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

Amlan Dasgupta

Discussion #2
Part 1

What are the differences between creational, structural, and behavioral patterns?
Creational design patterns generally deal with the creation of an instance of an object. These design patterns are meant to handle the creation of a specific object in a way that makes sense for the current situation. Singletons and factories are some examples of this type of design pattern.

Structural patterns enable us to find similarities between different classes and use them to form a similar interface between them. Bridges and Adapters are examples of these types of design patterns. They allow for new functionality to rise from these interfaces. Bridges and Adapters are some exaples of this design pattern.

Behavorial patterns help to create the connections and communication between two separate classes. Much of these patterns is about creating algorithms and assigning responsibilities to objects. Iterators and observers are examples of these.

Part 2
Describe one design pattern or pattern language in your own words. Again, reference your sources. Explain what interests you about this pattern. Does it make sense to you? Can you see using it in your coding? If so, what for? If not, why not?

The singleton is a design pattern that I have used in several Java projects. This design pattern is useful when one knows that there will never be more than one instance of a certain object. This allows the use of class methods that return the only instance of the class. In these projects, I found that this design pattern was very useful. For example, in several projects for CS2335, we created server-client models that needed to communicate with each other. Since we knew that there would never be more than 1 server running on a machine at a time, it was advantageous to us to use the singleton design pattern here.

References:
http://my.execpc.com/~gopalan/design/behavorial.html
http://my.execpc.com/~gopalan/design/creational.html
http://my.execpc.com/~gopalan/design/structural.html




Discussion #4
Question taken from Summer 2003 Midterm Review

Design Critique

What is wrong with the following and how do you fix it?


1. We decided to have one shape class and have a type attribtue which can be "Circle", "Rectangle", "Triagle". We have to case on the type to figure out what to draw. Later we need to case on the type again to output the postscript.

This design doesn't use the idea of inheritance properly. This design makes is difficult to add any new shapes, as a user would have add case statements to several different places within the code. The designer should have created separate Circle, Rectangle, and Triangle classes that would inherit from a Shape class. The Shape class should have a method to get the postscript. The inheriting methods should override this method.


2. Boxes need to use a pen so we had Box inherit from Pen.

Inheritance should only be used when there is a " is a " relationship between two classes. However, a box is not a pen, so inheritance would not be an appropriate tool to use here. Instead, the relationship between Box and Pen is that a Box has a Pen. Because of this, we should add an instance variable to Box that refers to a Pen object.


3. We got lots of coding done because we were able to copy code to many different classes.

Having to copy lots of code from different classes is ussually a sign of bad design. Often, this means that the design was built poorly for the purpose of extendability. The designer could have created a better design by possibly using inheritance more, so methods would be inherited and the code in those methods would not have to be copied several times.


4. We really only needed one "main" class and a couple of helper classes.

This is ussually a bad idea, since this often means that the few helper classes have too much in them and should be split up into several different classes. Also, this design suggests that the main class is very large and should likely be broken up into several different classes. By splitting up the project into several different classes, the project would become easier to extend and maintain.


5. We call the class that edits the image part of the slide "EditBackground".

This should not be a class of itself. The image class should have a method that edits its background. The relationship between an image and editBackground is that edit background is a task that an image can do. For this reason, edit background should be an instance method of the image class.



Discussion #5
Team ASDF - Milestone #3 Case

Links to this Page