Design Principles

Question 1 [24]

(a) [6] — 2 marks per principle identified + 1 each for smell/consequence.

• Single Responsibility Principle (SRP): Simulator handles both integration strategy selection and force computation and orchestration. Smell: "God class." Consequence: any change to force law OR integrator forces edits to the same class → merge conflicts, fragile tests. [3]
• Open/Closed Principle (OCP): the if/elif chain must be modified to add a new integrator. Smell: "switch on type." Consequence: not closed for modification; risk of regression each time. [3]
• (DIP also acceptable: hard-coded constants = dependency on concretions.)

(b) [8]

class Integrator(ABC):
    @abstractmethod
    def advance(self, state, dt, force_fn): ...   # returns new state
 
class ForceModel(ABC):
    @abstractmethod
    def accel(self, state): ...                   # dv/dt
 
class Simulator:
    def __init__(self, integrator: Integrator, force: ForceModel):
        self._integ = integrator      # depends on ABSTRACTION (DIP)
        self._force = force
    def run(self, state, dt, steps):
        for _ in range(steps):
            state = self._integ.advance(state, dt, self._force.accel)
        return state

• 3 marks: Integrator abstraction with advance.
• 3 marks: ForceModel abstraction; constants now injected, not hard-coded (DIP: high-level Simulator depends on interfaces).
• 2 marks: Simulator constructor takes abstractions (constructor injection).

(c) [6] 1-D: $a(v) = -g$ (constant, no drag). Start $v_0=0$, $dt=1$.

• Euler: $v_1 = v_0 + dt\cdot a = 0 + 1\cdot(-9.81) = -9.81$ m/s. [1.5]
• RK4: all four slopes equal $-g$ since $a$ is constant: $k_1=k_2=k_3=k_4=-9.81$, so $v_1 = v_0 + \frac{dt}{6}(k_1+2k_2+2k_3+k_4) = -9.81$ m/s. [1.5]
• Explanation [3]: For a constant derivative the exact solution is linear in $t$; Euler's local truncation error $O(dt^2)$ has coefficient $\propto v''=a'=0$, and RK4's $O(dt^5)$ term also vanishes. Both are exact here. For a nonlinear force (e.g. drag $\propto v^2$), $a'\neq 0$, so Euler's $O(dt^2)$ error appears while RK4 remains $O(dt^5)$ — they diverge.

(d) [4]

• Adding VerletIntegrator = new class implementing Integrator.advance; no existing class is modified — inject it into Simulator. [2]
• This satisfies OCP: system is open for extension (new strategy) and closed for modification (Simulator, existing integrators untouched). Contrast with the original if/elif, which required modification. [2]

Question 2 [20]

(a) [6]

• Principle violated: DRY (and KISS). Writing 6 classes duplicates the same 3 transformation logics; a bug fix in gain must be repeated. [2]
• Decorator solution: 3 leaf/decorator components each wrapping a Signal source; composition builds any ordering at runtime. [4]

class Filter(ABC):
    def apply(self, x): ...
class Source(Filter):
    def apply(self, x): return x
class Gain(Filter):
    def __init__(self, inner, a): self.inner, self.a = inner, a
    def apply(self, x): return self.a * self.inner.apply(x)
class Bias(Filter):
    def __init__(self, inner, c): self.inner, self.c = inner, c
    def apply(self, x): return self.inner.apply(x) + self.c
# any ordering: Gain(Bias(Source(), c), a)  vs  Bias(Gain(Source(), a), c)

(b) [8] Compute both compositions:

• $(g_a\circ b_c)(x) = g_a(x+c) = a(x+c) = ax + ac$. [2]
• $(b_c\circ g_a)(x) = b_c(ax) = ax + c$. [2]
• Difference: $(g_a\circ b_c)(x) - (b_c\circ g_a)(x) = (ax+ac)-(ax+c) = c(a-1)$. [2]
• This is nonzero exactly when $c\neq0$ and $a\neq1$ ⇒ non-commutative. [1]
• Design implication [1]: Since order changes the output, the sequence of Decorators is semantically significant and must be part of the pipeline's documented contract — it is not an interchangeable implementation detail.

(c) [6] $a=2, c=3, x=5$:

• $g_a\circ b_c$: $2(5+3)=16$. [1.5]
• $b_c\circ g_a$: $2\cdot5+3=13$. [1.5]
• Difference $=16-13=3 = c(a-1)=3(2-1)=3$. ✓ Formula confirmed. [1]
• Flyweight [2]: All $10^6$ Gain(2) decorators share identical intrinsic state (the factor 2). Store one shared flyweight object; per-use extrinsic state (the wrapped signal) passed in. Memory drops from $O(10^6)$ objects to $O(1)$ shared + references ≈ six orders of magnitude saving on the intrinsic data.

Question 3 [16]

(a) [6] Set $C_A(n)=C_B(n)$: $500 + 15n = 0 + 60n \;\Rightarrow\; 500 = 45n \;\Rightarrow\; n^\* = \frac{500}{45} = \frac{100}{9} \approx 11.11.$ [6] So the framework pays off only once ~12 distinct formats are needed.

(b) [6]

• Actual/expected $n = 1$ (one format, stable 3 years, no roadmap) is far below $n^\*\approx11.1$. [2]
• Therefore $C_B(1)=60 < C_A(1)=515$; Design B is ~8.6× cheaper today. YAGNI: don't build the abstract-factory speculative infrastructure for formats that "aren't gonna be needed"; KISS: 20 LOC is trivially understandable and testable. [2]
• Precise condition [2]: YAGNI is correct whenever the expected number of formats $\mathbb{E}[n] < n^\* = 100/9$. Equivalently, choose B while $\mathbb{E}[n]\lesssim 11$; only invest in A once demand credibly exceeds the break-even.

(c) [4]

• Separation of Concerns improvement always worthwhile: split to_csv() into (1) a data-serialization concern (row→string formatting) and (2) an I/O concern (writing to file/stream). [2]
• Rationale: decouples formatting from output destination, enabling unit-testing formatting without touching disk — cheap, non-speculative, and does not build unused format machinery, so it does not violate YAGNI. [2]

[
  {"claim":"Euler and RK4 give -9.81 for one step of constant accel -g from v=0, dt=1",
   "code":"g=Rational(981,100); dt=1; v0=0; euler=v0+dt*(-g); k=-g; rk4=v0+dt/6*(k+2*k+2*k+k); result=(euler==Rational(-981,100)) and (rk4==Rational(-981,100)) and (euler==rk4)"},
  {"claim":"Composition difference (g_a o b_c)-(b_c o g_a) = c(a-1)",
   "code":"a,c,x=symbols('a c x'); lhs=a*(x+c); rhs=a*x+c; result=simplify((lhs-rhs)-c*(a-1))==0"},
  {"claim":"Numeric check a=2,c=3,x=5 gives 16 and 13 with difference 3",
   "code":"a,c,x=2,3,5; g_of_b=a*(x+c); b_of_g=a*x+c; result=(g_of_b==16) and (b_of_g==13) and (g_of_b-b_of_g==c*(a-1))"},
  {"claim":"Break-even n* solves 500+15n=60n giving 100/9",
   "code":"n=symbols('n'); sol=solve(Eq(500+15*n,60*n),n); result=sol[0]==Rational(100,9)"}
]