S.O.L.I.

D Principles
You are doing Object Oriented Design if your code is: SOLID 5 simple principles whereby written code can be more readable and easier to maintain Single responsibility principle There should never be more than one reason for a class to change. Of course, object oriented. Re-usable. Can be changed with minimal effort. Can be extended without changing existing code.

Open/closed principle Software entities (classes, modules, functions, etc.) should be open for extension but closed for modification.

Liskov substitution principle Functions that use ... references to base classes must be able to use objects of derived classes without knowing it.

Interface segregation principle Clients should not be forced to depend upon interfaces that they do not use.

Dependency inversion principle High-level modules should not depend on low-level modules. Both should depend on abstractions. Abstractions should not depend upon details. Details should depend upon abstractions.

Single Responsibility Principle

State that a class should have only one reason to change. Every object should have a single responsibility, and that responsibility should be entirely encapsulated by the class. All its services should be narrowly aligned with that responsibility. The Single Responsibility Principle represents a good way of identifying classes during the design phase of an application and it reminds you to think of all the ways a class can evolve. A good separation of responsibilities is done only when the full picture of how the application should work is well understands.

Open Closed Principle

Open-Closed Principle has 2 primary attributes: 1. "Open For Extension" - It is possible to extend the behavior of the module as the requirements of the application change (i.e. change the behavior of the module). 2. "Closed for Modification" - Extending the behavior of the module does not result in the changing of the source code or binary code of the module itself.

Liskov Substitution Principle (a.k.a. design by contract)

Likov's Substitution Principle states that if a program module is using a Base class, then the reference to the Base class can be replaced with a Derived class without affecting the functionality of the program module. This principle is just an extension of the Open Close Principle and it means that we must make sure that new derived classes are extending the base classes without changing their behavior. Liskov's principle imposes some standard requirements on signatures: Contra variance of method arguments in the subtype. Covariance of return types in the subtype. No new exceptions should be thrown by methods of the subtype, except where those exceptions are themselves subtypes of exceptions thrown by the methods of the super type.

Design by contract leading to some behavioral restrictions on how contracts can interact with inheritance: Preconditions cannot be strengthened in a subtype, Post conditions cannot be weakened in a subtype. Invariants of the super type must be preserved in a subtype, history constraint ("history rule" encapsulation).

Behaviorally, a Square is not a Rectangle! And it is behavior that software is really all about. The LSP makes clear that in OOD the IS-A relationship pertains to behavior. Not intrinsic private behavior, but extrinsic public behavior that clients depend upon.

Interface Segregation Principle

States that client should not be forced to implement interfaces they don't use. Instead of one fat interface many small interfaces are preferred based on groups of methods, each one serving one sub module. It produces a flexible design

If the design is already done fat interfaces can be segregated using the Adapter pattern. If we are going to apply it more than is necessary it will result a code containing a lot of interfaces with single methods, so applying should be done based on experience and common sense in identifying the areas where extension of code are more likely to happens in the future.

Dependency Inversion Principle

High-level modules should not depend on low-level modules. Both should depend on abstractions. Abstractions should not depend upon details. Details should depend upon abstractions. The goal of the dependency inversion principle is to decouple high-level components from low level components such that reuse with different low-level component implementations becomes possible.

http://lostechies.com/chadmyers/2008/03/08/pablo-s-topic-of-the-month-march-solid-principles/ http://www.oodesign.com/

Design Patterns
1. Strategy: Defines a family of algorithms, encapsulates each one, and make them interchangeable. Strategy lets the algorithm vary independently from clients who use it. 2. Decorator: Attach additional responsibilities to an object dynamically. Decorators provide a flexible alternative to sub classing for extending functionality. 3. Factory Method Define an interface for creating an object, but let the subclasses decide which class to instantiate. Factory Method lets a class defer instantiation to subclasses. 4. Observer Define a one-to-many dependency between objects so that when one object changes state, all its dependents are notified and updated automatically. 5. Chain of Responsibility Avoid coupling the sender of a request to its receiver by giving more than one object a chance to handle the request. Chain the receiving objects and pass the request along the chain until an object handles it. 6. Singleton Ensure a class only has one instance, and provide a global point of access to it. 7. Flyweight Use sharing to support large numbers of fine-grained objects efficiently. A flyweight is a shared object that can be used in multiple contexts simultaneously. The flyweight acts as an independent object in each context; its indistinguishable from an instance of the object thats not shared. 8. Adapter Convert the interface of a class into another interface clients expect. Adapter lets classes work together that couldnt otherwise because of incompatibility interfaces. 9. Faade Provide a unified interface to a set of interfaces in a system. Faade defines a higher-level interface that makes the subsystem easier to use. 10. Template Define a skeleton of an algorithm in an operation, deferring some steps to subclasses. Template Method lets subclasses redefine certain steps of an algorithm without changing the algorithms structure. 11. Builder Separate the construction of a complex object from its representation so that the same construction processes can create different representations. 12. Iterator Provide a way to access the elements of an aggregate object sequentially without exposing its underlying representation. 13. Composite Compose objects into tree structures to represent part-whole hierarchies. Composite lets clients treat individual objects and compositions of objects uniformly. 14. Command

Encapsulate a request as an object, thereby letting you parameterize clients with different requests, queue or log requests, and support undoable operations. 15. Mediator Define an object that encapsulates how a set of objects interact. Mediator promotes loose coupling by keeping objects from referring to each other explicitly, and lets you vary their interaction independently. 16. State Allow an object to alter its behavior when its internal state changes. The object will appear to change its class. 17. Proxy Provide a surrogate or placeholder for another object to control access to it. 18. Abstract Factory Provide an interface for creating families of related or dependent objects without specifying their concrete classes. 19. Bridge Decouple an abstraction from its implementation so that the two can vary independently. 20. Interpreter Given a language, define a representation for its grammar along with an interpreter that uses the representation to interpret sentences in the language. 21. Memento Without violating encapsulation, capture and externalize an objects internal state so that the object can be restored to this state later. 22. Prototype Specify the kinds of objects to create using a prototypical instance, and create new objects by copying this prototype. 23. Visitor Represent an operation to be performed on the elements of an object structure. Visitor lets you define a new operation without changing the classes of the elements on which it operates.