week 5 summary

Gergő Pintér, PhD

gergo.pinter@uni-corvinus.hu

software design and architecture stack

based on Khalil Stemmel’s figure [1]

gang of four (GoF) design patterns

  • GoF: Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides
  • 23 common software design patterns
    • published in “Design Patterns: Elements of Reusable Object-Oriented Software” (1994) [2]
  • provides solutions to common design problems
  • categorized into three main groups
    1. creational
    2. structural
    3. behavioral

read about the design patterns in details, for example at refactoring.guru

GoF design patterns in functional programming

OO pattern FP pattern
factory pattern function
strategy pattern function
decorator pattern function
visitor pattern function
… …

Peter Norvig demonstrated that 16 out of the 23 patterns are simplified or eliminated by language features in Lisp or Dylan (1998) [3]

more about it from Scott Wlaschin [4]

SOLID principles

SOLID is a mnemonic acronym for five design principles intended to make object-oriented designs more understandable, flexible, and maintainable [5]

single responsibility principle
a class should do one thing and therefore it should have only a single reason to change
open-closed principle
classes should be open for extension and closed to modification
Liskov substitution principle
if class A is a subtype of class B, B should be able to replaced with A without disrupting the behavior of the program → square/rectangle problem
interface segregation principle
many client-specific interfaces are better than one general-purpose interface; clients should not be forced to implement a function they do no need
dependency inversion principle
modules should depend upon interfaces or abstract classes, not concrete classes; it’s an inversion because implementations depend upon abstractions and not the other way round

based on [6], [7]

coupling

  • the degree of interdependence between software modules
  • coupling is usually contrasted with cohesion
    • low coupling often correlates with high cohesion, and vice versa
from Wikimedia | public domain

source Wikipedia [8]

architectural styles / topologies

common pitfalls of architecture design and how to avoid them

tight coupling between layers
  • use techniques like inversion of control for flexible dependency management
  • each layer should only interacts with its adjacent layer through well-defined interfaces
too many layers
  • define the essential layers based on your application requirements; 4‑5 layers are usually enough
  • avoid splitting responsibilities into too many small layers without reason

source: Layers in software architecture by Sagar Hudge [9]

common pitfalls of architecture design and how to avoid them

cross-layer communication
  • violates the separation of concerns
  • each layer only interacts with its adjacent layers (see law of Demeter)
mixing business logic in the presentation layer
  • happens when business rules implemented directly in the presentation layer resulting duplicated or inconsistent logic, which is harder to update, scale, or test
  • keep business logic in the business logic layer and presentation layer should only display data/status updates

source: Layers in software architecture by Sagar Hudge [9]

common pitfalls of architecture design and how to avoid them

failure to refactor and maintain the architecture
  • “over time, the architecture may become outdated or cluttered with technical debt, making it hard to scale or add new features” [9]
  • regularly review and refactor the codebase to keep layers clean and maintainable – iterative design, boys scout rule
lack of proper layer abstraction
  • “if layers are not abstracted properly (e.g., exposing internal implementation details), it becomes difficult to replace or update components without affecting other layers” [9]
  • each layer should have a clear interface that hides internal details from other layers

source: Layers in software architecture by Sagar Hudge [9]

law of leaky abstractions

All non-trivial abstractions, to some degree, are leaky.

– Joel Spolsky

  • refers to a design flaw where an abstraction, intended to simplify and hide the underlying complexity of a system, fails to completely do so
  • this results in some of the implementation details becoming exposed or ‘leaking’ through the abstraction,
  • forcing users to have knowledge of these underlying complexities to effectively use or troubleshoot the system

source: Wikipedia / Leaky abstraction [10]

references

[1]
K. Stemmler, “How to learn software design and architecture.” https://khalilstemmler.com/articles/software-design-architecture/full-stack-software-design , 28-Sept-2019.
[2]
E. Gamma, R. Helm, R. Johnson, and J. Vlissides, Design patterns: Elements of reusable object-oriented software. Pearson Education, 1994.
[3]
P. Norvig, “Design patterns in dynamic languages.” http://www.norvig.com/design-patterns/ , 17-Mar-1998.
[4]
S. Wlaschin, “Functional programming design patterns.” https://fsharpforfunandprofit.com/fppatterns/ , Dec-2014.
[5]
Wikipedia contributors, “SOLID — Wikipedia, the free encyclopedia.” https://en.wikipedia.org/w/index.php?title=SOLID&oldid=1237710587, 2024.
[6]
S. Millington, “A solid guide to SOLID principles.” https://www.baeldung.com/solid-principles , 05-Feb-2019.
[7]
S. Oloruntoba and A. S. Walia, “SOLID: The first 5 principles of object oriented design.” https://www.digitalocean.com/community/conceptual-articles/s-o-l-i-d-the-first-five-principles-of-object-oriented-design , 23-Apr-2024.
[8]
Wikipedia contributors, “Coupling (computer programming) — Wikipedia, the free encyclopedia.” https://en.wikipedia.org/w/index.php?title=Coupling_(computer_programming)&oldid=1245630908, 2024.
[9]
S. Hudge, “Layers in software architecture.” https://medium.com/@sagar.hudge/layers-in-software-architecture-c8cc16329ff6 , 17-Oct-2024.
[10]
Wikipedia contributors, “Leaky abstraction — Wikipedia, the free encyclopedia.” https://en.wikipedia.org/w/index.php?title=Leaky_abstraction&oldid=1314409362, 2025.