Designing Object Systems with GRASP and Interaction Diagrams

# Designing Object Systems with GRASP and Interaction Diagrams

10.1 From Analysis to Design and Responsibility-Driven Design

10.1.1 Concept Overview

Object design builds on what analysis has already produced, but it is not a copy. Requirements, both functional and non-functional, set the boundary of what must be fulfilled. Analysis objects act as a framework that inspires the design rather than dictates it. Real-world objects identified during analysis — Sale, Product, Customer, Register — become software or logical objects, which are then turned into classes and programmed as actual runtime objects. Design operates at two levels at once: the high-level overall architecture (layers, subsystems, packages) and the inner working of how objects collaborate moment by moment to make a use case happen.

An object-oriented solution is therefore best understood as a collaboration of objects that carry responsibilities and capabilities to perform tasks together. The design job is to take objects already named in analysis, add responsibilities in the form of methods, and describe the result with UML diagrams that let us think and communicate before coding. Doing this well depends on accumulated experience from more than thirty to forty years of software design: rules, principles, idioms, and common ways of judging a decision without solving every problem from scratch. The aim is to reuse solutions — not to invent a new clever arrangement for a problem that has been solved a hundred times before.

A pattern is a collection that pairs a general problem with a general solution. More precisely, a pattern names a recurring problem in a context, a solution structure, and guidance on trade-offs and variations when adapting it. Design patterns document such problem and solution combinations. They are general and need adaptation to a specific context; a dress pattern for a sari is not sewn exactly like one for jeans, yet the pattern tells you what pieces exist and how they relate. Learning good designs also benefits from reverse engineering existing programs, tracing why a working design took a particular decision rather than just admiring that it works. Design remains a creative process often described as an art, yet it is learned by applying standard rules, design guidelines, and principles until the principles become instinct.

10.1.2 The Core Principle of Responsibility Assignment

Real-world grounding was built step by step in the lecture. An election illustrates the idea concretely. An election as an event is managed by a state administration. An election booth needs several distinct roles: managing the queue, validating identity against a list, marking voters with ink, and a polling officer coordinating the whole station. No single person does everything; work is distributed by competence and access to the right information (the queue manager sees the line, the validator holds the register). The same reasoning transfers directly to software: map the roles to objects and assign each object the responsibility it is best equipped to hold. If we were to computerize the booth, the Queue object manages ordering, the Registry object validates identity, and the PollingOfficer object coordinates — because each holds the relevant data.

A complementary everyday phrasing of the same rule is to keep data and the behavior that needs that data together, so lightweight classes collaborate to meet a responsibility rather than one bloated class carrying everything. Collaboration is therefore not a workaround; it is the intended outcome of correct assignment.

Visual intuition — what the design evolution looks like: Imagine a two-panel figure. The left panel shows Analysis: a domain model with boxes for Sale, SalesLineItem, ProductSpecification connected by associations, with attributes like time and quantity written inside. No methods are shown yet. The right panel shows Design: the same boxes now have method compartments added — getTotal(), getSubtotal(), getPrice() — and lifelines with arrows between them indicating messages. An arrow labeled "inspires" goes from left to right, not "copies", to emphasize that methods are added and collaborations are decided. The takeaway in one sentence: analysis tells you what exists; design decides who does what and how they talk.

10.1.3 Communicating Design Decisions Through Patterns

Design decisions should be explainable to another developer without retelling the whole story. Just as a step in mathematics is justified by citing a theorem, a design step is justified by citing a pattern or principle. Saying that a decision follows Information Expert or Creator is like citing Pythagoras theorem: the name carries a whole set of intent, structure, and trade-off, so a single sentence can replace a paragraph of hand-waving.

That makes patterns a communication tool among developers and architects. Chunking ideas under names also helps memory, so a name can bring the full picture to mind when you later recall it. The lecture drew the parallel explicitly:

A pattern name carries whole intent as Pythagoras theorem carries a whole proof. Hearing the name, you reconstruct the triangle, the squares, the relationship.

When we choose a solution there are always trade-offs, with pros and cons. A pattern advises how a solution applies in varying circumstances and what forces are at play. There is no single beautiful or ugly design in the abstract; the quality comes from how well dependencies and responsibilities are balanced. Human factors that allow work to continue in the real world despite imbalance — people compensating, improvising — cannot be relied on in software, so the design must aim for low dependence among objects and a fair distribution of work where each object does its part and acts as an expert for its job.

