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: Kyle Spafford

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

There are many differences between these categories of design patterns. Each of these categories aims to model the solution to a problem through in a certain viewpoint. Since there can almost always be multiple solutions to a single problem, the particular point-of-view about how to solve the problem is unique to each category. In order to better understand the difference, an explanation of each category is necessary.

The first category, creational design patterns, is built on the notion of the creation of objects. The solution in a creational pattern, then, is examined by what is being made. That is, the behavior of a system is described by what kind of objects it is creating(2). For example, the AbstractFactory pattern involves making a single AbstractFactory for each class(5). Then, through polymorphism, it can create whatever object it needs to through one method. So, creation is handled through passing around instances of the AbstractFactory. As one can easily tell, this pattern is centered around the factory creating objects in the program. This is an extremely simple example, but it works well to demonstrate the basics of a creational design pattern.

The next category, structural patterns, tends to be a bit more technical. A structural pattern is a pattern that examines different language mechanisms for structuring code and designing objects(3). Example: The AdapterPattern (also called a wrapper) The AdapterPattern takes some client and an interface that the client understands. It also involves a class that does not understand the interface. Once implemented, the client can then understand the class that previously could not use the interface. Essentially, the Adapter allows two classes to understand each other that could not before(6). With this simple example, one can see the ‘structure’ of how the classes could(n’t) communicate. That is the essence of the structural pattern, the system governing what the classes can and cannot do.

Behavioral design patterns can be based either on class or on objects. With class, behavioral patterns describe how inheritance, algorithms and the flow of control work(4). With behavioral patterns based on objects, the pattern usually describes how the group of objects function together to solve a problem that no class by itself could solve(4). Examine the Chain of Responsibility pattern. In this pattern, there is a sender class and a group of receiver classes. It is unknown what type of object is being sent and how it should be handled. The pattern states that once the object has been sent, each receiver class should examine the object, handle it if possible, and send it to the next receiver if it can’t handle it (7). This pattern is good because it reduces coupling between the sender and receiver. How is this a behavioral pattern? Well, it clearly describes how the receiver objects work to accomplish a goal that they couldn’t do by themselves.

Then, the main difference between these categories of design patterns is how they model the solution to a problem. Creational patterns examine how to create and control instances. Structural problems examine how object function within the rules of a language. And behavioral patterns examine how classes work together to accomplish a goal that no individual one could accomplish.

Interesting Pattern:

Command Pattern

The command pattern involves creating a generic command class with some method that is “do” or “handle.(8)” Since each instance can involve a different set of operations to perform, one can handle anything with this simple generic class. It also makes queuing objects easy, as well as undoing things. I found this pattern interesting because it is particularly useful in network coding. In fact, I used this pattern to handle the communication of a simple client/server system over a TCP/IP socket for a project in 2335. Another of the great advantages of this pattern is its reusability. I was able to use the same basic network code for several different projects that had a client/server networking system. Since it is generic, it is easily portable to other projects.


Link to this Page