Guru's Excerpt

1) "Prefer composition to Inherentance."

--From GOF

 

2) A word about checked exceptions:

    The great value of exceptions is the unification of error reporting: a standard machanism by which to report errors, rather than the popourri of ignorable approaches that we had in C.

    I believe taht have a single mechanism for handling errors is excellent, and I believe that using a separate channel(exception handling mechanism) for moving the exceptions around is good, but it seems to me that checked exception do not do this; instead, they tend to intrude (a lot) into your "normal working code" and thus a step backwards.

    "I intend to put a lot more RuntimeExceptions into my Java code."

--From Bruce Eckel

 

3) "Design patterns help you learn from other's successes instead of your own failures."

--From Mark Johnson

 

4) "Separate things that change from things that stay the same."

 

5) The basic concept of a pattern can also be seen as the basic concept of program design: adding a layer of abstraction.

 

6) Classifying patterns:

    1> Creational:

             How an object can be created.

             This often involves isolating the details of object creation,

             so your code isn't dependent on what types of objects there are and thus doesn't have to be changed when you add a new type of Object.

         Eg. Singleton, Factory, Factory Method, Abstract Factory, Builder and Prototype patterns.

    2> Structural:

            Objects are connected with other objects to ensure that changes in the system don't require changes to those connections.

         Eg. Adapter, Bridge, Composite, Decorator and Proxy.

    3> Behavioral:

            Objects that handle particular types of actions within a program.

            These encapsulate processes that you want to perform, such as interpreting a language, fulfilling a request, moving through a sequence (as in an interator), or implementing an algorithm.

          Eg. Observer, Visitor, Iterator, Command, Chain of Responsibility, Template Method and Strategy patterns.

 

7) "We should forget about small effenciencies, say about 97% of the time: Premature optimization is the root of all evil."

-- From Donald Knuth

 

8) Design Principles (SOLID):

    1> Single Responsibility Principle (SRP)

         A class should have only one reason to change. 

    2> Open-Close Principles (OCP)

         Software entities like classes, modules and functions should be open for extention but close for modifications.

    3> Liskov Substitution Principles (LSP)

         Derived types must be completely substitutable for their base types.

    4> Interface Segregation Principles (ISP)

         Clients should not be forced to depend upon interfaces that they don't use.

         This principle teaches us to take care how we write our interfaces. When we write our interfaces we should take care to add only methods that should be there. If We add methods that should not be there, the classes implementing the interface will have to implement those methods as well. For example if we create a an interface called Worker and add a method lunch break, all the workers will have to implement it. What if the worker is a robot?

         As a conclusion, Interfaces containing methods that are not specific to it are called polluted or fat interfaces. We should avoid them.

    5> Dependency Inversion Principle (DIP)

         1. High-level modules should not depend on low-level modules. Both should depend on abstractions. 

         2. Abstractions should not depend on details. Details should depend on abstractions.

         -->Interface Oriented Programming & Spring Ioc & Google Guice

 

9) Law of Demeter

    a.k.a. "Don't talk to strangers." 

    An object A can request a service (call a method) of an object instance B, but object A should not "reach through" object B to access yet another object C, to request its services. Doing so would mean that object A implicitly requires greater knowledge of object B's internal structure. Instead, B's interface should be modified if necessary so it can directly serve object A's request, propagating it to any relevant subcomponents. Alternatively, A might have a direct reference to object C and make the request directly to that. If the law is followed, only object B knows its own internal structure.

 

Reference Links:

1) http://www.oodesign.com/design-principles.html