structural pattern matching

a paradigm principle example in functional programming, in addition to OOP’s from week 4

foo = 3

match foo:
    case 1:
        print("it's one")
    case 2:
        print("it's two")
    case _:
        print("it's not one or two")

structural pattern matching

a paradigm principle example in functional programming, in addition to OOP’s from week 4

foo = [1, 2.4, 3.1]

match foo:
    case [1, 2, 3]:
        print("it's a list with 1, 2, and 3")
    case [1, 2, _]:
        print("it's a list with 1, 2, and whatever")
    case [1, float(), float()]:
        print("it's a list with 1, and two floats")

the 23 (GoF) design patterns

bridge pattern (structural)

observer pattern (behavioral)

• instead of flooding the service with update requests, or the server sending notifications to everyone clients can subscribe to notifications
• this is exactly how newsletters work

observer pattern - Python example

class Observable:
    def __init__(self):
        self.subscribers = []

    def subscribe(self, subscriber):
        self.subscribers.append(subscriber)

    def notify(self, data):
        for subscriber in self.subscribers:
            subscriber.update(data)

class Subscriber:  # aka Observer
    def __init__(self, name):
        self.name = name

    def update(self, data):
        print(f"{self.name} received data: {data}")

class TemperatureSensor(Observable):
    def __init__(self):
        super().__init__()

    def change_temperature(self, temp):
        print(f"Temperature changed to: {temp}")
        self.notify(temp)

class DisplayUnit(Subscriber):
    def update(self, temp):
        print(f"{self.name} updated with temperature: {temp}")

sensor = TemperatureSensor()  # create observable

display1 = DisplayUnit("Display 1")  # create observer
display2 = DisplayUnit("Display 2")  # create observer

sensor.subscribe(display1)
sensor.subscribe(display2)

sensor.change_temperature(25)  # change value

Temperature changed to: 25
Display 1 updated with temperature: 25
Display 2 updated with temperature: 25

GoF design patterns in functional programming

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]

map-filter-reduce

some FP design patterns

Enum.map([0, 1, 2, 3], fn(x) -> x - 1 end)
[-1, 0, 1, 2]

Enum.filter([1, 2, 3, 4], fn(x) -> rem(x, 2) == 0 end)
[2, 4]

Enum.reduce([1, 2, 3], fn(x, acc) -> x + acc end)
6

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

class Shape:
    pass


class Square(Shape):
    def __init__(self, width: float):
        self.width = width

class Circle(Shape):
    def __init__(self, radius: float):
        self.radius = radius

class AreaCalculator:

    def sum(self, shapes: list[Shape]) -> float:
        result = 0
        for shape in shapes:
            if isinstance(shape, Square):
                result += shape.width**2
            elif isinstance(shape, Circle):
                result += shape.radius**2 * math.pi

        return round(result, 2)

open-closed principle

class Shape:
    pass

class AreaInterface:
    def area(shape: Shape) -> float:
        pass

class Square(Shape, AreaInterface):
    def __init__(self, width: float):
        self.width = width

    def area(self) -> float:
        return self.width**2

class Circle(Shape, AreaInterface):
    def __init__(self, radius: float):
        self.radius = radius

    def area(self) -> float:
        return round(self.radius**2 * math.pi, 2)

class AreaCalculator:
    def sum(self, shapes: list[Shape]) -> float:
        return sum([i.area() for i in shapes])

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 [7]

Liskov substitution principle - example

class Rectangle:

    def __init__(self, width: int, height: int):
        self.__width = width
        self.__height = height

    def setWidth(self, width: int):
        self.__width = width

    def setHeight(self, height: int):
        self.__height = height

    def getWidth(self):
        return self.__width

    def getHeight(self):
        return self.__height

    def getArea(self):
        return self.__width * self.__height

class Square(Rectangle):

    def __init__(self, width: int):
        super().setWidth(width)
        super().setHeight(width)

    def setWidth(self, width: int):
        super().setWidth(width)
        super().setHeight(width)

    def setHeight(self, height: int):
        super().setWidth(height)
        super().setHeight(height)

>>> r = Rectangle(2, 3)
>>> print(r.getArea())
6

>>> s = Square(2)
>>> print(s.getArea())
4

Liskov substitution principle - example

def getAreaTest(r: Rectangle):
    width = r.getWidth()  # width is 2
    r.setHeight(10)
    return f"Expected area of {width * 10}, got {r.getArea()}"

>>> r = Rectangle(2, 3)
>>> print(r.getArea())
6

>>> s = Square(2)
>>> print(s.getArea())
4

>>> print(getAreaTest(r))  # rectangle
Expected area of 20, got 20

>>> print(getAreaTest(s))  # square
Expected area of 20, got 100

this example violates the Liskov substitution principle

interface segregation principle

states that 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

Dependency inversion principle says that 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. [7]

law of Demeter

• if object A only calls its immediate friend (B) and doesn’t reach into its internals (like C), then changes to C or removal of C don’t affect A
  • this way, each class knows as little as possible about others, reducing the impact of changes
  • decreases dependency & results looser coupling
• this often leads to adding wrapper methods
  • while that might increase the number of methods, it results in cleaner interactions

layers of an architecture

layers of an architecture

layers of an architecture

layers of an architecture

how separating layers helps to design an architecture?

• separation of concerns: each element has a clear responsibility, making the codebase easier to understand, maintain, and modify
• modularity and reusability: elements (components or services) that can be used across different parts of the application or even other projects
• scalability: changes in one element (e.g., database layer) do not necessarily affect others, easier to replace one as the software scales
• ease of testing: each element can be tested individually

server/client architecture

message bus

• shared communication channel that connects multiple components or services
• simple, extensible

message bus types

layered

number of layers in a layered architecture is not set to a specific number

layered - properties

onion architecture

hexagonal - motivation

hexagonal (ports & adapters)

hexagonal vs. layered

the clean architecture

MVC - MVP - MVVM

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

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” [15]

• 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” [15]

• each layer should have a clear interface that hides internal details from other layers

architecture v1

architecture v1 - class

architecture v2

architecture v2 - class

architecture v2.1 - class

architecture v3

architecture v3 - SQL

SELECT
    CAST(strftime('%W', timestamp) AS INTEGER) AS week_of_year,
    CAST(strftime('%u', timestamp) AS INTEGER) AS day_of_week,
    count(*) AS count
FROM activity
WHERE
    user_id = 42 AND
    week_of_year > 35 AND
    week_of_year < 40
GROUP BY
    week_of_year,
    day_of_week
;

architecture v3 - SQL

SELECT
    lesson / 50.0 AS progress
FROM activity
WHERE
    user_id = 42 AND
    result = 'success'
ORDER BY
    lesson DESC
LIMIT 1;

architecture v3 - issues

• hard dependency on database
  • business logic in persistence layer
  • code depends on the SQL dialect
    • can be mitigated with an object-relational mapping (ORM) framework but that would also be a dependency
• may not suitable for complex aggregations
  • stored functions just increase dependency
• harder to unit test

why write ARDs?