In GRASP terminology, many of these guidelines are presented as patterns even when strictly they are principles or advices. Larman uses the pattern form deliberately as a learning aid: naming, structuring, and remembering classic assignment reasoning so that instead of saying "it felt right," you can say "assigned by Expert because this class already aggregates the needed data, which also supports Low Coupling."

10.1.4 Student Questions and Answers

10.1.5 Industry Applications

Election booth organization shows how to map physical roles and responsibilities to object assignments and how the expert rule operates outside software — a technique still used in domain-driven design workshops where stakeholders role-play processes to discover candidate objects. Viewing many existing designs and applying reverse engineering to see why a working program is organized a certain way is presented as a practical learning method. Teams that inherit a codebase often reconstruct the interaction diagrams from code to uncover the original responsibility decisions before changing them.

10.1.6 Exam Notes

10.2 Interaction Diagrams and Messages as the Path to Methods

10.2.1 Concept Overview

For each system event or scenario within a use case we identify all participating objects and see how messages pass among them. Message passing leads directly to methods that will be added to class descriptions. A message is a request from one object to another for help, behavior, or expected action. If object A sends a message to object B, then B must have the capability and therefore a method to serve it. The message identifies the target object, whether communication is synchronous or asynchronous, the message name kept as abstract as possible, and the parameters. Whoever possesses the needed data supplies it as a parameter.

Interaction diagrams capture this dynamic view. Both sequence diagrams and communication (collaboration) diagrams are used. System events described in a system sequence diagram (SSD), such as seminar details entry or pressing an end-of-sale button, correspond to single operations that are then expanded into finer-grained interactions among domain objects. A sequence diagram or a collaboration diagram is drawn per scenario or per system event. The two forms are semantically equivalent — the same messages among the same objects — so a team can start with whichever is easier to sketch on a wall.

10.2.2 Notation, Numbering, and Diagram Organization

Large use cases that become too complex should be broken into multiple diagrams. A reference frame (often labeled ref), shown as a box that refers to another diagram, connects them. This ref notation is part of the Larman textbook conventions for linking diagrams and allows a main diagram to stay readable while detail lives in a referenced sub-diagram. Conditions, loops, and parallel fragments all have standard forms and should be learned for both diagram types so you can read any team's sketch.

The same system can be shown either way: the information is semantically equal in sequence and collaboration forms, so either diagram type can be used to create the design. Practical advice given in the lecture is to include the collaboration sequence numbers even when you sketch a sequence, to keep clarity because no single modeling view is ever complete. Also, keep message names abstract — createRegistration(...) rather than callCreateRegistrationSQL() — so the diagram stays at design level, not code level.

Visual intuition — what the two views emphasise: Imagine two figures side by side showing the same three-object interaction (UI → Controller → Domain). The left figure is a sequence diagram: vertical lifelines for each object, time flows downward, horizontal arrows carry messages verifyCode() then getSchedule(). The right figure is a communication diagram: the same three boxes placed as a triangle, numbered arrows 1: verifyCode() and 2: getSchedule() looping along links. The x-axis in the sequence view is objects, the y-axis is time; the x-axis in the communication view is space (layout freedom) and the numbers encode time. The takeaway: sequence shows time explicitly, communication shows topology compactly — choose by what you need to emphasise.

10.2.3 Worked Example: Department Seminar Scheduling

:Actor -> :UI : enterScheduleInfo(deptCode, year, term)
:UI -> :Department : verifyDepartment(deptCode)
alt [valid]
  :Department -> :Scheduling : getSchedule(term, year) : Schedule
  :Department -> :Registration : create(deptCode, year, term, capacity)
else [invalid]
  :Department --> :UI : error("unknown department")
end

10.2.4 Student Questions and Answers

10.2.5 Industry Applications

System events such as pressing spell-check, end-of-sale, or submit seminar details show how external events from a user interface are mapped to controller handling and then delegated to domain objects. In a POS system, endSale from the register UI becomes a controller message that triggers total calculation; in a word processor, spellCheck triggers dictionary lookup. The same mapping appears in web systems where an HTTP request is the system event forwarded from a frontend controller to domain services.

10.2.6 Exam Notes

10.3 Visibility, Scope, and Kinds of Responsibility

10.3.1 Concept Overview

An object can only send a message to another object if it has visibility — a connection or reference that makes the receiver accessible. Visibility means accessibility: a link, an association, or some form of access such as global access, local access, or parameter access. Scope defines where a variable or parameter is accessible in code. A parameter within a function has local (method) scope; a global variable has access in many places. Sending parameters or messages is only possible where visibility exists. This links the object-oriented notion of visibility directly to programming experience with variable scope — if you cannot name a variable in that block, you cannot send it a message either.

Responsibilities divide into two broad kinds familiar from CRC cards (Class-Responsibility-Collaborator) — an early lightweight design technique where each class has a card listing what it knows and does and who it collaborates with:

• Knowing: what information the object holds. This includes private encapsulated data, public and protected data, its attributes, and which collaborators it knows about. It also includes accessor duties such as get and set operations, and knowing about related objects (e.g., a Sale knows its SalesLineItems).

• Doing: what the object does. This includes performing computations and calculations itself, informing other objects to do work, carrying out an operation itself, and requesting services from collaborators when it cannot complete a job alone. Initiating action in other objects and controlling or coordinating activities of other objects — knowing about others and sequencing actions one after another — are central doing responsibilities. Each object should have a clear purpose that defines what it does.

Visual intuition — visibility graph: Imagine a figure with four small object boxes: Register, Sale, ProductCatalog, SalesLineItem. Solid lines labeled "attribute" connect Register→ProductCatalog (permanent) and Sale→SalesLineItem (collection). Dashed arrows labeled "parameter" show a transient link during makeLineItem(desc,qty) from Sale to ProductDescription. A small note box shows local visibility created inside enterItem() where desc appears after a return assignment. The x-axis is not numeric; the shape is about permanence: attribute lines are thick and long-lasting, parameter/local lines are thin and annotated with [during method]. Takeaway in one sentence: messages can only flow along a visibility line that exists at that moment.

10.3.2 High Cohesion as a Design Aim

Each object should do a single, well-defined job. That is described as high cohesion, where a single-responsibility object keeps its purpose focused. The behavior and data of the object stay at the same place, supporting encapsulation. Requesting services from other objects via collaborators is expected — cohesion does not mean isolation — but the core activity of the object itself should remain narrow.

A useful contrast is a Big object with 100 methods and 2,000 lines covering database, UI, and calculations (low cohesion) versus a Small object with 10 focused methods and 200 lines (high cohesion). High cohesion is evaluated alongside low coupling: keeping each object focused also keeps its dependencies lean because it only needs collaborators for its one job, not for many unrelated jobs.

10.3.3 Student Questions and Answers

10.3.4 Industry Applications

Human organization separates work among specialists so that each department focuses on its own concerns without interference, which mirrors software separation of concerns that visibility and scope rules enforce. In layered architectures, a domain object is not given global visibility to a UI widget because that would tie domain logic to presentation. Enforcing visibility boundaries keeps layers replaceable — for example, swapping a Swing UI for a web UI without touching Sale logic.

10.3.5 Exam Notes

10.4 GRASP: General Responsibility Assignment Software Patterns

10.4.1 Concept Overview

GRASP stands for General Responsibility Assignment Software Patterns. The key words are responsibility assignment. GRASP collects guidelines and principles for assigning responsibilities to objects and is presented as a learning aid and communication tool rather than as the final set of Gang of Four design solutions. The Gang of Four patterns are the concrete design ideas — Strategy, Factory, Adapter and twenty others — studied afterward as the Gang of Four (GoF) patterns; GRASP documents simple object-oriented assignment guidelines in pattern form so beginners can reason methodically before tackling the heavier GoF catalog. The name is also a mnemonic: grasp these principles to grasp object design.

There are nine GRASP patterns. The first five, often treated as the most used, are Expert, Creator, Controller, Low Coupling, and High Cohesion. The additional four are Polymorphism, Indirection, Pure Fabrication, and Protected Variation. In the lecture, Controller and Indirection are singled out as more challenging because they involve layering and indirection decisions, while the others are described as simple principles that follow quickly once Expert is understood. GRASP is sometimes read as "learning to grasp object analysis and design principles and guidelines for assigning responsibilities."

A pattern is not a finished piece of code you copy-paste; it is advice you adapt. Thinking in patterns also supports low representational gap — choosing software names and structures that mirror how we already think about the domain — so a Board in the domain naturally becomes a Board in the design.

10.4.2 Naming, Communication, and Reuse

Giving a pattern a name makes communication among developers and solution architects compact. Saying that a particular pattern was applied conveys the full set of involved objects and intent without repeating every diagram. Names support chunking ideas into memory so they can be incorporated into understanding and recalled under time pressure.

The advantage of a pattern over an isolated rule is that it talks about context together with problem and solution, so intent is clearer. GRASP uses this naming and documentation practice for assignment guidelines, even though strictly they are principles and advices rather than concrete pattern solutions in the Alexander sense (where a pattern is a physically built solution). The Larman simplification is noted explicitly: many principles and guidelines are presented as patterns to help learners reason scientifically about responsibility assignment rather than claiming an intuition-only process. Design is described as constrained choice among alternatives: select the best solution within time limits, weighing coupling, cohesion, and encapsulation.

Visual intuition — GRASP as a filter: Picture a funnel. At the top, many possible assignments for a responsibility ("Sale could do it, Register could do it, a new helper could do it"). In the middle, GRASP patterns act as labeled filters — Expert ("who has the data?"), Creator ("who contains it?"), Low Coupling ("which choice adds fewer dependencies?"). At the bottom, one or two surviving options exit with a justification label attached. The x-axis is alternatives, the y-axis is evaluation depth. Takeaway: GRASP narrows choices with explicit criteria instead of gut feel.

10.4.3 Approach to Learning GRASP

Learning object design through GRASP is framed as applying responsibility principles rationally and in an explainable way. Instead of saying a decision was made by intuition, the designer can point to an established principle and show the trade-off. The guidance recommends studying at least four or five case studies of good designs to absorb how patterns operate in context — reading the interaction diagram, covering the answer, guessing the assignment, then checking against the stated pattern. Open-Close Principle and Liskov Substitution are examples of broader principles that complement GRASP while designing; they will appear later but already shape how you think about extensibility.

Expect to reuse accumulated wisdom from thirty to forty years of software design rather than reinvent every collaboration. That reuse is precisely the economy a pattern language provides.

10.4.4 Industry Applications

Reuse across thirty to forty years of accumulated software design experience, treated as a set of named good solutions that can be adapted rather than reinventing each problem from scratch, is standard practice in product teams, consultancy libraries, and open-source frameworks. Pattern catalogs form checklists in design reviews: "Did we consider Expert, Creator, and Low Coupling for this new use case?" This practice shortens onboarding because a newcomer who knows the pattern vocabulary can read a prior team's interaction diagrams quickly.

10.4.5 Exam Notes

10.5 The Expert Pattern: Assigning Work to the Information Holder

10.5.1 Concept Overview

The Expert pattern (often called Information Expert) states that responsibility should be assigned to the class that has the information needed to carry it out. An expert is whoever holds the data and skill to do the job. For software this becomes an information expert rule: give the responsibility to the object that already holds the attributes or collaborator information required, because that object can do the work with low extra coupling and preserved encapsulation.

The intuition from everyday life is used explicitly in the lecture: the gardener does gardening, each person does the job they know, and in the same way a software object with the right attributes should hold the method. Lightweight classes collaborating to meet a responsibility follow from this: data and the behavior that needs that data reside together, and no single god class accumulates everything.

A responsibility is not just a method; it is an obligation of one object to another, a contract or guarantee that once a message is sent the receiver will perform the work. That contrasts sharply with human organizations where a person with capability might still not act; in an object system the obligation is expected to be met. Responsibilities split into knowing and doing, and Expert applies to both — here it tells us who should know the total and who should do the calculation.

10.5.2 Mathematical Formulation

The spoken description given is that the subtotal for a sales line item needs quantity and product price, and the total for a sale needs the sum of line subtotals. Reconstructed alongside that description and reconciled against Larman T1 Chapter 17 and companion examples:

