Showing posts with label Design. Show all posts
Showing posts with label Design. Show all posts

HFDP - Model View Controller (MVC)

MVC is probably the most known compound pattern, since it describes naturally almost any modern application.

Let's think for instance to an mp3 player. The user sees on the View what is the current status of the player. Using the interface, the user asks the application to do something new, as playing another song, and the request is passed to the Controller. The Controller acts consequently, asking the model to change its status. The View observes the Model, and reacts changing accordingly when notified by the Model.

Model: keeps all the data, the state and the application logic.
View: gives the user a presentation of the model.
Controller: receives the user inputs and asks for changes in the Model and View accordingly.

The user has only access to the View. His requests are passed to the Controller.

The Controller translates the request it gets from the View in calls to the Model.

If required, the Controller could also ask the View to change.

The Model notifies the View when its state changes. And the View could ask the Model for more data to integrate the information to be showed to the user.

The Observer Pattern connects the Model to the View. The Model is observed by the View.
The Strategy Pattern connects the View to the Controller. The Controller implements the behaviour of the View.
The Composite Pattern is used to structure the View, to manage all its components.

More on MVC, and on compound patterns, in chapter twelve of Head First Design Patterns, by Freeman, Freeman, Sierra, Bates.

Go to the full post

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