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

Russell Myers' Discussion 2

Discussion 2: Design Patterns and the Portland Form


The Portland Form

The Portland Form is a very useful way of writing about a particular design pattern. It offers an easy way to characterize a particular problem and then explain the solution to that particular problem. Design patterns explain common problems in the way we would understand other, easier to understand problems. Taking from the general design pattern ideas, the Portland Form simply explains a way on how to document these problems for others as a sort of reference. This comes directly from the Portland Pattern Repository's page on the subject.

The Portland Form would be useful for nearly any programming language. It seems that you can make quite a few generalizations about almost any Object-Oriented programming language. The simple idea here is "explaination". This carries through to larger, more complex problems which become broken down into smaller, easier to understand portions.

I feel the idea of the Portland Form, when catalogued, is analogous to a library. A library contains many different books, which relate to topics on particular design pattern problems and solutions. Within each of these books (be it a short book, or long), there are generally chapters – meaning, the problem is broken down into sub-sections. Much like a book, you can understand a timeline of a story or a particular topic in simply one section; it makes sense to break it down if needed.


The Factory Method Pattern

Wikipedia's explaination describes it best:
"The Factory Method pattern is an object-oriented design pattern. Like other creational patterns, it deals with the problem of creating objects (products) without specifying the exact class of object that will be created. Factory Method, one of the patterns from the Design Patterns book, handles this problem by defining a separate method for creating the objects, which subclasses can then override to specify the type of product that will be created."
This particular design pattern deals with creating a "production line" that easily creates objects through abstraction. Using this method, one can abstract a single class that fits the purposes of all products that may need be created in the future. Then, when, in the design progression, the product need production, a subclass is created to handle that need. Thus, the addition of more production creations is simplified into a simple extension method from the abstract object that describes the process. Individual product needs are met, yet time is cut down from the lack of repetitive programs.

This design pattern makes complete sense and seems almost obvious for something like the database example they mentioned (I happen to be taking a databases class). Creating objects that extend in this way, you can easily take data from multiple types of fields in multiple types of database "tasks" with simple extension. It just makes sense. Its interesting to me because of the amount of work that is saved in this particular design process, and I will likely use this exact method within the next few months.

Links to this Page