Question 1a
We have used the term “program to an interface, not to an implementation”.
Why is this desirable?

Answer:
Following this principle leads to code that exhibits loose coupling
among classes. Examples of these benefits include:

a) Better testability. Classes that are not under tests can be
substituted with fakes that implement the same interface. I.e you could
substitute AJAXLibrary with FakeAJAX if the class just expects anything
that implements an interface RemoteCallLibrary.

b) Better code reuse. If you have a routine that can sort anything that
implements Comparable interface, you can now sort almost anything pretty
easily instead of writing sorts for every type of object.

Question 1b
We also used the term “favor object composition over class inheritance”.
Explain this concept and indicate
what possible advantages there may be. In your discussion explain what
object composition is, discuss the
advantages and disadvantages of class inheritance and the possible
advantages of object composition.

Answer:

Two common advantages of Composition over inheritance:
Composition allows for code reuse even if two objects don't fit into a
class taxonomy. In a video game, there could be a Monster class,
Observer Camera class, and some utility search class. They can all
maintain (be composed of) a strategy object to figure out how to traverse
the level. But they don't have (not do they need) a shared ancestor. Fitting
them into a taxonomy with a shared superclass is awkward and complicates
the taxonomy by another level.

Composition allows to vary the behaviour of the object at runtime,
Using the example of strategy above, the strategy of the Monster
traversing the map can change depending on inputs by the user during the
lifetime of a Monster instance.

Disadvantage:
Certain problems have a class hierarchy map well to a domain taxonomy.
If different types of bank loans form a hierarchy of types in the
problem domain, it might be awkward to split up a concept of a loan into
pieces that compose each other. Inheritance thus would better represent
the domain problem.


Question 2
We discussed architectural styles, architectural design patterns and basic
design patterns. Explain the difference between these concepts and when
(during the development cycle) they could be used. Why would one even
consider applying these methods? Is there any useful result in the short or
long term for the software system?

Architectural styles: Broad approaches to solving problems (pipes & 
filters, object-oriented, tiers, repository, etc.) that define which 
underlying tools are available to be used by patterns. These must be 
decided early, as they provide the general approach that is implemented. 

Architectural design patterns: Higher-level than design patterns, 
describe construction of system as a whole and links between components. 
These should be decided early as they can have far-reaching 
implications. e.g. Should tiers be accessed through a façade?

Basic design patterns: Refer to how the internals of a component are 
arranged in order to solve problems. These are decided on as the problem 
they solve arises. e.g. An iterator is introduced when an operation must 
be applied to every component of a data structure. 

Rayside’s opinion is that these are all design patterns. 

Design patterns specify a general solution schema for problems that is 
known to have certain desirable properties. In the short term, the 
decision to use a design pattern provides a clear procedure for 
implementation. In the long term, the use of a standard design pattern 
provides a clear structure for maintenance programmers to help 
understand the code as well as use whatever extensibility procedures are 
available to the pattern.