Composite

1
Composite

• A Design Pattern

2
Presentation Outline

• Approach a typical programming problem and some
  possible solutions
• Exercises Evaluate the advantages/disadvantages
  of each solution
• Introduce the Composite Design Pattern -
  intuitive notion and formal specification
• Some additional detail
• Exercise Homework Assignment ?

3
A Programming Problem

• A programmer wishes to implement a simple file
  system containing DataFiles and Folders
• Such a system organizes files into a hierarchical
  tree structure as shown to the right

4
A Programming Problem

• Each file in the system has a size
• The file system must be able to calculate the
  total size from any particular folder/file (where
  the total size is the sum of the sizes of all the
  files beneath a particular point in the tree)

5
A First Attempt

• Our first (and rather natural) attempt is to
  create the following
• A class (and interface) for DataFiles
• A class (and interface) for Folders
• Lets pause a moment to examine such an
  implementation

6
Exercise 1

• Spend a minute now to think and jot down briefly
  the advantages and disadvantages this class
  organization has on the implementation

7
Exercise 1

• Lets discuss some of the observations that were
  made!

8
A Second Attempt

• We examine the previous implementation and have
  realized that because the two classes have
  different interfaces, the implementation of some
  methods is rather complex
• We also realize that the two classes have a
  common operation they perform (that being they
  must return their size)

9
A Second Attempt

• So for our new implementation of this problem, we
  focus on having a single interface for both class
  types, so we can treat them uniformly

10
A Second Attempt

• We create the following
• A class called IFSComponent (File System
  Component) which will define a common interface
  for both DataFiles and Folders in our file system
• And as before, a class for DataFiles and a class
  for Folders but this time both extending the
  IFSComponent class
• Lets pause again to look at this second
  implementation

11
Exercise 2

• Again, spend a minute now to think and jot down
  briefly the advantages and disadvantages this
  revised class organization has on the
  implementation

12
Exercise 2

• Lets discuss some of the observations that were
  made!

13
Reviewing

• We have seen that creating a common interface for
  both DataFiles and Folders has made the
  implementation of their methods easier and
  cleaner
• We were able to do so in this case because of the
  common operation (determining size) that
  DataFiles and Folders needed to perform

14
Reviewing

• Such a class organization would be possible with
  other data structures besides trees as well
  (linked lists, arrays, etc.)
• In general, we are dealing with collections or
  compositions of some kind of primitive object (in
  our case it was DataFiles)

15
Reviewing

• The compositions are not restricted simply to
  holding primitives either compositions can
  contain other compositions
• In our case, Folders could contain Folders

16
Reviewing

• By treating objects in the composition uniformly
  (by specifying a common set of methods such as
  getSize()), we make the implementation of these
  classes easier
• We also make it easier for others (clients) who
  are to use or extend the classes to do so

17
Composite Design Pattern

• If you have understood thus far, you probably
  already have a very good idea in mind as to what
  the Composite design pattern is all about!

18
Composite Design Pattern

• More formally, the keys to this design pattern
  are the following
• Primitive objects
• Containers for the primitives (to create
  compositions)
• Operation(s) that are common to both primitive
  objects and compositions
• Most importantly, an abstract class to represent
  BOTH primitives and containers

19
Composite Design Pattern

• Here is the formal class structure of this
  pattern

20
Exercise 3

• Where do the classes and methods in our example
  fit into this diagram?

21
Some Additional Detail

• One might wonder why you declare the methods to
  handle children in the abstract class, when only
  the composite class has any use for them is it
  not poor programming practice to have these
  methods inherited by primitive classes, which
  have no use for them?
• There is a tradeoff here between safety and
  transparency

22
Some Additional Detail

• Safety
• If the child management methods are moved from
  the abstract class to the composite one, the
  client can no longer call these methods on
  primitive objects, improving the safety
• However, this gives primitive and composite
  objects different interfaces which is what the
  design pattern is to avoid

23
Some Additional Detail

• Transparency
• Leaving the child management methods in the
  abstract class improves transparency, because all
  objects can then be treated the same way by the
  client
• Unfortunately, this allows the possibility of the
  client calling these methods on primitive types
  (which would be meaningless)

24
Some Additional Detail

• The Composite Design Pattern, as documented by
  the Gang of Four, chooses the benefits of
  transparency over safety child management
  methods are declared in the abstract Component
  class and inherited by all classes

25
Exercise 4

• The required Homework Assignment (sorry!)
• Submit your answers for the previous Exercises
  (1, 2 3)
• There is also a coding assignment, which we will
  go through with you now

26
The fun begins................

• Reminder
• Q 8. Does all (non)members have access to
  equal amount of information or certain
  information is accessible to ECs only, or members
  only or ECs and members only? If so, what are
  they?
• Arvnad It is reasonable to assume that some
  info are only accessable by ECs. Also its good to
  make the system in a way that some members can
  view more info than others. This is better to be
  event based and be assigned by an EC.

27
(No Transcript)