Pages

HFDP - Proxy

This post on the Proxy pattern has been moved to Biting Code, my blog dedicated to JVM languages.

Go to the full post

HFDP - Remote Proxy / RMI

This post on the Remote Proxy and RMI has been moved to Biting Code, my blog dedicated to JVM languages.

Go to the full post

HFDP - State

This post on the State pattern has been moved to Biting Code, my blog dedicated to JVM languages.

Go to the full post

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.

Go to the full post

HFDP - Composite

This post on the Composite pattern has been moved to Biting Code, my blog dedicated to JVM languages.

Go to the full post

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.

Go to the full post

HFDP - Iterator

This post on the Iterator pattern has been moved to Biting Code, a blog dedicated to JVM languages.

Go to the full post

HFDP - The Hollywood Principle

This post on the Hollywood Principle pattern has been moved to Biting Code, my blog dedicated to JVM languages.

Go to the full post

HFDP - Adapter

This post on the Adapter pattern has been moved to Biting Code, a blog dedicated to JVM languages only.

Go to the full post

HFDP - Command

This post on the Command pattern has been moved to Biting Code, a blog dedicated to JVM languages only.

Go to the full post

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.

Go to the full post

HFDP - Singleton

This post on the Singleton pattern has been moved to Biting Code, a blog dedicated only to JVM languages.

Go to the full post

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.

Go to the full post

HFDP - Strategy

This post has been moved to Biting Code, a blog dedicated only to JVM languages.

Go to the full post

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.

Go to the full post