Let $q_i$ be the quantity for sales line item $i$, where $q_i\in \mathbb{N}$ (a natural number, e.g., $2$ items) and is held by the SalesLineItem object, and let $p_i$ be the unit price for the product in that line, where $p_i\in {\mathbb{R}}_{\ge 0}$ (a non-negative real, e.g., $120.00$ in currency units) and is held via ProductSpecification (exposed via getPrice()).

Visual intuition — income stack: Imagine a bar chart where the x-axis is line item index $i=1,2,3$ and the y-axis is currency (e.g., rupees). Each bar's height is $s_i=q_i\times p_i$. One bar might be height $240$ ($2\times 120$), another $75$ ($3\times 25$), another $50$ ($1\times 50$). The total is the stacked height $total=240+75+50=365$, shown as the top of the stacked bar. The takeaway: Sale as expert stacks what SalesLineItem experts already know individually.

10.5.3 Worked Example: Computing a Sale Total

class Sale {
  List<SalesLineItem> lineItems;
  Money getTotal() {
    Money total = 0;
    for (SalesLineItem sli : lineItems)  // iteration
      total += sli.getSubtotal();        // delegate to expert
    return total;
  }
}
class SalesLineItem {
  int quantity;
  ProductSpecification product;
  Money getSubtotal() { return quantity * product.getPrice(); }
}

A special case is pointed out and saved for the next subsection: saving a sale to a database is a common operation every persistent class would otherwise need. Although all the sale information is in Sale, giving Sale the responsibility to handle connection strings and database work would make every class heavy and duplicate persistence logic. This is an intentional exception to Expert — separation of concerns overrides information possession here.

10.5.4 Exception, Separation of Concerns, and Encapsulation

Persistence belongs apart under separation of concerns. Database work — handling a SQL server or other persistent storage, connection strings, transaction boundaries — should live in a separate persistence concern or layer, not inside each domain class. That keeps classes highly cohesive, each focused on its own domain concern, and maintains low coupling and better encapsulation where private data is not exposed for persistence convenience. The guidance is that not every class should know how to access a database; a dedicated class or layer (often called PersistenceManager, DBService, or a Mapper/Repository) provides that service so domain objects remain focused on domain behavior.

In modern three-tier terms, this is why the domain layer does not embed database access: the same Sale logic must work regardless of whether the store is a relational DB, a file, or an in-memory mock. Encapsulation also benefits: persistence code often needs to set private fields; exposing those fields just to satisfy persistence weakens the class contract.

10.5.5 Student Questions and Answers

10.5.6 Industry Applications

Gardener and election booth analogies make Expert concrete in team discussions — give the task to whoever already holds the needed information, not to whoever volunteers. Persistence separation reflects modern three-tier practice where domain objects do not embed database connection handling; a dedicated persistence service does it to avoid duplication across classes, as seen in frameworks like Hibernate, JPA, or Repository patterns.

10.5.7 Exam Notes

10.6 The Creator Pattern: Responsibility for Creating Instances

10.6.1 Concept Overview

Creator addresses a frequent activity in object-oriented systems: who creates instances. Creation is done via a constructor (or factory method) that requires parameters, so whoever creates an object should have the information and access to supply those initialization parameters without extra coupling. Conceptually, Creator is Expert applied to creation: the expert in building an object should be the one that creates it, because it already knows the parts, the context, or the construction data.

When such a containment or close-use relationship exists, coupling remains low and encapsulation stays intact because creation uses information the creator already holds. The alternative — an unrelated helper collecting all parameters just to forward them — would introduce a new coupling and duplicate knowledge.

Visual intuition — containment as creation license: Picture a UML class diagram fragment. A Sale box has a diamond (composite aggregation) line to SalesLineItem with multiplicity 1 to 1..*, and SalesLineItem has a line to ProductSpecification. Next to it, a sequence diagram shows register.makeLineItem(desc, qty) arriving at Sale, then a dashed creation arrow create(desc, qty) from Sale to a new SalesLineItem lifeline appearing lower on the page, then Sale adding it to its collection. The x-axis in the class view shows structure; the y-axis in the sequence view shows time flowing down to birth. Takeaway: containment in the static view licenses creation in the dynamic view.

