1.Identify the aspects of your application that vary and separate them from what stays the same.
2.Program to an interface, not an implementation.
3.Favor composition over inheritance.
4.Classes should be open for extension, but closed for modification.
-The Strategy Pattern defines a family of algorithms, encapsulates each one, and makes them interchangeable. Strategy lets the algorithm vary independently from clients that use it.
Observer Pattern
� The Observer Pattern defines a one-to-many relationship between objects.
� Subjects, or as we also know them, Observables, update Observers using a common interface.
� Observers are loosely coupled in that the Observable knows nothing about them, other than that they implement the Observer Interface.
� You can push or pull data from the Observable when using the pattern (pull is considered
more “correct”).
� Don’t depend on a specific order of notifcation for your Observers.
� Java has several implementations of the Observer Pattern, including the general purpose java.util.Observable.
� Watch out for issues with the java.util.Observable implementation.
� Don’t be afraid to create your own Observable implementation if needed.
� Swing makes heavy use of the Observer Pattern, as do many GUI frameworks.
� You’ll also find the pattern in many other places, including JavaBeans and RMI.
Decorator pattern
The Decorator Pattern attaches additional responsibilities to an object dynamically.
Decorators provide a flexible alternative to subclassing for extending functionality.
� Decorators have the same supertype as the objects they decorate.
� You can use one or more decorators to wrap an object.
� Given that the decorator has the same supertype as the object it decorates, we can pass
around a decorated object in place of the original (wrapped) object.
� The decorator adds its own behavior either before and/or after delegating to the object it
decorates to do the rest of the job.
� Objects can be decorated at any time, so we can decorate objects dynamically at runtime
with as many decorators as we like.
2.Program to an interface, not an implementation.
3.Favor composition over inheritance.
4.Classes should be open for extension, but closed for modification.
-The Strategy Pattern defines a family of algorithms, encapsulates each one, and makes them interchangeable. Strategy lets the algorithm vary independently from clients that use it.
Observer Pattern
� The Observer Pattern defines a one-to-many relationship between objects.
� Subjects, or as we also know them, Observables, update Observers using a common interface.
� Observers are loosely coupled in that the Observable knows nothing about them, other than that they implement the Observer Interface.
� You can push or pull data from the Observable when using the pattern (pull is considered
more “correct”).
� Don’t depend on a specific order of notifcation for your Observers.
� Java has several implementations of the Observer Pattern, including the general purpose java.util.Observable.
� Watch out for issues with the java.util.Observable implementation.
� Don’t be afraid to create your own Observable implementation if needed.
� Swing makes heavy use of the Observer Pattern, as do many GUI frameworks.
� You’ll also find the pattern in many other places, including JavaBeans and RMI.
Decorator pattern
The Decorator Pattern attaches additional responsibilities to an object dynamically.
Decorators provide a flexible alternative to subclassing for extending functionality.
� Decorators have the same supertype as the objects they decorate.
� You can use one or more decorators to wrap an object.
� Given that the decorator has the same supertype as the object it decorates, we can pass
around a decorated object in place of the original (wrapped) object.
� The decorator adds its own behavior either before and/or after delegating to the object it
decorates to do the rest of the job.
� Objects can be decorated at any time, so we can decorate objects dynamically at runtime
with as many decorators as we like.