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 4 - Benjamin J McMillan

Midterm Review - Spring 2003 - Design principles:

Coupling:

This is measure of how dependent one module is to another. Low coupling (aka "loose") means the modules in the system are not heavily dependent on the other modules, such that if a module was changed, removed, replaced, etc the other modules would still operate, thus achieving robustness. High coupling (aka "tight") means the modules are heavily depedent on other modules, and doing anything to those dependent modules would break the others. Low coupling is what you should try to achieve when designing a system. Adhering to the other design principles mentioned throughout this text can aid in achieving low coupling.

Cohesion:

This is a measure of how similar procedures/data are in a module. Different types of similarity exist, but most often it is used to mean similar in responsibility. High cohesion is what you should try to achieve. Low cohesion, on the other hand, represents very little organization of actions/responsibilities within a system. That would be like writing
all the methods, and placing them into random modules. This increases complexity (unnecessarily) and increases maintainability (that is, it'll be easier to maintain).

Encapsulation / Information Hiding & Abstraction:

In order for a system to be robust and maintainable, that system's design must utilize encapsulation. Encapsulation, like cohesion (communicational and functional), represents the grouping of data and methods together into modules in a sensible manner. If you have some data that can be somehow manipulated or queried, the data and the methods by which to manipulate such data should exist in the same module / class. Likewise, all similar data (and their appropriate methods) should exist in the same class.

Information hiding, although closely related to encapsulation, isn't synonymous to such. Rather, information hiding is the hiding of implementation/structure and data. Of course, you might want to access data from outside the class, but you should provide public getters and setters for such data, while the data itself is protected (Java: private/protected keywords).

Abstraction is the ability for one class or method to ignore the details of another class or method and just focus on what is necessary for that particular moment. The most basic example of abstraction, in a procedural since, is by calling a hypothetical 'sort' function. We don't [most likely] care if the sort function uses bubble, quick, or merge (or whatever) to do the sorting, we just care about the returned collection.

The implementation of all 3 of these concepts can help facilitate a robust (low coupling, stable interface), maintainable (high cohesion) design.

Open-Closed principle:

The open-closed principle dictates that a proper design should allow for (be open to) extension, but be closed for modification. For instance, let's suppose we have a Shape object that had an attribute that could be Square, Rectangle, Circle, or Triangle. What if we just discovered (or needed) the Rombus shape? We would have to modify the Shape class and add that to the possible list of shapes. This is BAD. However, if we made the Shape an abstract class, and implemented many subclasses (one for Square, one for Circle, etc) we would just have to add a Rombus class by extending the Shape class.

Delegation:

Delegation is the process of transferring responsibility to another entity. For instance, let's suppose we have an XML reader that has a method for reading an element, and has a collection of modules, each responsible for a different namespace. Each of those modules also has a method for reading an element, but are specialized for a particular namespace. The client asks the XML reader for information about an element, the XML reader then looks at the namespace of the element, looks for the appropriate namespace module, and gives the raw element data to that module's element reader method. The higher level XML reader doesn't have to know about the details of all namespaces, and just has to know who does. This is akin to a president delegating the task of writing a speech to his/her speech writer, the task of typing his/her notes to his/her secretary, and so on.

Links to this Page