Downloaded 19 times
Uploaded byAlok Guha
Design patterns
The document discusses design patterns and their history. It mentions that design patterns were first documented by Christopher Alexander in the 1970s and later defined by the "Gang of Four" (GoF) in their 1994 book Design Patterns: Elements of Reusable Object-Oriented Software. The document then provides descriptions of what a design pattern is, why they are used, their different purposes (creational, structural, behavioral), and scope (class vs object level). It also includes brief summaries of some specific design patterns like Singleton, Factory Method, Abstract Factory, Builder, Prototype, Facade, Proxy, Adapter, and Bridge.
Design patterns
- 2. 1994 • Design Patterns: Elements of 1987 Reusable Object- • Kent Beck and Oriented Ward Cunningham Software by GoF – Erich Gamma, Richard Helm, 1970’s Ralph Johnson and John Vlissides • Christopher Alexander
- 3. What? • Recurring Solutionto a Problem in a Context • Context – A situation in which a pattern applies. Ex – You have a collection of objects • Problem – Unsettled question that is constrained by context. Ex – You need to step through the collection without exposing the collection’s implementation • Solution – The answer to problem. Ex – Encapsulate the iteration into a separate class Why? • Leverage a proven solution • Provide a common vocabulary
- 5. Purpose • Creational –Abstract object instantiation. Provide a way to decouple a client from the object it needs to instantiate • Structural – Concerned with composing classes or objects into larger structures • Behavioral – Concerned with how classes and objects interact and distribute responsibility Scope • Class – Relationship between classes is established through inheritance and at compile time • Object – Relationship between objects are primarily by composition and at runtime.
- 6. Singleton Factory Method Abstract Factory Builder Prototype
- 7. Intent Ensure a class only has one instance, and provide a global point of access to it.
- 9. Java API • Java.lang.Runtime– getRuntime() • Class class Others • Spring ApplicationContext • Spring beans • Struts action classes
- 10. Multi- Serialization threading Multiple Cloning classloaders
- 11. Intent Define an interface for creating an object, but let subclasses decide which class to instantiate. Factory Method lets a class defer instantiation to subclasses.
- 13. Java API • Collection.iterator() •DriverManager.getConnection() • Java.sql.Driver – connect () returns java.sql.Connection • NamingManager.getInitialContext() • Hashtable env = new Hashtable(); • env.put(Context.INITIAL_CONTEXT_FACTORY, "com.sun.jndi.ldap.LdapCtxFactory"); • javax.xml.parsers.SAXParserFactory
- 14. • A classcan't anticipate the class of objects it must create. • A class wants its subclasses to specify the objects it creates. Applicability
- 15. Simple Factory Idiom- Something that appears to be factory method pattern, but is not. Manifests as a (most probably) static creation method that returns a type that varies based on the arguments Example – • ResourceBundle.getBundle(name, locale)
- 16. Eliminates need towork with concrete classes. Provides hook for subclasses for providing extended version of an object. Could result in proliferation of subclasses created just to create a particular concrete product. Connects parallel class hierarchies.
- 17. Intent Provide an interface for creating families of related or dependent objects without specifying their concrete classes.
- 19. org.w3c.dom.Document java.awt.Toolkit createElement createButton createAttribute createCheckbox createDialog
- 20. • A systemshould be independent of how its products are created, composed, and represented. • A system should be configured with one of multiple families of products. • A family of related product objects is designed to be used together, and you need to enforce this constraint. • You want to provide a class library of products, and you want to reveal just their interfaces, not their implementations. Applicability
- 21. Isolates concrete classesfrom clients. Makes exchanging product families easy. It promotes consistency among products. Supporting new kinds of products is difficult.
- 22. Intent Specify the kinds of objects to create using a prototypical instance, and create new objects by copying this prototype.
- 24. Java API • java.lang.Cloneable* •java.io.Serializable* • * - More of means to prototyping than examples
- 25. • when instancesof a class can have one of only a few different combinations of state. It may be more convenient to install a corresponding number of prototypes and clone them rather than instantiating the class manually, each time with the appropriate state. • to avoid building a class hierarchy of factories that parallels the class hierarchy of products. • Sometimes classes are specified at runtime and are created with dynamic loading (Class.forName) or a similarly expensive process (when initial state is specified in an XML file, for example). Rather than repeatedly going through the expense of creating an object, create a single prototype and copy it multiple times. Applicability
- 26. Can reduce objectcreation time Reduced sub-classing - Factory Method often produces a hierarchy of Creator classes that parallels the product class hierarchy. The Prototype pattern lets you clone a prototype instead of asking a factory method to make a new object. Hence you don't need a Creator class hierarchy at all. Implementation complexities – Shallow copy or Deep copy Allows adding and removing products at run-time
- 27. Intent Separate the construction of a complex object from its representation so that the same construction process can create different representations.
- 29. StringBuilder Java.lang.ProcessBuilder • ProcessBuilder pb= new ProcessBuilder("myCommand", "myArg1", "myArg2"); • Map env = pb.environment(); • env.put("VAR1", "myValue"); • env.remove("OTHERVAR"); • env.put("VAR2", env.get("VAR1") + "suffix"); • pb.directory(new File("myDir")); • Process p = pb.start();
- 30. • Runtime controlover the creation process is required. • The algorithm for creating a complex object should be independent of the parts that make up the object and how they're assembled. • The construction process must allow different representations of the product being constructed. Applicability
- 31. Allows finer controlover the construction process Isolates code for construction and representation Lets you vary a product's internal representation
- 32. Façade Proxy Adapter Decorator Bridge Composite Flyweight
- 33. Intent Provide a unified interface to a set of interfaces in a subsystem. Facade defines a higher- level interface that makes the subsystem easier to use.
- 35. Almost every APIwe see and use on daily basis JDBC JMS JNDI
- 36. • A simpleinterface is needed to provide access to a complex system. • There are many dependencies between system implementations and clients. • Systems and subsystems should be layered. Applicability
- 37. Shields clients fromsubsystem components, thereby reducing the number of objects that clients deal with and making the subsystem easier to use. Promotes weak coupling between the subsystem and its clients. It doesn't prevent applications from using subsystem classes if they need to. Thus you can choose between ease of use and generality.
- 38. Intent Provide a surrogate or placeholder for another object to control access to it.
- 40. Java API • DynamicProxies – Mechanism to create proxies Spring AOP Hibernate • Every entity reference at runtime EJB • EJBObject • EJBHome
- 41. • The objectbeing represented is external to the system - Remote Proxy • Objects need to be created on demand - Virtual Proxy • Access control for the original object is required - Protection Proxy • Added functionality is required when an object is accessed - Smart References Applicability
- 42. Introduces a levelof indirection A remote proxy can hide the fact that an object resides in a different address space. A virtual proxy can perform optimizations such as creating an object on demand. Both protection proxies and smart references allow additional housekeeping tasks when an object is accessed.
- 43. Intent Convert the interface of a class into another interface clients expect. Adapter lets classes work together that couldn't otherwise because of incompatible interfaces
- 44. • defines thedomain- Target specific interface that Client uses • collaborates with objects conforming Client to the Target interface • defines an existing Adaptee interface that needs adapting • adapts the interface Adapter of Adaptee to the Target interface
- 45. Java API StringInputStream/Reader ByteArrayInputStream CharArrayReader
- 46. • You wantto use an existing class, and its interface does not match the one you need. • You want to create a reusable class that cooperates with unrelated or unforeseen classes, that is, classes that don't necessarily have compatible interfaces. • (object adapter only)You need to use several existing subclasses, but it's impractical to adapt their interface by subclassing every one. An object adapter can adapt the interface of its parent class. Applicability
- 47. Class Adapters • AdaptsAdaptee to Target by committing to a concrete Adapter class. As a consequence, a class adapter won't work when we want to adapt a class and all its subclasses. • Lets Adapter override some of Adaptee's behavior, since Adapter is a subclass of Adaptee. Object Adapters • Lets a single Adapter work with many Adaptees—that is, the Adaptee itself and all of its subclasses (if any). The Adapter can also add functionality to all Adaptees at once. • Makes it harder to override Adaptee behavior. It will require subclassing Adaptee and making Adapter refer to the subclass rather than the Adaptee itself.
- 48. Intent Attach additional responsibilities to an object dynamically. Decorators provide a flexible alternative to subclassing for extending functionality.
- 49. •Defines the interfacefor objects that can have responsibilities Component added to them dynamically. •Defines an object to which additional responsibilities can be ConcreteComponent attached. •Maintains a reference to a Component object and defines an Decorator interface that conforms to Component's interface. ConcreteDecorator •Adds responsibilities to the component.
- 50. Java API Children of FilterinputStream such as BufferedInputStream, LineNumberInputStream , PushbackInputStream HttpServletRequestWrapper/ResponseWrapper
- 51. • To addresponsibilities to objects dynamically and transparently • When extension by subclassing is impractical. Sometimes a large number of independent extensions are possible and would produce an explosion of subclasses to support every combination. Or a class definition may be unavailable for subclassing. Applicability
- 52. More flexibility thanstatic inheritance. With decorators, responsibilities can be added and removed at run-time simply by attaching and detaching them. Avoids feature-laden classes high up in the hierarchy. Decorator offers a pay-as-you-go approach to adding responsibilities. Lots of little objects. A design that uses Decorator often results in systems composed of lots of little objects that all look alike.
- 53. Intent Decouple an abstraction from its implementation so that the two can vary independently.
- 54. •defines the abstraction's interface. Abstraction •maintains a reference to an object of type Implementor. •Extends the interface defined by RefinedAbstraction Abstraction. •defines the interface for Implementor implementation classes. •implements the Implementor ConcreteImplementor interface and defines its concrete implementation.
- 55. Java API AWT Component/ComponentPeer Andall AWT Component subclasses
- 56. • You wantto avoid a permanent binding between an abstraction and its implementation. This might be the case, for example, when the implementation must be selected or switched at run-time. • Both the abstractions and their implementations should be extensible by subclassing. • Implementation details should be hidden from the client. Applicability
- 57. Decoupling interface andimplementation. An implementation is not bound permanently to an interface. The implementation of an abstraction can be configured at run-time. Improved extensibility.You can extend the Abstraction and Implementor hierarchies independently. Hiding implementation details from clients.
- 58. Intent Provide a way to access the elements of an aggregate object sequentially without exposing its underlying representation.
- 59. •Defines an interfacefor accessing Iterator and traversing elements •Implements the Iterator interface •Keeps track of the current position ConcreteIterator in the traversal of the aggregate •Defines an interface for creating Aggregate an Iterator object •Implements the Iterator creation ConcreteAggregate interface to return an instance of the proper ConcreteIterator
- 60.
- 61. • To accessan aggregate object's contents without exposing its internal representation • To support multiple traversals of aggregate objects • To provide a uniform interface for traversing different aggregate structures (that is, to support polymorphic iteration) Applicability
- 62. Iterators simplify theAggregate interface More than one traversal can be pending on an aggregate. An iterator keeps track of its own traversal state. Therefore you can have more than one traversal in progress at once. It supports variations in the traversal of an aggregate.
- 63. Intent Compose objects into tree structures to represent part-whole hierarchies. Composite lets clients treat individual objects and compositions of objects uniformly.
- 64. •Declares the interfacefor objects in the composition. •Implements default behavior for the interface common Component to all classes, as appropriate. •Declares an interface for accessing and managing its child components. •Represents leaf objects in the composition. A leaf has no children. Leaf •Defines behavior for primitive objects in the composition. •Defines behavior for components having children. •Stores child components. Composite •Implements child-related operations in the Component interface. •Manipulates objects in the composition through the Client Component interface.
- 65. Java API DOM Node/Element AWT Dialog
- 66. • You wantto represent part-whole hierarchies of objects. • You want clients to be able to ignore the difference between compositions of objects and individual objects. Clients will treat all objects in the composite structure uniformly. Applicability
- 67. Defines class hierarchiesconsisting of primitive objects and composite objects. Primitive objects can be composed into more complex objects, which in turn can be composed, and so on recursively. Wherever client code expects a primitive object, it can also take a composite object. Makes the client simple. Clients can treat composite structures and individual objects uniformly. Makes it easier to add new kinds of components. Newly defined Composite or Leaf subclasses work automatically with existing structures and client code. Can make your design overly general. The disadvantage of making it easy to add new components is that it makes it harder to restrict the components of a composite. Sometimes you want a composite to have only certain components. With Composite, you can't rely on the type system to enforce those constraints for you. You'll have to use run-time checks instead.
- 68. Intent Use sharing to support large numbers of fine- grained objects efficiently.
- 69. Flyweight Declares an interface through which flyweights can receive and act on extrinsic state. ConcreteFlyweight (Character) implements the Flyweight interface and adds storage for intrinsic state, if any. A ConcreteFlyweight object must be sharable. Any state it stores must be intrinsic; that is, it must be independent of the ConcreteFlyweight object's context.
- 73. Iterator Strategy Template Method Observer Command Chain of Responsibility State Visitor Mediator Interpreter Memento
- 74. Intent Define a family of algorithms, encapsulate each one, and make them interchangeable. Strategy lets the algorithm vary independently from clients that use it.
- 75. •Declares an interfacecommon to all supported algorithms. Context uses this interface to call the Strategy algorithm defined by a ConcreteStrategy. •Implements the algorithm using ConcreteStrategy the Strategy interface. •Is configured with a ConcreteStrategy object. •Maintains a reference to a Strategy Context object. •May define an interface that lets Strategy access its data.
- 76. Java API • java.util.Comparator •java.util.zip.Checksum(CheckedInputStream/OutputStream) Others • org.apache.commons.collections.Predicate
- 77. • Many relatedclasses differ only in their behavior. Strategies provide a way to configure a class with one of many behaviors. • You need different variants of an algorithm. • You need to vary the behavior of objects at runtime. • A class defines many behaviors, and these appear as multiple conditional statements in its operations. Instead of many conditionals, move related conditional branches into their own Strategy class. Applicability
- 78. Families of relatedalgorithms. Hierarchies of Strategy classes define a family of algorithms or behaviors for contexts to reuse. An alternative to subclassing. Strategies eliminate conditional statements. A choice of implementations. Strategies can provide different implementations of the same behavior. The client can choose among strategies. Clients must be aware of different Strategies. Increased number of objects. Strategies increase the number of objects in an application. Sometimes you can reduce this overhead by implementing strategies as stateless objects that contexts can share.
- 79. Intent Define the skeleton of an algorithm in an operation, deferring some steps to subclasses. Template Method lets subclasses redefine certain steps of an algorithm without changing the algorithm's structure.
- 80. •Defines abstract primitive operations that concrete subclasses define to implement steps of an algorithm. •Implements a template method AbstractClass defining the skeleton of an algorithm. The template method calls primitive operations as well as operations defined in AbstractClass or those of other objects. •Implements the primitive ConcreteClass operations to carry out subclass- specific steps of the algorithm.
- 81. Servlet API • HttpServletservice() method Spring • JdbcTemplate • HibernateTemplate • JmsTemplate • TransactionTemplate Struts • RequestProcessor
- 82. • To implementthe invariant parts of an algorithm once and leave it up to subclasses to implement the behavior that can vary. • When common behavior among subclasses should be factored and localized in a common class to avoid code duplication. • To control subclasses extensions. You can define a template method that calls "hook" operations at specific points, thereby permitting extensions only at those points. Applicability
- 83. Avoids code duplication– Common behavior goes in parent class Controlled variation of algorithm through hook methods Hollywood principle – “Don’t call us, we’ll call you” - parent class calls the operations of a subclass and not the other way around. Use of inheritance for varying behavior
- 84. Intent Define a one-to-many dependency between objects so that when one object changes state, all its dependents are notified and updated automatically.
- 85. • Knows itsobservers. Any number of Observer objects may observe a subject. Subject • Provides an interface for attaching and detaching Observer objects. • Defines an updating interface for objects that Observer should be notified of changes in a subject. • Stores state of interest to ConcreteObserver objects. ConcreteSubject • Sends a notification to its observers when its state changes. • Maintains a reference to a ConcreteSubject object. • Stores state that should stay consistent with ConcreteObserver the subject's. • Implements the Observer updating interface to keep its state consistent with the subject's.
- 86. Java API java.util.EventListener (AllSwing) java.util.Observer/java.util.Observable javax.faces.event.PhaseListener
- 87. • When achange to one object requires changing others, and you don't know how many objects need to be changed. • When an object should be able to notify other objects without making assumptions about who these objects are. In other words, you don't want these objects tightly coupled. Applicability
- 88. Loose coupling between Subject and Observer. Enables broadcast communication Unexpected updates
- 89. Intent Encapsulate a request as an object, thereby letting you parameterize clients with different requests, queue or log requests, and support undoable operations.
- 90. • Declares aninterface for executing an Command operation. • Defines a binding between a Receiver object and an action. ConcreteCommand • Implements Execute by invoking the corresponding operation(s) on Receiver. • Creates a ConcreteCommand object and Client sets its receiver. • Asks the command to carry out the Invoker request. • Knows how to perform the operations Receiver associated with carrying out a request. Any class may serve as a Receiver.
- 91. Java API • java.lang.Thread/java.lang.Runnable •java.util.timer/java.util.TimerTask Others • Struts – action classes
- 92. • Parameterize objectsby an action to perform • Specify, queue, and execute requests at different times. • Support undo. Applicability
- 93. Command decouples theobject that invokes the operation from the one that knows how to perform it. Commands are first-class objects. They can be manipulated and extended like any other object. You can assemble commands into a composite command. It's easy to add new Commands, because you don't have to change existing classes.
- 94. Intent 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.
- 95. •Defines an interfacefor handling Handler requests. •Handles requests it is responsible for. •Can access its successor. ConcreteHandler •If the ConcreteHandler can handle the request, it does so; otherwise it forwards the request to its successor. •Initiates the request to a Client ConcreteHandler object on the chain.
- 96.
- 97. • More thanone object may handle a request, and the handler isn't known beforehand. 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. Applicability
- 98. Reduced coupling Added flexibilityin assigning responsibilities to objects Receipt isn't guaranteed
- 99. Intent Allow an object to alter its behavior when its internal state changes. The object will appear to change its class.
- 100. •Defines the interfaceof interest to clients. Context •Maintains an instance of a ConcreteState subclass that defines the current state. •Defines an interface for encapsulating the behavior State associated with a particular state of the Context. ConcreteState •Each subclass implements a behavior associated with a subclasses state of the Context.
- 101. General • Vending machines,ATMs and suchlike Wherever there is life cycle of objects is observed • Hibernate entities, EJB etc. Finite State Machines
- 102. • An object'sbehavior depends on its state, and it must change its behavior at run-time depending on that state. • Operations have large, multipart conditional statements that depend on the object's state. This state is usually represented by one or more enumerated constants. Often, several operations will contain this same conditional structure. The State pattern puts each branch of the conditional in a separate class. This lets you treat the object's state as an object in its own right that can vary independently from other objects. Applicability
- 103. It localizes state-specificbehavior and partitions behavior for different states It makes state transitions explicit State objects can be shared
- 104. Intent Represent an operation to be performed on the elements of an object structure. Visitor lets you define a new operation without changing the classes of the elements on which it operates.
- 105. • Declares aVisit operation for each class of Visitor ConcreteElement in the object structure. • Implements each operation ConcreteVisitor declared by Visitor. • Defines an Accept operation Element that takes a visitor as an argument. • Implements an Accept ConcreteElement operation that takes a visitor as an argument.
- 106. JDK javax.lang.model.element.Element and ElementVisitor javax.lang.model.type.TypeMirror and TypeVisitor javax.lang.model.element.AnnotationValue and AnnotationValueVisitor
- 107. • Many distinctand unrelated operations need to be performed on objects in an object structure, and you want to avoid "polluting" their classes with these operations. • The classes defining the object structure rarely change, but you often want to define new operations over the structure. • An object structure contains many classes of objects with differing interfaces, and you want to perform operations on these objects that depend on their concrete classes. Applicability
- 108. Makes adding newoperations easy Gathers related operations and separates unrelated ones Adding new ConcreteElement classes is hard Can visit across class hierarchies compared to Iterator Can Accumulate state while visiting May break encapsulation
- 109. Intent Define an object that encapsulates how a set of objects interact. Mediator promotes loose coupling by keeping objects from referring to each other explicitly, and it lets you vary their interaction independently.
- 110. •Defines an interfacefor Mediator communicating with Colleague objects. •Implements cooperative behavior by ConcreteMediator coordinating Colleague objects. •Knows and maintains its colleagues. •Each Colleague class knows its Mediator object. Colleague classes •Each colleague communicates with its mediator whenever it would have otherwise communicated with another colleague.
- 111. JDK java.util.concurrent.Executor#execute(Runnable command) java.util.Timer (scheduleXXX() methods)
- 112. • A setof objects communicate in well-defined but complex ways. The resulting interdependencies are unstructured and difficult to understand. • Reusing an object is difficult because it refers to and communicates with many other objects. • A behavior that's distributed between several classes should be customizable without a lot of subclassing. Applicability
- 113. Decouples colleagues Simplifies objectprotocols – replaces many-to-many interaction with one-to-many Abstracts how objects cooperate - can help clarify how objects interact in a system. Centralizes control Limits subclassing –behaviour is localized in mediator and hence would require subclassing only mediator for changing it.
- 114. Intent Given a language, define a representation for its grammar along with an interpreter that uses the representation to interpret sentences in the language.
- 115. Postfix Calculator • expression::= plus | minus | multiply | variable • plus ::= expression expression '+' • minus ::= expression expression '-' • into ::= expression expression '*' • variable ::= 'a' | 'b' | 'c' | ... | 'z'
- 116. AbstractExpression Declares an abstract Interpret operation that is common to all nodes in the abstract syntax tree. TerminalExpression Implements an Interpret operation associated with terminal symbols in the grammar. An instance is required for every terminal symbol in a sentence. NonterminalExpression One such class is required for every rule R ::= R1 R2 ... Rn in the grammar. Maintains instance variables of type AbstractExpression for each of the symbols R1 through Rn. Implements an Interpret operation for nonterminal symbols in the grammar. Interpret typically calls itself recursively on the variables representing R1 through Rn. Context Contains information that's global to the interpreter. Client Builds (or is given) an abstract syntax tree representing a particular sentence in the language that the grammar defines. The abstract syntax tree is assembled from instances of the NonterminalExpression and TerminalExpression classes. Invokes the Interpret operation.
- 117.
- 118. • The grammaris simple. For complex grammars, the class hierarchy for the grammar becomes large and unmanageable. • Efficiency is not a critical concern. Applicability
- 119. It's easy tochange and extend the grammar Implementing the grammar is easy Complex grammars are hard to maintain Adding new ways to interpret expressions is easy
Editor's Notes
- #3 1. Christopher Alexander, an architect, started the work of observing,recognizing and documenting design patterns in buildings. He Authored the book “A Pattern Language: Towns, Buildings, Construction” that summed up his research.2. Kent Beck and Ward Cunningham started experimenting with the idea of applying patterns to programming and presented their results in OOPSLA (Object-Oriented Programming, Systems, Languages & Applications) annual conference in 1987 in a paper named "Using Pattern Languages for Object-Oriented Program"
- #4 Context – an environment, surroundings, situation or interrelated conditions within which something exists. Example, how to represent algorithms as objects?Problem – an unsettled question, something that needs to be investigated and solved. It is constrained by context.Solution – an answer to the problem in a context.So, if we have a solution to a problem in a context, is it a pattern? Not necessarily. The characteristic of recurrence needs to be applied in such case. The solution is a pattern if it can be applied repeatedly in similar context.
- #18 If you have understood factory pattern, understanding abstract factory is a cakewalk. How many create methods you have in a factory ? Answer is 1. How many product(s) does a factory return ? Answer is 1. Now if you are asked how many create methods or in other words, how many product(s) does an abstract factory create ? - Answer will be : More than 1.
- #46 Collection.toArray() returns an Object[] and not the correct type. Say you have a collection containing Strings, then you have to pass a String[] into the toArray() method.
- #53 With decorators, responsibilities can be added and removed at run-time simply by attaching and detaching them. In contrast, inheritance requires creating a new class for each additional responsibility This gives rise to many classes and increases the complexity of a system. Furthermore, providing different Decorator classes for a specific Component class lets you mix and match responsibilities.Instead of trying to support all foreseeable features in a complex, customizable class, you can define a simple class and add functionality incrementally with Decorator objects. Functionality can be composed from simple pieces. As a result, an application needn't pay for features it doesn't use. It's also easy to define new kinds of Decorators independently from the classes of objects they extend, even for unforeseen extensions. Extending a complex class tends to expose details unrelated to the responsibilities you're adding. The objects differ only in the way they are interconnected, not in their class or in the value of their variables. Although these systems are easy to customize by those who understand them, they can be hard to learn and debug.