Understanding the State and Composite Design Patterns in Software Development
The State and Composite design patterns are key concepts in software architecture, enhancing flexibility and organization. The State pattern allows an object to alter its behavior based on its internal state, enabling different responses tailored to its current conditions. For example, a Room may have states like Alright, SomeFaults, and ManyFaults, influencing its maintenance operations. The Composite pattern, on the other hand, facilitates complex tree structures, treating individual objects and compositions uniformly, simplifying operations on hierarchical structures. Together, they promote robust and scalable software design.
Understanding the State and Composite Design Patterns in Software Development
E N D
Presentation Transcript
State Pattern • Intent • Alter behaviour of an object when its internal state changes • Object appears to change its class • Alternate names Objects for states
State – Motivation • An object may be in one of many states. It responds differently depending upon its current state • Example • A Room can be in one of the states • Alright, SomeFaults, ManyFaults • A request to paint the room is made • Alright state – clean and paint room • SomeFaults– repair yourself and paint room • ManyFaults– hire contractor and paint room
+ ALRIGHT + SOME_FAULTS + MANY_FAULTS paint + furnish + paint + furnish + paint + furnish + State – Example Structure state + ROOM * ROOM_STATE paint * furnish * paint furnish
* STATE operation * + A_STATE operation + State – Abstract Structure state + CONTEXT operation state.operation
State – Participants • Context Defines client interface • Deferred State Defines interface for common behaviour for different states • Effective State Implements behaviour of that state in context
State – Collaborations • Context delegates state specific behaviour to a concrete state object • Context may pass itself as an argument so that state can access context features • Context is the primary interface with clients • Clients configure context with state objects • Clients do not deal directly with state objects • Context or concrete state can decide which state follows another state
State – Applicability • Object has different behaviour depending on state • Operations have multi-part conditional statement dependent upon state • State is represented by an enumerated constant • Several operations have same conditional structure • Pattern puts each branch of the conditional into a separate class • Object’s state becomes an object that can vary independently of other objects
State – Related Patterns • State objects are often Singletons • Frequently, state classes do not contain any attributes • As a result, state objects of the same type are all the same • To avoid having many different objects that are exactly the same, one can make such classes singletons
Composite Pattern • Intent • Compose objects into tree structures representing part-whole hierarchies • Clients deal uniformly with individual objects and hierarchies of objects
Composite – Motivation • Applications that have recursive groupings of primitives and groups • Drawing programs lines, text, figures and groups • Eiffel static structure classes and clusters • Operations on groups are different than primitives but users treat them in the same way
DIAGRAM DIAGRAM DIAGRAM DIAGRAM TEXT LINE OVAL OVAL TEXT TEXT Composite – Drawing Example
CLIENT COMPOSITE[T] * GRAPHIC * add * remove * iterate * draw * DIAGRAM + draw + add + remove + iterate + Composite – Example Architecture T TEXT + OVAL + LINE + draw + draw + draw +
COMPONENT * CLIENT op_1 * op_2 * COMPOSITE[T] * add * remove * iterate * Composite – Abstract Architecture T LEAF + COMPOSITE_COMPONENT + op_1 + op_2 + op_1 + op_2 + add + remove + iterate +
Composite – Applicability • Represent part-whole hierarchies of objects • Clients can ignore difference between individual objects and compositions • Clients deal with all objects in a composition in the same way
Composite – Participants • Component Defines properties of an entity • Leaf Defines properties of a primitive entity • Composite Declares properties of a collection of entities • Composite Component Combines properties of a collection of entities and properties of a primitive entity • Client Uses component and composite properties
Composite – Consequences • Whenever client expects a primitive it can accept a composite • Client is simplified by removing tag-case statements to identify parts of the composition • Easy to add new components by subclassing, client does not change • If compositions are to have restricted sets of components have to rely on run-time checking
Composite – Related Patterns • Decorator is a degenerate Composite (only one component) • Visitor localizes operations that would be distributed across composite and leaf classes
