Specifying Class / Object Implementations :
A class as a rectangle with the class name in bold. Operations appear in normal type below the class name. Any data that the class defines comes after the operations. Lines separate the class name from the operations and the operations from the data:
Class relationships are represented by following connectors:
You have to be careful about the shapes of the arrow tips. The inheritance arrow is closed, whereas dependency arrow is open. Also note that the arrow tips for inheritance and dependency are at the end of the dependent class, but the diamond for aggregation is at the end of the aggregating class.
For the "has" relationship(aggregation), you can also write the cardinality on the end points of the connection. The most common choices for the cardinality are:
Cardinalities of an aggregation relationship
Some designers differentiate between aggregation and containment. Containment is a stronger form of aggregation where the contained objects do not have an existence independent of their container. For example, in the mail system, the message queues are contained in the mailboxes�a message queue never exists outside a mailbox. But messages move throughout the mail system and don't always reside in a message queue. Thus, a message queue does not contain message objects. The UML notation for containment(Composition) is a line with a solid diamond at the end (see figure 4). We will not make that distinction in this course, but you may encounter it elsewhere.
Composition
Some designers do not like the aggregation relationship because they feel it is too implementation-specific. UML defines a more general association between classes. An association is drawn as a solid line without a diamond. You can write roles at the ends of the lines (see figure 5). Here we model the fact that students are participants of courses, and that courses make up a student's schedule. Early during a design, this general relationship makes a lot of sense. As you move closer to implementation, you will want to resolve whether a Course object manages a collection of students, a Student object manages a collection of courses, or both.
An association with roles
Occasionally, an association is directed, that is, it can only be navigated in one way. For example, a message queue needs to be able to locate the messages inside, but a message need not know in which message queue it is. A directed association is drawn with an open arrow tip (see figure 6). It is easy to confuse that connector with inheritance�you have to pay close attention to the shapes of the arrow tips when drawing UML diagrams.
A directed association
Finally, if a class realizes an interface, you draw a dotted arrow with a closed arrow tip. Add the stereotype descriptor�interface� above the interface name. (The � and � characters are called guillemets or French quotation marks. They have Unicode values \u00AB = 171 and \u00BB = 187.)
You have to be careful about the shapes of the arrow tips. The inheritance arrow is closed, whereas dependency arrow is open. Also note that the arrow tips for inheritance and dependency are at the end of the dependent class, but the diamond for aggregation is at the end of the aggregating class.
For the "has" relationship, you can also write the cardinality on the end points of the connection. The most common choices for the cardinality are:
Conversely, when you do model an aggregation, you should not also classify the same relationship as an attribute. Suppose a mailbox has two message queues, one for new messages and one for saved messages. Then you can either draw an aggregation line between Mailbox and MessageQueue, or you can give the Mailbox class two attributes newMessages, savedMessages, but you can't do both at the same time.
Some designers differentiate between aggregation and containment. Containment is a stronger form of aggregation where the contained objects do not have an existence independent of their container. For example, in the mail system, the message queues are contained in the mailboxes�a message queue never exists outside a mailbox. But messages move throughout the mail system and don't always reside in a message queue. Thus, a message queue does not contain message objects. The UML notation for containment is a line with a solid diamond at the end (see figure 4). We will not make that distinction in this course, but you may encounter it elsewhere.
Realizing an interface
We classify design patterns by two criteria (Table 1.1). The first criterion, called purpose, reflects what a pattern does. Patterns can have either creational, structural, or behavioral purpose. Creational patterns concern the process of object creation. Structural patterns deal with the composition of classes or objects. Behavioral patterns characterize the ways in which classes or objects interact and distribute responsibility.
Creational class patterns defer some part of object creation to subclasses, while Creational object patterns defer it to another object. The Structural class patterns use inheritance to compose classes, while the Structural object patterns describe ways to assemble objects. The Behavioral class patterns use inheritance to describe algorithms and flow of control, whereas the Behavioral object patterns describe how a group of objects cooperate to perform a task that no single object can carry out alone.
There are other ways to organize the patterns. Some patterns are often used together. For example, Composite is often used with Iterator or Visitor. Some patterns are alternatives: Prototype is often an alternative to Abstract Factory. Some patterns result in similar designs even though the patterns have different intents. For example, the structure diagrams of Composite and Decorator are similar.
1. Factory Method : If we have different products to create and want to abstract out the product details from client, an abstract factory method will be provided, which will create the appropriate product and will return a generic instance to client.
Factory method will create the concrete product and will return the base product to the client.
2. Abstract Factory : If client needs to create a family of related products, there will be one abstract factory and a set of concrete factories, client will chose the factory for the family of products.
AbstractFactory classes are often implemented with factory methods (Factory Method (107)), but they can also be implemented using Prototype (117).
A concrete factory is often a singleton (Singleton (127)). *Note : Refer implementation section for details.
3. Singleton : Ensure a class only has one instance, and provide a global point of access to it.
The
A class as a rectangle with the class name in bold. Operations appear in normal type below the class name. Any data that the class defines comes after the operations. Lines separate the class name from the operations and the operations from the data:
Return types and instance variable types are optional, since we don't assume a statically typed implementation language.
Objects are created by instantiating a class. The object is said to be an instance of the class. The process of instantiating a class allocates storage for the object's internal data (made up of instance variables) and associates the operations with these data. Many similar instances of an object can be created by instantiating a class.
Class relationships are represented by following connectors:
You have to be careful about the shapes of the arrow tips. The inheritance arrow is closed, whereas dependency arrow is open. Also note that the arrow tips for inheritance and dependency are at the end of the dependent class, but the diamond for aggregation is at the end of the aggregating class.
For the "has" relationship(aggregation), you can also write the cardinality on the end points of the connection. The most common choices for the cardinality are:
- any number (zero or more): *
- one or more: 1..*
- zero or one: 0..1
- exactly one: 1
Cardinalities of an aggregation relationship
Some designers differentiate between aggregation and containment. Containment is a stronger form of aggregation where the contained objects do not have an existence independent of their container. For example, in the mail system, the message queues are contained in the mailboxes�a message queue never exists outside a mailbox. But messages move throughout the mail system and don't always reside in a message queue. Thus, a message queue does not contain message objects. The UML notation for containment(Composition) is a line with a solid diamond at the end (see figure 4). We will not make that distinction in this course, but you may encounter it elsewhere.
Composition
Some designers do not like the aggregation relationship because they feel it is too implementation-specific. UML defines a more general association between classes. An association is drawn as a solid line without a diamond. You can write roles at the ends of the lines (see figure 5). Here we model the fact that students are participants of courses, and that courses make up a student's schedule. Early during a design, this general relationship makes a lot of sense. As you move closer to implementation, you will want to resolve whether a Course object manages a collection of students, a Student object manages a collection of courses, or both.
An association with roles
Occasionally, an association is directed, that is, it can only be navigated in one way. For example, a message queue needs to be able to locate the messages inside, but a message need not know in which message queue it is. A directed association is drawn with an open arrow tip (see figure 6). It is easy to confuse that connector with inheritance�you have to pay close attention to the shapes of the arrow tips when drawing UML diagrams.
A directed association
Finally, if a class realizes an interface, you draw a dotted arrow with a closed arrow tip. Add the stereotype descriptor�interface� above the interface name. (The � and � characters are called guillemets or French quotation marks. They have Unicode values \u00AB = 171 and \u00BB = 187.)
You have to be careful about the shapes of the arrow tips. The inheritance arrow is closed, whereas dependency arrow is open. Also note that the arrow tips for inheritance and dependency are at the end of the dependent class, but the diamond for aggregation is at the end of the aggregating class.
For the "has" relationship, you can also write the cardinality on the end points of the connection. The most common choices for the cardinality are:
- any number (zero or more): *
- one or more: 1..*
- zero or one: 0..1
- exactly one: 1
Figure 3. Cardinalities of an aggregation relationship
While aggregation relationships are implemented as fields, not all fields of a class should automatically be drawn as aggregations in a class diagram. For example, suppose the class Message has a field timestamp of type Date. Generally, you don't model aggregation with foundational types such as strings, dates or numbers. Therefore, you should not draw boxes for the Message and Date classes and join them by an aggregation line. Simply describe the timestamp as an attribute instead.Conversely, when you do model an aggregation, you should not also classify the same relationship as an attribute. Suppose a mailbox has two message queues, one for new messages and one for saved messages. Then you can either draw an aggregation line between Mailbox and MessageQueue, or you can give the Mailbox class two attributes newMessages, savedMessages, but you can't do both at the same time.
Some designers differentiate between aggregation and containment. Containment is a stronger form of aggregation where the contained objects do not have an existence independent of their container. For example, in the mail system, the message queues are contained in the mailboxes�a message queue never exists outside a mailbox. But messages move throughout the mail system and don't always reside in a message queue. Thus, a message queue does not contain message objects. The UML notation for containment is a line with a solid diamond at the end (see figure 4). We will not make that distinction in this course, but you may encounter it elsewhere.
Figure 4. Composition
Some designers do not like the aggregation relationship because they feel it is too implementation-specific. UML defines a more general association between classes. An association is drawn as a solid line without a diamond. You can write roles at the ends of the lines (see figure 5). Here we model the fact that students are participants of courses, and that courses make up a student's schedule. Early during a design, this general relationship makes a lot of sense. As you move closer to implementation, you will want to resolve whether a Course object manages a collection of students, a Student object manages a collection of courses, or both.
Figure 5. An association with roles
The relationship between courses and students is bidirectional�Course objects will need to know about the students in the course, and Student objects need to know about the courses for which they are registered. Occasionally, an association is directed, that is, it can only be navigated in one way. For example, a message queue needs to be able to locate the messages inside, but a message need not know in which message queue it is. A directed association is drawn with an open arrow tip (see figure 6). It is easy to confuse that connector with inheritance�you have to pay close attention to the shapes of the arrow tips when drawing UML diagrams.
Figure 6. A directed association
Finally, if a class realizes an interface, you draw a dotted arrow with a closed arrow tip. Add the stereotype descriptor�interface� above the interface name. (The � and � characters are called guillemets or French quotation marks. They have Unicode values \u00AB = 171 and \u00BB = 187.) Many designers write interface names in italics, but that is not a UML requirement. Figure 7 shows an example.Realizing an interface
We classify design patterns by two criteria (Table 1.1). The first criterion, called purpose, reflects what a pattern does. Patterns can have either creational, structural, or behavioral purpose. Creational patterns concern the process of object creation. Structural patterns deal with the composition of classes or objects. Behavioral patterns characterize the ways in which classes or objects interact and distribute responsibility.
Table 1.1: Design pattern space
The second criterion, called scope, specifies whether the
pattern applies primarily to classes or to objects. Class patterns
deal with relationships between classes and their subclasses. These
relationships are established through inheritance, so they are
static—fixed at compile-time. Object patterns deal with object
relationships, which can be changed at run-time and are more dynamic.
Almost all patterns use inheritance to some extent. So the only
patterns labeled "class patterns" are those that focus on class
relationships. Note that most patterns are in the Object scope.Creational class patterns defer some part of object creation to subclasses, while Creational object patterns defer it to another object. The Structural class patterns use inheritance to compose classes, while the Structural object patterns describe ways to assemble objects. The Behavioral class patterns use inheritance to describe algorithms and flow of control, whereas the Behavioral object patterns describe how a group of objects cooperate to perform a task that no single object can carry out alone.
There are other ways to organize the patterns. Some patterns are often used together. For example, Composite is often used with Iterator or Visitor. Some patterns are alternatives: Prototype is often an alternative to Abstract Factory. Some patterns result in similar designs even though the patterns have different intents. For example, the structure diagrams of Composite and Decorator are similar.
1. Factory Method : If we have different products to create and want to abstract out the product details from client, an abstract factory method will be provided, which will create the appropriate product and will return a generic instance to client.
Factory method will create the concrete product and will return the base product to the client.
2. Abstract Factory : If client needs to create a family of related products, there will be one abstract factory and a set of concrete factories, client will chose the factory for the family of products.
AbstractFactory classes are often implemented with factory methods (Factory Method (107)), but they can also be implemented using Prototype (117).
A concrete factory is often a singleton (Singleton (127)). *Note : Refer implementation section for details.
3. Singleton : Ensure a class only has one instance, and provide a global point of access to it.
The
Singleton class is declared as
class Singleton {
public:
static Singleton* Instance();
protected:
Singleton();
private:
static Singleton* _instance;
};
The corresponding implementation is Singleton* Singleton::_instance = 0;
Singleton* Singleton::Instance () {
if (_instance == 0) {
_instance = new Singleton;
}
return _instance;
}
Also make Instance as a property and update Get method accordingly.
4. Prototype : It can be used like Abstract Factory pattern.
5.Builder : Separate the construction of a complex object from its representation so that the same construction process can create different representations.
Abstract Factory (87) is similar to Builder in that it too may construct complex objects.The primary difference is that the Builder pattern focuses on constructing a complex object step by step. Abstract Factory's emphasis is on families of product objects (either simple or complex). Builder returns the product as a final step, but as far as the Abstract Factory pattern is concerned, the product gets returned immediately.
6. Composite : Composite lets clients treat individual objects and compositions of objects uniformly.
7. Chain Of Responsibility : Avoid coupling the sender of a request to its receiver by giving more than one object a chance to handle the request. Chain the receiving objects and pass the request along the chain until an object handles it.
Use Chain of Responsibility when
- more than one object may handle a request, and the handler isn't known a priori. The handler should be ascertained automatically.
- you want to issue a request to one of several objects without specifying the receiver explicitly.
- the set of objects that can handle a request should be specified dynamically.
- A typical object structure might look like this:
8. Decorator:
9. Adapter:
10. Bridge:
11. Facade:
12. Proxy:
