Exam 1

Design is about:

making change safe and affordable over time.

Most software cost is in:

modifying code, not writing it

Why use namespaces from a design perspective?

To organize modules into conceptual boundaries (e.g, TeaShop.Payments, TeaShop.Inventory, TeaShop.UI)

UML class diagrams show:

static structure (not execution flow)

T/F: Multiplicity is a design constraint that must be enforced in code.

True

What is the underlying premise of SRP?

SRP is about one actor (source of change) per module. Actors represent change pressure, not specific people.

What does this mean? SRP applies fractally from class to system level.

A fractal is a pattern that repeats at different scales.

Like a tree:

• branches look like small trees; same rule just zoomed in/out.

The SRP rule applies to every level of the system.

Define Strategy Pattern:

A pattern that defines a family of algorithms, encapsulates each, and makes them interchangeable at runtime.

What is one benefit of the Strategy Pattern?

It prevents "God methods" where multiple behaviors are tangled together. If done well, follows OCP, SRP, and permits dynamic dispatching.

What is the Open-Closed Principle?

OCP is about localizing change: "open for extension, closed for modification."

• Extend behavior without modifying stable code.

• SRP required → cannot close a class that has multiple reasons to change.

What does the Liskov Substitution Principle require from subtypes?

• Subtypes must not:

  • strengthen preconditions,

  • weaken postconditions, and

  • must preserve invariants.

T/F: LSP is the safety foundation for polymorphism and OCP.

True

What is the primary cause of software problems and maintenance cost?

complexity

Define complexity.

Anything related to the structure of a software system that makes it hard to understand or modify.

How does complexity manifest?

As change amplification, cognitive load, or unknown knowns.

What causes compexity?

dependencies: code cannot be modified / understood in isolation

obscurity: important information is not obvious (ambiguous naming of variables, inconsistencies)

What can highlight change amplification?

SRP

Define tactical programming

method to programming in which the focus is on getting it to work now (optimizing speed) without consideration of the consequences of the complexity introduced.

Define strategic programming

method to programming that encourages an investment mindset in which investments are both proactive and reactive and take about 10-20% of the programming time; leads to good design that optimizes long-term simplicity

T/F: OCP is framed as a refactoring discipline, not day-one over-design.

True

The best modules:

Have interfaces simpler than their implementations.

Define information hiding:

• Each module should hide design decisions and internal details that are likely to change.

• Public interfaces should be stable; internal representations should be free to evolve.

What should be hidden?

Details about how a module is implemented.

T/F: Encapsulation is most valuable when it hides volatility.

True

Define information leakage.

When modules understand the internal design logic of other modules.

Define temporal decomposition

When the structure of system is designed on time order and not by concept (rule/policy). This leads to information leakage as modules must know the details versus simply follow instructions.

How to overcome temporal decomposition?

Create a class that owns the rule/policy and has instruction methods that may be invoked by other methods (hint: order specialist class w/ methods: getPattyInstructions, getSauces, etc.)

When do you use an interface vs a class?

Interface: Anticipate change; Class: Anticipate no changes

Define pass-through method.

method that does little more than invoke another method

Define dispatcher

a valid form of pass-through method in which the method performs logic to determine which specific method should be invoked.

What is a context object? Why?

An object that bundles a list of variables (often global) to reduce complexity; preferred over long parameter lists of pass-through variables

Explain the notion of “pull complexity downward”.

It is more important for a module to have a simple interface than implementation. We want to pull complexity down into the module anytime:

1. the complexity is closely related to the class’s existing functionality, and

2. the complexity will lead to simplifications elsewhere, and

3. the complexity will lead to a simpler interface

Define composition root pattern.

Pattern in which a place is designated within the program for wiring together components and creation of objects. This helps keep the main program short and boring.

What is allowed in LSP? What is not allowed?

Allowed: different implementation, extra behavior, performance changes

Forbidden: different meaning, changes to guarantees, semantic changes (changes to method outcome but not signature, params)

T/F: A well-designed system has each layer providing a different level of abstraction compared to the ones above/below it.

True

Explain how leaky abstractions and redundant layers increase cognitive load.

Each layer should represent one realm of thought. If understanding code requires reasoning about multiple layers at once, cognitive load increases.

