Software Design Patterns Lecutre (Intro)

Editor's Notes

• #6: scalability deals with how the application can grow or shrink. Extensibility deals with how other people, systems, etc. can take the existing code and add on to it without affecting the base
• #8: Name – helps in having a common vocabulary for communication Problem – a list of conditions to be met before the pattern can be applied
• #9: Solution – doesn’t describe a concrete design or implementation, because pattern is like a template Consequences – seldomly discussed but very imp…generally time and space tradeoffs…May address implementation and language issues as well. Listing consequences help in evaluating and understanding patterns.
• #10: The purpose criterion sorts the patterns in three groups. Creational, Structural and Behavioural. Creational patterns deals with object creation. Class scope creational patterns defer some part of the object creation process to subclasses. Object scope creational patterns defer it to another object. Structural patterns deals with compositions of objects and classes. Structural class patterns are based on inheritance to build a structure. Structural object patterns use object references to build a structure. Behavioural patterns are used to distribute responsibility between classes and objects. The patterns define how the classes and objects should interact, and what responsibilities each participant has. Behavioural class patterns are based on inheritance. They are mostly concerned with handling algorithms and flow of control. Behavioural object patterns describe how objects can cooperate to carry out tasks that no single object can carry out alone.
• #12: Object proliferation - you'll end up with a lot extra little objects when you implement the design pattern. So you have quite a few small classes that don't really do anything. It ends up taking tons of classes to do something really small an anti-pattern is something that does not work, or is so brittle that it gives the appearance of working, but is easily broken. One common anti-pattern: using inheritance from a utility class (e.g., Hashtable) rather than delegation. Inheritance is used very often in this context, and even works, but has the following problems: It causes the derived class to rely on the internals of a base class which is out of the control of the developer. While the utility classes normally are stable and fairly similar across VMs, some innocuous change in the future could break the derived class. It muddies the business meaning of the derived class. For example, an order is not a vector, although an order may contain a vector of line items.
• #15: Interfaces are fundamental in OO. Objects are known only thru their interfaces…there is no other way of knowing what is inside. Interface hides the implementation details. This means that 2 diff objects can have 2 totally diff implementations for the same interface. Inheritance (white box) – internal details visible, static- compile time. Inheritance sometimes break encapsulation. Composition (black box) – well defined interface, internal details not visible, dynamic – run time
• #21: Help in building flexible systems because they minimize interdependency between objects. A well defined interface is all that is needed. The ability to add new objects without affecting the existing objects.
• #25: The only thing that the Subject knows about the Observer is that it implements a certain interface Can add new observers at any time We never need to modify the subject to add new types of observers Changes to either Subject or Observers will not affect the other. Talk about push and pull.
• #30: Fro the technical folks…will this compile? Ans: yes, since the constructor is protected. Solution: private constructor (but no subclassing then) separate package for the Singleton class.
• #31: Multithreading issues…can be avoided, synchronizing the getInstance() method. Public static synchronized Singleton getInstance() Static initialization instead of lazy initialization. Private static Singleton instance = new Singleton();
• #37: Seem like a contradiction. There are techniques, example Observer. We can extend the Subject by adding new Observers without actually adding code to the Subject. Also called Open-Closed Principle. Be careful, can result in complex code.
• #41: If there
• #42: Proxy and Decorator very similar… Decorator adds behavior to a class while proxy controls access to it.
• #46: The Proxy class might have stale information, in which case we might have to add some extra logic to ensure freshness…Depending on the logic, complexity level might increase.
• #48: Minimize the number of classes an object interacts with. This principle prevents us from creating designs with large number of coupled classes such that changes in one part of the system cascades to other parts. Lots of dependencies results in fragile, expensive, and complex systems.
• #71: Interfaces are fundamental in OO. Objects are known only thru their interfaces…there is no other way of knowing what is inside. Interface hides the implementation details. This means that 2 diff objects can have 2 totally diff implementations for the same interface. Inheritance (white box) – internal details visible, static- compile time. Inheritance sometimes break encapsulation. Composition (black box) – well defined interface, internal details not visible, dynamic – run time