HFDP - Protection Proxy
This post has been moved to Biting Code, a blog dedicated only to JVM languages.
HFDP - Virtual Proxy
This post on the Virtual Proxy has been moved to Biting Code, my blog dedicated to JVM languages.
HFDP - Proxy
This post on the Proxy pattern has been moved to Biting Code, my blog dedicated to JVM languages.
HFDP - Remote Proxy / RMI
This post on the Remote Proxy and RMI has been moved to Biting Code, my blog dedicated to JVM languages.
HFDP - State
This post on the State pattern has been moved to Biting Code, my blog dedicated to JVM languages.
HFDP - External Iterator for Composite
This post on the External Iterator for Composite pattern has been moved to Biting Code, my blog dedicated to JVM languages.
HFDP - Composite
This post on the Composite pattern has been moved to Biting Code, my blog dedicated to JVM languages.
HFDP - Single Responsibility
Accordingly to the Single Responsibility Design Principle we should strieve for give to a class only one reason to change.
Any responsibility represents also a reason for possible changes. If a class has more than one responsibility, it would have also more than one area of changes.
Tending to the single responsibility paradigm helps us to design the class with an high cohesion. We say that a class has an high cohesion when it is designed around a set of related functions.
This is the principle that guided to the Iterator pattern, since it extracts that functionality from the relative collection, giving it an heigher cohesion.
In chapter eight of Head First Design Patterns, by Freeman, Freeman, Sierra, Bates, is said more on this design principle.
Any responsibility represents also a reason for possible changes. If a class has more than one responsibility, it would have also more than one area of changes.
Tending to the single responsibility paradigm helps us to design the class with an high cohesion. We say that a class has an high cohesion when it is designed around a set of related functions.
This is the principle that guided to the Iterator pattern, since it extracts that functionality from the relative collection, giving it an heigher cohesion.
In chapter eight of Head First Design Patterns, by Freeman, Freeman, Sierra, Bates, is said more on this design principle.
HFDP - Iterator
This post on the Iterator pattern has been moved to Biting Code, a blog dedicated to JVM languages.
HFDP - The Hollywood Principle
This post on the Hollywood Principle pattern has been moved to Biting Code, my blog dedicated to JVM languages.
HFDP - Template Method
This post on the Template Method pattern has been moved to Biting Code, a blog dedicated to JVM languages.
HFDP - Principle of Least Knowledge
This post has been moved to Biting Code, a blog dedicated to JVM languages only.
HFDP - Façade
This post on the Façade pattern has been moved to Biting Code, a blog dedicated to JVM languages only.
HFDP - Adapter
This post on the Adapter pattern has been moved to Biting Code, a blog dedicated to JVM languages only.
HFDP - Command
This post on the Command pattern has been moved to Biting Code, a blog dedicated to JVM languages only.
HFDP - Null Object
This post on the Null Object pattern (or idiom) has been moved to Biting Code, a blog dedicated to JVM languages only.
HFDP - Singleton
This post on the Singleton pattern has been moved to Biting Code, a blog dedicated only to JVM languages.
HFDP - Abstract Factory
If we need to create objects from families of product we could use the Abstract Factory Pattern, that provides an interface to create families of related objects without specifying their concrete class.
The AbstractFactory defines the interface for all the ConcreteFactory, basically providing an abstract method for each product that has to be created.
The Client is written referring to the AbstractFactory interface that would be set to a ConcreteFactory at runtime.
For instance, our PizzaStore could use an Abstract Factory to make available to the process specific ingredients accordingly to the actual PizzaStore is running.
So, the NYPizzaStore would use the NYIngredientFactory, in this way our call in the client for, say, ingredient.createDough(), would resolve in a call for that specific ingredient factory, that would give us the specific dough for the New York pizza style.
This post was about the third part of chapter four of Head First Design Patterns, by Freeman, Freeman, Sierra, Bates. Get the book for more details.
The AbstractFactory defines the interface for all the ConcreteFactory, basically providing an abstract method for each product that has to be created.
The Client is written referring to the AbstractFactory interface that would be set to a ConcreteFactory at runtime.
For instance, our PizzaStore could use an Abstract Factory to make available to the process specific ingredients accordingly to the actual PizzaStore is running.
So, the NYPizzaStore would use the NYIngredientFactory, in this way our call in the client for, say, ingredient.createDough(), would resolve in a call for that specific ingredient factory, that would give us the specific dough for the New York pizza style.
This post was about the third part of chapter four of Head First Design Patterns, by Freeman, Freeman, Sierra, Bates. Get the book for more details.
HFDP - Factory Method
This post has been moved to Biting Code, a blog dedicated only to JVM languages.
HFDP - Simple Factory
This post has been moved to Biting Code, a blog dedicated only to JVM languages.
Head First - Design Patterns
I love the Head First books. They are fun to read and actually convey a load of useful information.
I have already read this particular episode of their series a while ago, but now I've got the impulse of reading it again, and what I am doing is jotting down a few lines that I think could be useful to the occasional reader to have an idea of the book.
The programming language used along in the book is Java, so it's better to have a good knowledge of it - or at least of a similar language like C# - to understand properly what is going on.
If you are interested in software design I warmly suggest you to get it. Head First Design Patterns, by Freeman, Freeman, Sierra, Bates; it's an O'Really book.
I have already read this particular episode of their series a while ago, but now I've got the impulse of reading it again, and what I am doing is jotting down a few lines that I think could be useful to the occasional reader to have an idea of the book.
The programming language used along in the book is Java, so it's better to have a good knowledge of it - or at least of a similar language like C# - to understand properly what is going on.
If you are interested in software design I warmly suggest you to get it. Head First Design Patterns, by Freeman, Freeman, Sierra, Bates; it's an O'Really book.
Subscribe to:
Posts (Atom)