We start by exploring modern software development languages, frameworks and tools. This will include a rapid review of Java and an exploration of the principle features of successors to Java now emerging.
The term 'Paradigm' is sometimes used to attempt to encapsulate a mind-set associated with different movements in programming. Here we try to characterise what this means, and walk though some of the paradigms, old and new, in the field.
The history of programming languages is a facinating and continually evolving discipline. We briefly review alternative 'forces' shaping this evolution, as well as inspecting the programming 'family tree'. We will also walk through an extended example, exploring alternatives expressions of the same programme. This may yield some insights into current programming notations trends.
The java programming language is a mature, well understood language that powers many enterprises and public web applications. Originally design for the consumer electronics market, it was quickly adopted as general purpose, versatile language relatively easy to learn and master.
Classes are the fundamental abstraction in the language. Understanding their structure, layout and semantics is essential. In particular a clear understanding of the difference between static and regular attributes & methods + the role of the Object pseudo class is essential.
The set of control statements are largely inherited from C and C++. There are small number of these and their structure and behaviour is largely unsurprising.
Behind the language are a set of well-understood principles. These principles are independent of Java, but underpin its structure and meaning. Understanding these principles is important and is a useful starting point for comparing Java and the features of other programming languages.
This is your first assignment. It is a java console application, whose specification is presented here. A useful working pattern over the next few weeks would be to complete each lab, and and then evaluate the specification (and the project of the lab) and see where you need to go with it.
Object Oriented thinking has consistently placed the inheritance relationship as a key feature of its approach. We review how this relationship is realized in Java. As you will see it is a complex relationship, and we will return to the difficulties it can cause in a later topic.
All programming languages will have support for a range of common data structures. Unlike typical dynamic programming language, collections are implemented as a standard library in Java (as opposed to being built in). We will survey the major features of this library, focusing on the principle interfaces and implementations. There is considerable more to collections, which should be investigated independently.
At the heart of the JDK are object I/O and Serialization capabilities, packaged into a comprehensive library for managing the life cycle of simple objects. Although the approach taken by this particular base library has to some extent been superseded by other approaches, it remains an important and influential technical approach, that can be usefully applied in simpler standalone applications.
Test Driven Development has been among the most influential approaches in recent software engineering history. Here we look at its origins, principles and some of the important benefits of the approach.
The essential elements of TDD are fairly easy to grasp. The support libraries (xUnit) are relatively straightforward, and we can expect our IDE to provide direct assistance to using these libraries. Here we look at the facilities Eclipse provides to the JUnit library.
Earlier JUnit libraries relied on Inheritance and specific design patterns to integrate the unit tests into runnable test suites. Modern JUnit relies on Java Annotations - which simplify test structure and enable more flexible structuring of tests classes.
One way of becoming familiar with TDD is to explore some simple examples of various strategies that might be employed in some simple examples. Here we look at useful examples from the Pragmatic series - which laid out much of the early exploration of TDD.
We try to apply some of these practices to the Pacemaker app we are building the labs. In general many of the tests are straightforward, however there are some subtleties in the serializer tests.
Dealing with unexpected events and errors is usually delegated to the Exceptions mechanism in Java. Here we review the nature of exceptions and identify some best practices when dealing with exceptions generated from libraries and frameworks.
Building and deploying Java applications can be a source of considerable complexity and ad-hoc procedures. Maven is a tool than aims to standardize this process, incorporating rigorous dependency management, repository structure and project layout best practices.
Using maven in practice will involve bootstrapping a project from scratch, and dealing immediately with library dependencies. For well known libraries this will be straightforward. For obscure or abandoned libraries, we need to take some additional steps.
Xtend is an interesting "Java Successor" language, which exhibits many modern programing language features. Strongly influenced by python and to a certain extend Scala. The language us a useful example of the effectiveness of type inference.
This is a sample solution to assignment 1, Implemented in xtend and accompanied by simplified UML models.
Structure 101 from Headway will generate interesting and informative perspectives of the structure and organisation of a java, or java derived, language.
The solution to assignment 1 was developed partly with assignment 2 in mind. Here is the specification.
SRP is a simple yet effective guideline for determining the core features of a class. It is the first of the SOLID principles, a well respected source of effective design practices.
Redevelop the Pacemaker application into a simple cloud service. Expose this service as a REST API
A review of the basic structure of JUnit based tests, elaborating on the primary assert calls and annotations.
Guidelines for Composing Tests phrased using the acronym: - Right, Boundary, Inverse, Cross-check, Errors & Performance.
More guidelines - this time the acronym is Conformance, Ordering, Range, Reference, Existing, Cardinality, Time.
If you are using the Play Framework - and any Relational Database - then database evolution will be a central concern and a key source of misconfiguration errors.
THe second of the "SOLID" principles: "Software Entities should be open for extension but closed for modification"
Extend Pacemaker to include Activities & Locations. Review the design and implementation in UML + examine the new tests.
TDD is a rich and mature field, with its own literature and best practices. Here we review an attempt to capture some of this best practice into a set of higher level patterns.
An exploration of potential opportunities for Mocking in Pacemaker 2.0. These could include a social subsystem, which could be concieved as an independent system, mocked out in advance of its development.
Another of the SOLID principles - this time a more subtle take on inheritance, emphasizing the core behaviours expected by the relationship.
A quick tour of the Play Framework, providing just enough background to be able to make sense of Pacemaker 2.0 and its implementation.