What is the intent of the strategy pattern?

Encapsulate interchangeable algorithms behind a stable interface and swap them at runtime.

How does the strategy pattern uphold SRP, OCP, LSP?

• SRP: Isolates each algorithm into its own class

• OCP: Lets you add new algorithms without editing the context

• LSP: Relies on consistent behavior from each strategy implementation

What is the intent of the decorator pattern?

Add responsibilities by wrapping objects rather than modifying or subclassing them repeatedly.

How does the decorator pattern uphold SRP, OCP, LSP?

• SRP: Keeps each added responsibility in its own class

• OCP: Composes new behavior without changing existing components

• LSP: Requires that decorators preserve the component contract

Strategy Pattern vs Decorator Pattern

• Strategy: only one thing varies; uses a context with one selected strategy;

• Decorator: stack additional behaviors around the same base operation; many things to vary; uses wrapper chains.

• Common trap: using Strategy when you really need behavior layering (logging + retry + metrics), or using Decorator when you only need one policy choice.

Dependency vs Association vs Composition

• Dependency: temporary method-level usage (local variable).

• Association: long-lived reference between objects.

• Composition: strong ownership where part lifetime is bound to whole.

• Common trap: drawing composition when the part is actually supplied externally and can outlive the owner (that is aggregation/association, not composition).

SRP vs DRY

• SRP focuses on change boundaries (one actor/reason to change).

• DRY focuses on duplication removal.

• Rule of thumb: when they conflict, prioritize clear responsibility boundaries first, then remove duplication safely.

Define Inheritance

Is structural and type-level (compile-time); models an is-a relationship where a subtype extends a base class enabling reuse of base behavior/state.

Notation: solid line, upward open triangle

Define Realization

A structural and type-level (compile-time) is-a relationship showing a class implementing an interface contract.

Notation: dashed line, upward open triangle

Define Dependency

Is non-structural (usage) and runtime/temporary; it is a short-lived relationship during execution, usually via parameters or local variables. It is not an is-a or has-a relationship.

Notation: dashed lined, downward arrow

Define Association

Is structural and state-level (runtime); is a long-lived has-a relationship in which objects know about each other but no ownership is implied.

Notation: Solid line, downward arrow

T/F: Prefer Association over Aggregation and Composition unless instance lifetime must be explicitly defined.

True

Define Aggregation

Is structural and state-level (runtime); it is a has-a whole-part relationship where the part's lifetime is independent of the whole. (weak ownership - groups)

Notation: solid line, open diamond

Define Composition

Is structural and state-level (runtime); it is a strong has-a relationship where the part is created internally and lifetimes are bound. (strong ownership)

Notation: solid line, filled diamond

Abstraction

Hiding irrelevant details to reduce cognitive load and localize change.

Abstract class

Partially implemented base type that can share state/behavior but cannot be instantiated.

Actor (SRP)

Conceptual source of change that requests modifications to code.

Behavioral subtyping

LSP rules for preconditions, postconditions, and invariants.

Change amplification

Small changes cause widespread edits/failures in several different areas of the code.

Cohesion

How tightly related a modules’s responsibilities are. Goal is high cohesion.

Concrete class

Instantiable type with full implementation.

Contract

The behavioral promises a type makes to its clients.

Coupling

Degree of dependency between modules. Desire is loose/low coupling.

Dynamic dispatch

Runtime selection of the correct overridden method.

Encapsulation

The process of protecting state and exposing controlled behavior.

Interface

Contract defining required members without implementation.

Multiplicity

UML constraint on how many related instances exist; must be enforced in code.

Polymorphism

Using a base type to work with many concrete types.

Precondition

What must be true before a method runs.

Postcondition

What must be true after a method completes.

Semantic promise

The meaning/behavior clients expect from a type.

Substitutability

Ability to replace a base type with any subtype safely.

UML class diagram

Static structural view of classes and relationships.

T/F: Refactor toward OCP only when variation appears.

True

Liskov Substitution Principle (LSP)

Subtypes must be usable anywhere their base type is expected without surprises. Focuses on semantics not syntax.

T/F: Design debt often causes maintenance pain and subtle defects after initial release.