10.6.2 Worked Example: Sale Creating SaleLineItem

class Sale {
  List<SalesLineItem> lineItems;
  void makeLineItem(ProductDescription desc, int qty) {
    SalesLineItem sli = new SalesLineItem(desc, qty);
    lineItems.add(sli);           // establish the aggregation link
  }
}
class SalesLineItem {
  ProductSpecification product;
  int quantity;
  SalesLineItem(ProductSpecification desc, int qty) {
    this.product = desc;
    this.quantity = qty;
  }
  Money getSubtotal() { return quantity * product.getPrice(); }
}

:Register -> :Sale : makeLineItem(desc, qty)
:Sale -> :SalesLineItem : create(desc, qty)  // dashed, {new}
:Sale -> :Sale : lineItems.add(sli)          // self message, establish link

The discussion also notes containment terminology: part-of relationships favor creation by the whole. The overall message is that creation decisions are made by checking which object is the expert in providing the initialization data — Creator is a specialization of Expert for birth.

10.6.3 Industry Applications

Department as creator of course or seminar offering reflects containment in organizational modeling — a department owns its offerings, so it creates them. Choosing creation targets via containment and close-use relationships is described as keeping coupling low and supporting reuse of the creation responsibility. In frameworks, composite owners creating their parts appears pervasively: a Document creating its Paragraphs, a Cart creating CartItems, a Playlist creating PlaylistEntrys.

10.6.4 Exam Notes

10.7 The Controller Pattern: Coordinating System Events Without Burdening the Interface

10.7.1 Concept Overview

Controller answers who should be responsible for handling system events. A system event is a high-level event generated by an external actor operating through the user interface — the operation named in a System Sequence Diagram (SSD) such as createRegistration(deptCode, year, term), enterItem(itemID, quantity), or endSale(). The first non-GUI object to receive such events is the Controller. All business logic lives behind this point in a model-view-controller or broader three-tier view where the presentation layer and persistence/database layer flank the domain layer and its software objects.

A GUI component such as a button, text field, or scanner listener should only receive the raw input and forward it. The actual handling — validation, lookup, creation, calculation — is delegated to the Controller, which then coordinates work among domain objects. System events are identified during SSD work and then mapped to Controller responsibilities. Controllers can be named handlers in code, often with a suffix like Handler, Coordinator, or Session.

The principle cited is separation of concerns: keep user interface concerns (widget state, rendering, input handling) distinct from domain processing (business rules, calculations, persistence coordination) so the interface remains usable and reusable and the domain remains testable without a GUI.

10.7.2 Why the Interface Should Not Handle System Events

If a GUI element processes business logic directly, that logic becomes tightly bound to that particular GUI. The interface cannot be reused elsewhere (e.g., the same sale logic from a Swing register needed for a web register) and the coupling between presentation and domain becomes high and undesirable. A non-GUI Controller provides reuse: the same domain handling can be reached from different interface forms because the logic is not embedded in any one screen widget. It also keeps the UI focused on its own cohesion — displaying and capturing input — rather than becoming a bloated mix of rendering plus business rules.

Consider the Monopoly example referenced in T1 and the compiler example from the lecture: a JFrame receiving actionPerformed should not itself implement playGame() rules; it should delegate playGame() to a domain-level handler. Similarly, a button labeled "End Sale" should forward endSale() to the Controller, not compute totals itself.

10.7.3 Types of Controllers and the Bloated Controller Trap

Three forms are described in the lecture (with naming variations in literature):

• Facade or packet Controller (also called system or root Controller): A single Controller exposing a simplified surface over a subsystem, handling a modest number of events, often presented as handlers that hide many components. Example: a single SystemHandler or POSHandler receiving all sale events. The compiler is given as a classic packet Controller: a single entry point such as $cc$ or $gcc$ with a file name and options hides the internal work of syntax tree creation, syntax checking, and semantic checking while coordinating all components. The caller sees one command; complexity is encapsulated. Use a facade when the number of system events is small (about five or six or fewer).

• Use-case Controller: One handler per use case, useful when a use case involves many events or needs to maintain session state across several interactions. Examples: ProcessSaleHandler handling makeNewSale(), enterItem(), endSale(), makePayment() as one session; or ScheduleSeminarHandler remembering deptCode and year across steps. Session state — temporary data that must persist between system events of the same use case — is the signal to choose this form.

