HPK taruh disini
The relationship between data items, abstract data types, and data structures.
The ADT defines the logical form of the data type. The data structure implements the physical form of the data type. |
At a higher level of abstraction than ADTs are abstractions for describing the design of programs — that is, the interactions of objects and classes. Experienced software designers learn and reuse various techniques for combining software components. Such techniques are sometimes referred to as design patterns.
A design pattern embodies and generalizes important design concepts for a recurring problem. A primary goal of design patterns is to quickly transfer the knowledge gained by expert designers to newer programmers. Another goal is to allow for efficient communication between programmers. Its much easier to discuss a design issue when you share a vocabulary relevant to the topic.
Specific design patterns emerge from the discovery that a particular design problem appears repeatedly in many contexts. They are meant to solve real problems. Design patterns are a bit like generics: They describe the structure for a design solution, with the details filled in for any given problem. Design patterns are a bit like data structures: Each one provides costs and benefits, which implies that trade offs are possible. Therefore, a given design pattern might have variations on its application to match the various trade offs inherent in a given situation.
Flyweight
The Flyweight design pattern is meant to solve the following problem. You have an application with many objects. Some of these objects are identical in the information that they contain, and the role that they play.
We could imagine describing the layout of text on a page by using a tree structure. The root of the tree is a node representing the page. The page has multiple child nodes, one for each column. The column nodes have child nodes for each row. And the rows have child nodes for each character. These representations for characters are the flyweights. The flyweight includes the reference to the shared shape information, and might contain additional information specific to that instance.
Visitor
Given a tree of objects to describe a page layout, we might wish to perform some activity on every node in the tree. Next we discusses tree traversal, which is the process of visiting every node in the tree in a defined order. A simple example for our text composition application might be to count the number of nodes in the tree that represents the page. At another time, we might wish to print a listing of all the nodes for debugging purposes.
We could write a separate traversal function for each such activity that we intend to perform on the tree. A better approach would be to write a generic traversal function, and pass in the activity to be performed at each node. This organization constitutes the visitor design pattern. The visitor design pattern is used in tree traversal and graph traversal.
Composite
There are two fundamental approaches to dealing with the relationship between a collection of actions and a hierarchy of object types. First consider the typical procedural approach. Say we have a base class for page layout entities, with a subclass hierarchy to define specific subtypes (page, columns, rows, figures, characters, etc.). And say there are actions to be performed on a collection of such objects (such as rendering the objects to the screen). The procedural design approach is for each action to be implemented as a method that takes as a parameter a pointer to the base class type.
Strategy
Our final example of a design pattern lets us encapsulate and make interchangeable a set of alternative actions that might be performed as part of some larger activity. Again continuing our text compositing example, each output device that we wish to render to will require its own function for doing the actual rendering.