View this PageEdit this PageAttachments to this PageHistory of this PageHomeRecent ChangesSearch the SwikiHelp Guide
Hotspots: Admin Pages | Turn-in Site |
Current Links: Cases Final Project Summer 2007

Robert Hutson - Discussion 2

Name: Robert Hutson

Q = What are the differences between creational, structural, and behavioral patterns?

I'll start this discussion with a few general definitions of the terms 'creational', 'structural', and 'behavioral' as applied to design patterns in an object-oriented programming sense. Most design patterns can be classified with one of these three purposes in mind. Creational design patterns deal with object creation mechanisms. That is, trying to create objects in a manner suitable to the situation. This is often used to avoid complexity in a design in which there are a lot of objects all doing different things and that serve a different purpose in the overall program. Structural design patterns ease the design process by identifiying a simple way to realize relationships between entities. Put another way, they focus on the composition of classes and objects into larger structures. These 'compositions' are done at run-time (i.e. dynamic). Behavioral patterns identify common communication patterns between objects and realize these patterns. By doing so, these patterns increase flexibility in carrying out this comunication, or interaction if you will. So in short, creational patterns deal with object creation (hence the name), structural patterns deal with composition of objects into larger structures (hence the name again), and behavioral patterns deal with interaction between objects, or their general communicative behavior.

Now I will give an example and brief explanation of each for each of the patterns previously discussed.
One example of a creational design pattern is the Singleton. The singleton design pattern ensures that only one instance of a class is created. All objects that use an instance of that class use the same instance. This can be helpful if you have a lot of objects that need an instance of a class, but you want to be extra sure that they get the correct instance.
An example of a structural design pattern would be a Facade. A Facade pattern simplifies access to a related set of objects by providing one object that all objects outside the set use to communicate with the sets. This sounds similar to an interface.
Lastly, an example of a behavioral design pattern would be a Null Object. This provides an alternative to using 'null' to indicate the absence of an object to delegate an operation to. Using null to indicate the absense of such an object requires a test for null before each call to the other object's methods. Instead of using null, the Null Object pattern uses a reference to an object that doesn't do anything. In other words, a blank class with blank methods.

Here, I will discuss the Facade pattern in some more detail because it is one which I find particularly interesting because I have indeed unknowingly used this before in a cs2335 project in which the Client networking classes needed to communicate not only with each other, but with the main Gui classes, without having to put an instance of one in the other (which would have been a poor design). First I will give a slightly different version of the definition given in the previous part of this discussion. A Facade is a structural design pattern which provides a unified interface to a set of interfaces in a subsystem, in turn making the subsystem easier to use. Everything related to this pattern is in either a Facade class/object (the affector) or a subsystem class (the affectee). The responsibilities of the Facade class is to know which subsystem classes are responsible for a given request, and then delegate the request to the appropriate object. The Subsystem classes implement subsystem functionality (the stuff that gets invoked by the Facade object), and it handles any work delegated/assigned to it. However, the subsystem classes should not have any knowledge of the Facade and thereby keeps no reference (instance variable) of it. To put this pictorially, in a UML diagram of this, it would have a box for the Facade, with a bunch of arrows directed away from it to the various Subsystem boxes. With that said, you should have a pretty clear idea of when to use something like this. For example, a multi-threaded server might have a Facade class that delegates responsilities to separate Client handlers (connections to it). So the server would receive a client request, and then know which client sent it through some kind of Facade, which can then tell the appropriate object(s) to handle it accordingly. I have done something pretty simliar to this in the past and it actually worked out quite well. Enough said...this concludes my discussion on the Facade pattern.

Links to this Page