TRUE

T/F: OOD techniques are primary used to localize changes as requirements evolve.

TRUE

T/F: A method that keeps growing with type-based conditions is a warning sign that the method needs refactoring.

TRUE

T/F: Dynamic dispatch means method behavior is resolved at compile time based on the concrete object behind an abstraction.

FALSE

T/F: If an object is only passed as a method parameter and never stored, the relationship should be modeled in UML as a dependency rather than an association.

TRUE

T/F: A class that changes frequently automatically violates the Single Responsibility Principle

FALSE

T/F: If accounting-rule changes and database changes keep hitting the same class, that is a strong SRP refactoring signal.

TRUE

T/F: Replacing repeated policy if/else branches with Strategy can support safer extension.

TRUE

T/F: OCP means existing code should never be modified under any circumstances.

FALSE

T/F: In the Decorator pattern, once decorators are introduced, the concrete component should no longer be used directly by clients.

FALSE

T/F: Creating an interface with exactly one implementation and no variation evidence is always a discipline OCP decision.

FALSE

T/F: ThrowingNotSupportedException from an override for required base behavior is often a sign of LSP trouble.

TRUE

T/F: A God class never exhibits high cohesion.

TRUE

In long-lived systems, which activity usually dominates total cost?

A. Writing the first working version.

B. Changing and extending existing behavior over time

C. Choosing the IDE and formatter

D. Renaming local variables after code review

B

Which statement about abstract classes is correct?

A. They cannot define constructors.

B. They can share implementation and still be non-instantiable.

C. They prevent derived classes from overriding behavior.

D. They are identical to interfaces.

B

An array IPublication[] holding instances of PaperbackBook, Magazine, and AudioBook demonstrates:

A. Immutability

B. Inheritance reuse of implementation

C. Polymorphism through a shared contract

D. Static method binding at compile time

C

When ownership and lifetime semantics are not essential to an instance, the recommendation is:

A. Association

B. Composition

C. Aggregation

D. Realization

A

In actor-based SRP analysis, the most useful question is:

A. What layer of the architecture does this class belong to?

B. How cohesive are the methods within this class?

C. Who requests this kind of change?

D. How frequently is this class modified?

C

SRP-first guidance for DRY decisions is:

A. Always deduplicate any similar code.

B. Never deduplicate across files.

C. Prefer inheritance before deduplication review.

D. Deduplicate only when the code changes for the same reason.

D

Practical OCP Primarily aims to:

A. Eliminate all future maintenance.

B. Predict every future requirement up front.

C. Protect stable code by localizing where new behavior lands.

D. Replace every class with an interface.

C

You have a Print class whose constructor requires six concrete classes to perform a single operation. This most strongly suggests:

A. The Print class is optimized for unit testing because dependencies are replaceable.

B. The Print class likely violates SRP.

C. The Print class is open for extension and closed for modification.

D. The Print class should be made static to reduce dependencies.

B

Define The Interface Segregation Principle (ISP)

A client should not be forced to depend on interfaces they do not use.

T/F: Broad interfaces couple unrelated change axes, increasing recompilation, retesting, and regression risk.

TRUE

T/F: Interface design should follow usage boundaries, not implementation convenience.

TRUE

Signs of ISP Violations:

• Class is forced to implement unrelated methods.

• Clients depend on operations they should never call.

• Dependency injection can accidentally wire a type that compiles but fails at runtime.

• Small interface changes trigger broad ripple effects across unrelated clients.

SRP vs ISP

Boundary clarification: SRP asks what independent reasons-tochange exist inside a module; ISP asks what each client is forced to depend on at the module boundary.

How are ISP and OCP connected?

OCP depends on stable abstractions. Fat interfaces are unstable because unrelated client needs keep changing them. With ISP, you extend behavior by adding new focused contracts instead of modifying broad ones.

How are ISP and LSP connected?

• LSP requires safe substitution. When a subtype throws on valid interface methods, substitution breaks.
  ISP: interface is too broad for some clients.
  LSP: subtype cannot honor full contract semantics.

How do Fat Interfaces impact Information Hiding?

Fat interfaces often leak internal workflow stages and implementation details. ISP pushes us to hide internals and expose only what a client must know.