• Role-based Controller: One handler per role such as head of department, dean, or operator, suitable when events cluster by actor role and session information is role-specific. Example: DepartmentHeadHandler vs RegistrarHandler each handling the events relevant to that role.

The guideline is that handling more than about five or six events with one Controller suggests splitting. Overloading a single Controller with too much work creates a bloated Controller (also called a low-cohesion Controller) that does too many jobs instead of merely delegating and coordinating. Bloated Controllers become hard to understand, test, and maintain, and they tend to accumulate high coupling because they know many domain classes for unrelated use cases.

Visual intuition — Controller as switchboard: Picture a three-layer stack: top layer UI with boxes for buttons, middle layer Controllers with one or more handler boxes, bottom layer Domain with Sale, Department, Registration. Arrows from UI always go down to a single Controller entry point, then fan out from the Controller to many Domain objects. A bloated Controller diagram would show one middle box with dozens of outgoing arrows to everywhere — visually overloaded — versus a use-case split where each Controller fans to only its relevant Domain cluster. Takeaway: fan-in to Controller is narrow, fan-out is focused; bloating breaks both.

10.7.4 Worked Example: From System Events to Delegation

:Actor -> :UI : submitRegistration(deptCode, year, term)
:UI -> :RegistrationHandler : createRegistration(deptCode, year, term)
:RegistrationHandler -> :DepartmentCatalog : getDepartment(deptCode) : Department
alt [dept found]
  :RegistrationHandler -> :Department : getSchedule(year, term) : Schedule
  :RegistrationHandler -> :Schedule : createRegistration(capacity) : Registration
else [not found]
  :RegistrationHandler --> :UI : error("unknown department")
end

10.7.5 Student Questions and Answers

10.7.6 Industry Applications

Compiler as a facade Controller illustrates encapsulation of a multi-component process behind one user-visible command (cc/gcc), directly analogous to a facade application service hiding domain complexity from a UI. Session-heavy interactions, such as complex use cases maintaining many variables (shopping checkout with cart state), map naturally to use-case Controllers; role-specific entry points (admin vs student vs department head portals) map to role-based Controllers. In web architectures, MVC frameworks instantiate this pattern — the web controller receives the HTTP request (system event) and delegates to domain services.

10.7.7 Exam Notes

10.8 Cohesion, Coupling, and the Remaining GRASP Guidance

10.8.1 Concept Overview

Two qualities are used to judge assignment decisions across all previous patterns: high cohesion and low coupling. They are the yin and yang of modular design — you cannot improve one in isolation without watching the other.

Modularity in turn aids maintenance, reuse, and often improves execution considerations such as time and memory through lower complexity — fewer paths, clearer interfaces. A good design is also described in the lecture as one that yields a quality product on time and within cost while remaining extensible for future requirements — cohesion and coupling are the concrete, reviewable proxies for that abstract goal.

Both are treated as thought patterns or design guidelines for software design, not as concrete Gang of Four solutions — they are evaluative principles you apply to judge an assignment after you have a candidate.

Visual intuition — coupling vs cohesion seesaw: Imagine a scatter plot where the x-axis is coupling (left = low, right = high) and the y-axis is cohesion (bottom = low, top = high). A desirable design sits in the upper-left quadrant (high cohesion, low coupling). A god Controller with many responsibilities sits in the lower-right (low cohesion, high coupling) — visually far from desirable. Refactoring by moving a responsibility from the god to the correct Expert moves the point diagonally toward the upper-left — one arrow per move. Takeaway: each responsibility shift should be judged by its movement on this plot.

10.8.2 Additional GRASP Patterns in Preview

The remaining GRASP patterns build on the same assignment logic and are previewed for the next session:

• Polymorphism — When alternatives or behaviors vary by type, assign responsibility to the type for which the behavior varies, often through an interface or abstract superclass. Example: different Payment subclasses each know how to authorize() themselves.

• Indirection — To avoid direct coupling between two elements, assign responsibility to an intermediate object that mediates between them. Example: a PersistenceManager between Sale and the database, or an Adapter between a domain object and an external service. The lecture singles this out as more difficult because it intentionally adds a layer.

