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

Discussion 2 - Amro Mousa

Amro Mousa
Discussion 2:

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

To answer the aforementioned question, I'll simply break it up into the three subcategories, defining each one followed by a short segment on their inherent, defined differences.

Generally speaking, design patterns are ways to solve a design problem formed using some standard pseudo language. More specifically design patterns are not algorithms (a way to solve a computational/mathematical problem). Patterns are completely versatile and reusable generic solutions to design problems such as information hiding and decoupling. Patterns also cut down on code maintenance, the most costly part of application development.

Patterns, as the delegated question poses, come in three flavors: creational, structural, and behavioral. While the names of the categories hint at their meanings, they are not completely descriptive. For this reason, I’ll attempt to give more insight into their meaning.

“Creational patterns define mechanisms for instantiating objects. The implementation of the creational pattern is responsible for managing the lifecycle of the instantiated object.”

What does that mean? How do you definite the mechanism for instantiating objects? It’s quite simple. Just like all real-world objects are created in some sort of factory, for example, you can use an AbstractObjectFactory to create the object of your choice depending on input. The usefulness of such a strategy depends on the application. If one is designing a small self-use application, the use of an ObjectFactory is unimportant. On the other hand, if one is designing an enterprise-class, scalable application, the use of such a design pattern is a must to simplify the coding methodology and the design. It reduces class dependencies which saves maintenance time when the application has grown substantially.

Another creational pattern is the Singleton. This is another useful pattern that limits the life of an object to a single instance. This is useful, again for the enterprise, but also for smaller applications like a small chat server, or the like.

“The composition of objects and their organization to obtain new and varied functionality is the underlying basis of Structural patterns.”

Structural patterns, such as Adapters, simplify the way objects and existing classes interface with new implementation. By using an interface and changing its implementation, the class being interfaced with never knows the difference. This, again, is a way to simplify code maintenance.

Another structural pattern is the Proxy. Proxies simply mediate communication between objects and “play the role” of one of the objects. This is useful in remote/networked applications for security purposes. Only the data that is required is transferred.

“Interaction between different objects is specifically covered by Behavioral patterns.”

The most common behavioral pattern is the Iterator. Iterators define a standard methodology for accessing items in a list, completely hiding implementation of the list from the calling object. This is useful for a number of reasons: it reduces class coupling, increases information hiding (of the list implementation), and simplifies object method calls.

In short, creational, structural and behavioral patterns set a basis for solving design problems and in turn increase the likelihood that a design will truly meet the object-oriented model. Creational patterns simplify the object life cycle, structural increase information hiding and reduce coupling, and behavioral simplify object interaction.

Please note that part 2 of my discussion is included with part 1, above. I've described several patterns in detail, emphasizing the creational type.


Link to this Page