Aggregate Relations
I’m tempted to say that
aggregation is a stronger form of
acquaintance, and that wouldn’t be far from wrong. In fact, in certain contexts it may be perfectly correct. Gamma,
et al point out that the differences between the two
is a matter of intent rather than explicit language mechanisms. That makes it a little tricky simply to show some code and pronounce,
“See that’s what an aggregate looks like.” So bear with me as we look at aggregate relations.
Conjoined Participants
As can be seen in the red arrow symbols in the Participant Relations diagram at the top of this post, an aggregate relation is indicated by an arrow with a diamond at its base. The GoF illustrate the relationship as shown in Figure 1:
Figure 1: Aggregator and Aggregatee
The Aggregator creates an aggregate instance of the Aggregatee. As noted, GoF point out that no single code set can demonstrate what an aggregate relationship looks like, but I think that we can get a start by looking at a fairly simple relationship in the State design I created so that we could discuss both aggregate relations and delegation. (The Strategy design also provides a good example of aggregation with delegation.)
Continue reading ‘ActionsScript 3.0 Design Pattern Relations Part II: Aggregation’
Class Relations
This post is the first in a series where I hope to discuss all of the key relationships between classes in Design Patterns. To help identify posts in this series I’ve created a general diagram with all of the different kinds of relationships between classes. I did not include the boxes for pseudo-code or divide the classes into areas for operations and properties. The purpose is to focus on the relationships in this series. You may have noticed that the chart is titled,
Participant Relations, and by
Participant, I’m referring to any class or interface in a design pattern using the Gang of Four’s terminology. In order to help you quickly see the current relationship topic, the Participant Relations diagram shows the currently discussed relations in red.
UML Controversy: Tempest in a Teapot
In this and subsequent posts, I’m sticking with the notations used by GoF. If you’re into UMLs, you’ll know that GoF actually use a few non-standard notations, but I think that by using the ones GoF use our discussion will be less confusing. If you’re interested in a more standardized UML notation take a look at Judith Bishop’s book, C# 3.0 Design Patterns (O’Reilly) on pp.4-5.
GoF discuss abstract classes and interfaces as interfaces. So, in an example where an abstract class is used, you’ll see an italicized class name. If an interface is used, you’ll see the same thing. In some respects this can be quite helpful in that when you see any italicized text in a class diagram you’ll think interface and know that you can develop your own design pattern using either an abstract class or interface.
The inheritance symbol, that we’ll be covering in detail in a later post, is used to denote both inheritance (extends) and implementation (implements). This is consistent with GoF’s interchangable use of abstract classes and interfaces and their notations. So bear with me on these idiosyncrasies and help focus on the relationships between participants.
Continue reading ‘ActionsScript 3.0 Design Pattern Relations Part I: Acquaintances’
Bill Sanders
Recent Comments