• Pure Fabrication — When no domain object is suitable (assigning there would destroy cohesion or raise coupling), invent a new non-domain class solely to achieve cohesion and low coupling. Example: a QuantityDiscountCalculator fabricated to hold discount rules that do not belong in Sale or ProductSpecification.

• Protected Variation — Identify points of predicted variation or instability, and assign responsibilities to create a stable interface around them so change does not ripple. This is the GRASP expression of Open-Close and information hiding. Example: wrapping an external payment gateway behind a stable PaymentGateway interface.

Indirection and Controller are noted as more difficult members of the full set precisely because they introduce or manage layers rather than placing a method on an obvious data holder. All nine together form the responsibility-assignment guidance to be read and practiced. Other broad principles mentioned to study alongside GRASP include Open-Close Principle (open for extension, closed for modification) and Liskov Substitution (subtypes substitutable for supertypes), which later appear as Protected Variation in practice.

Comparison — how GRASP supplements Expert/Creator/Controller:

10.8.3 General Guidance for Learning Good Designs

Good design is learned by studying good designs, not by memorizing definitions. The suggestion emphasized in the lecture is to work through at least four or five case studies, examine original solutions, and apply standard rules while designing — cover the answer, attempt the assignment, then check which GRASP principle justifies the textbook's choice. Working problems directly and producing original solutions is emphasized over passive reading. Learners were asked to practice a few interaction diagrams and to come prepared having read the GRASP material.

The mindset is iterative: draw a collaboration, apply Expert/Creator/Controller, evaluate with Low Coupling and High Cohesion, then refine. Over time, the principles become reflexive — what initially requires deliberate reasoning becomes the "it feels right because low coupling" intuition of an experienced designer. That is exactly the transition GRASP is designed to accelerate.

10.8.4 Industry Applications

Modularity through high cohesion and low coupling underpins large-scale software architecture across domains, including three-tier system organization that separates presentation, domain, and data tiers — each tier is a highly cohesive layer with low coupling to neighbors via defined interfaces. Indirection and protected variation are noted as the more nuanced GRASP ideas to explore for shielding a design from change, appearing as adapters, facades, and plug-in architectures in product lines.

10.8.5 Exam Notes

Exam Guidance Summary

Key Industry Applications

• Election booth operations → object assignment: Mapping physical roles (queue manager, validator, marking officer, polling officer) to software objects illustrates how domain expertise guides object design. Used in domain-driven workshops to discover objects by role-playing real processes.

• Gardener analogy → Expert: Giving the task to whoever already holds the needed information grounds the Expert rule in everyday expertise and is used to explain assignment choices in team reviews.

• Dress, window, and door patterns → pattern reuse: Naming captures variation families in physical design (sari vs jeans, window types) and translates to software pattern reuse — variation is expected, not exceptional.

• Reverse engineering existing programs → learning route: Reconstructing interaction diagrams from a working codebase to uncover why a design works is a practical learning route for inherited systems and for case-study practice.

• Compiler as facade controller: A single command (cc/gcc with filename and options) hiding syntax tree creation, syntax checking, and semantic checking exemplifies a facade or packet Controller and appears wherever a complex subsystem is exposed via a simple entry point (application services, APIs).

• Three-tier and Model-View-Controller organization: Separating presentation, domain, and persistence into layers directly motivates separation-of-concerns decisions such as excluding database handling from domain Experts. Seen in web, mobile, and enterprise architectures where the domain layer remains independent of the UI framework.

• Sale, SalesLineItem, and ProductSpecification collaboration → lightweight collaboration: Demonstrating how behavior and data stay together across lightweight domain objects while keeping each class focused is the canonical example used to evaluate Expert, Creator, cohesion, and coupling together.

• Department seminar scheduling → use-case realization: Modeling system events (enterScheduleInfo, createRegistration) as Controller-delegated interactions shows how an SSD scenario becomes an implemented use-case realization — the standard workflow for translating requirements into domain collaborations in iterative development.

• Sessioned use-case Controllers → stateful coordination: Using use-case or role-based Controllers to hold session state across multiple system events (e.g., multi-step registration or checkout) illustrates how Controller choice handles state and statecharts in real systems.