Design pattern

best way to use patterns is to load yourself with them and then recognise places in designs and existing applications where to apply them.

- Instead of code reuse, with patterns we get experience reuse.
Using inheritance hasn’t worked out very well, since the behaviour can change across the subclasses, and it’s not appropriate for all subclasses to have those behaviours.
The interface seemed promising as only objects that really do have behaviour will implement them.
- This would cause duplication of code across all objects as Java interfaces typically have no implementation code, so no code reuse (default enabled writing default implementation) .
  - To modify a behaviour, often forced to track down and change it in all the different subclasses where that behaviour is defined.

Take the parts that vary and encapsulate them, so that later you can alter or extend the parts that vary without affecting those that don’t.

If some aspect of code is changing with every new requirement pull iy out and separated from all the stuff that doesn’t change.
- Fewer unintended consequences from code changes and more flexibility to systems.
Create new classes by extracting the varying behaviour into its own class.
- the set of classes whose entire reason for living is to represent a behavior
Include behavior setter methods in the main classes so that we can change the behavior at runtime.

Program to an interface, not an implementation.

use an interface to represent each behavior
It’s the behavior class, rather than the main class, that will implement the behavior interface.
With new design, the behavior subclasses will use a behavior represented by an interface, so that the actual implementation of the behavior (in other words, the specific concrete behavior coded in the class that implements the behavior ) won’t be locked into the behavior subclass.

best way to use patterns is to load yourself with them and then recognise places in designs and existing applications where to apply them.

- Instead of code reuse, with patterns we get experience reuse.
Using inheritance hasn’t worked out very well, since the behaviour can change across the subclasses, and it’s not appropriate for all subclasses to have those behaviours.
The interface seemed promising as only objects that really do have behaviour will implement them.
- This would cause duplication of code across all objects as Java interfaces typically have no implementation code, so no code reuse (default enabled writing default implementation) .
  - To modify a behaviour, often forced to track down and change it in all the different subclasses where that behaviour is defined.

Take the parts that vary and encapsulate them, so that later you can alter or extend the parts that vary without affecting those that don’t.

If some aspect of code is changing with every new requirement pull iy out and separated from all the stuff that doesn’t change.
- Fewer unintended consequences from code changes and more flexibility to systems.
Create new classes by extracting the varying behaviour into its own class.
- the set of classes whose entire reason for living is to represent a behavior
Include behavior setter methods in the main classes so that we can change the behavior at runtime.

Program to an interface, not an implementation.

use an interface to represent each behavior
It’s the behavior class, rather than the main class, that will implement the behavior interface.
With new design, the behavior subclasses will use a behavior represented by an interface, so that the actual implementation of the behavior (in other words, the specific concrete behavior coded in the class that implements the behavior ) won’t be locked into the behavior subclass.