Inversion de contrôle en Java. L'univers Java voit souvent apparaître de nouvelles technologies favorisant la conception d'architectures logicielles.
Depuis quelques années, de nombreux développeurs s'intéressent à l'inversion de contrôle, ou IoC pour Inversion of Control. L'inversion de contrôle figure une nouvelle approche de la programmation de services et de composants. Pour utiliser cette technique, vous devez avoir recours à un conteneur d'inversion de contrôle comme Hivemind, PicoContainer ou Spring. Un conteneur d'IoC peut être identifié par trois caractéristiques majeures : il contient des objets, il contrôle la création de ces objets et il résout les dépendances entre les objets. De par sa nature le conteneur gère le cycle de vie de ces objets. Pour comprendre l'inversion de contrôle, nous allons prendre l'exemple d'un composant permettant de trouver des livres dans une bibliothèque.
List<Book> books = importer.readBooks(); Proxy Design Pattern. Intent Provide a surrogate or placeholder for another object to control access to it.Use an extra level of indirection to support distributed, controlled, or intelligent access.Add a wrapper and delegation to protect the real component from undue complexity.
Problem You need to support resource-hungry objects, and you do not want to instantiate such objects unless and until they are actually requested by the client. Discussion Design a surrogate, or proxy, object that: instantiates the real object the first time the client makes a request of the proxy, remembers the identity of this real object, and forwards the instigating request to this real object.
There are four common situations in which the Proxy pattern is applicable. Private Class Data. Intent Control write access to class attributesSeparate data from methods that use itEncapsulate class data initializationProviding new type of final - final after constructor.
Flyweight Design Pattern. Intent Use sharing to support large numbers of fine-grained objects efficiently.The Motif GUI strategy of replacing heavy-weight widgets with light-weight gadgets.
Problem Designing objects down to the lowest levels of system "granularity" provides optimal flexibility, but can be unacceptably expensive in terms of performance and memory usage. Facade Design Pattern. Decorator Design Pattern. Intent Attach additional responsibilities to an object dynamically.
Decorators provide a flexible alternative to subclassing for extending functionality.Client-specified embellishment of a core object by recursively wrapping it.Wrapping a gift, putting it in a box, and wrapping the box. Problem You want to add behavior or state to individual objects at run-time. Inheritance is not feasible because it is static and applies to an entire class. Discussion Suppose you are working on a user interface toolkit and you wish to support adding borders and scroll bars to windows. But the Decorator pattern suggests giving the client the ability to specify whatever combination of "features" is desired.
Widget* aWidget = new BorderDecorator( new HorizontalScrollBarDecorator( new VerticalScrollBarDecorator( new Window( 80, 24 )))); aWidget->draw(); This flexibility can be achieved with the following design. Composite Design Pattern. Intent Compose objects into tree structures to represent whole-part hierarchies.
Composite lets clients treat individual objects and compositions of objects uniformly.Recursive composition"Directories contain entries, each of which could be a directory. "1-to-many "has a" up the "is a" hierarchy Problem Application needs to manipulate a hierarchical collection of "primitive" and "composite" objects. Processing of a primitive object is handled one way, and processing of a composite object is handled differently.
Discussion Define an abstract base class (Component) that specifies the behavior that needs to be exercised uniformly across all primitive and composite objects. Use this pattern whenever you have "composites that contain components, each of which could be a composite". Child management methods [e.g. addChild(), removeChild()] should normally be defined in the Composite class. Structure. Bridge Design Pattern.
Intent Decouple an abstraction from its implementation so that the two can vary independently.Publish interface in an inheritance hierarchy, and bury implementation in its own inheritance hierarchy.Beyond encapsulation, to insulation Problem "Hardening of the software arteries" has occurred by using subclassing of an abstract base class to provide alternative implementations.
This locks in compile-time binding between interface and implementation. The abstraction and implementation cannot be independently extended or composed. Motivation Consider the domain of "thread scheduling". There are two types of thread schedulers, and two types of operating systems or "platforms". What if we had three kinds of thread schedulers, and four kinds of platforms? The Bridge design pattern proposes refactoring this exponentially explosive inheritance hierarchy into two orthogonal hierarchies – one for platform-independent abstractions, and the other for platform-dependent implementations. Discussion Structure. Adapter Design Pattern. Intent Convert the interface of a class into another interface clients expect.
Adapter lets classes work together that couldn't otherwise because of incompatible interfaces.Wrap an existing class with a new interface.Impedance match an old component to a new system Problem An "off the shelf" component offers compelling functionality that you would like to reuse, but its "view of the world" is not compatible with the philosophy and architecture of the system currently being developed. Discussion Reuse has always been painful and elusive.
It is like the problem of inserting a new three-prong electrical plug in an old two-prong wall outlet – some kind of adapter or intermediary is necessary. Adapter is about creating an intermediary abstraction that translates, or maps, the old component to the new system.