creational

• Factory Method
• Abstract Factory
• Builder
• Prototype
• Singleton

structural

• Adapter
• Bridge
• Composite
• Decorator
• Facade
• Flyweight
• Proxy

behavioral

• Chain of Responsibility
• Command
• Interpreter
• Iterator
• Mediator
• Memento
• Observer
• State
• Strategy
• Template Method
• Visitor

map

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

filter

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

remove odd elements

reduce

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

• states that a programmer should not add functionality until deemed necessary
• principle originates from extreme programming (XP)

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

• presentation layer (frontend/UI)
  • handles the interactions that users have with the software
  • focuses on the user interface and user experience – later in course
• business logic layer (domain layer)
• application layer (service layer)
• data access layer (persistence layer)
• data layer

• presentation layer (frontend/UI)
• business logic layer (domain layer)
  • where business rules and application logic are implemented
  • processes data, applies business rules, and controls transactions
• application layer (service layer)
• data access layer (persistence layer)
• data layer

• presentation layer (frontend/UI)
• business logic layer (domain layer)
• application layer (service layer)
  • acts as a bridge between the presentation layer and business logic
  • manages application flow, coordinates user requests, and processes business operations
• data access layer (persistence layer)
• data layer

• presentation layer (frontend/UI)
• business logic layer (domain layer)
• application layer (service layer)
• data access layer (persistence layer)
  • handles data storage and retrieval from persistent storage systems (e.g., database)
  • manages CRUD operations and interacts with data sources
• data layer

• presentation layer (frontend/UI)
• business logic layer (domain layer)
• application layer (service layer)
• data access layer (persistence layer)
• data layer
  • where data is stored in a structured or semi-structured format

Object-oriented design (OOD) is the process of planning a system of interacting objects to solve a software problem (Wikipedia contributors, 2024c).

control flow? structure?

• consists of two parts
  • client and server
• distributed
• always the client initiates a connection to the server
• while the server process always waits for requests from any client

models

• publish-subscribe model
  • messages are published to a specific topic, and all subscribed receivers receive those messages
  • one to many
• point-to-point model
  • messages are sent directly from a sender to a specific receiver, ensuring that only that recipient processes the message
  • one to one

delivery guaranties

• at most once
  • push based
  • no retries
• at least once
  • delivery confirmation
  • (typically) pull based
• exactly once
  • at least once, extended by guarantee that there will be no duplicates

• presentation layer (a.k.a. UI layer, view layer)
  • responsible for user interactions with the software system
• application layer (a.k.a. service layer)
  • aspects related to accomplishing functional requirements
• business (logic) layer
  • responsible for algorithms, and programming components
• data access layer (a.k.a. persistence layer)
  • responsible for handling data, databases

advantages

• simple and easy to learn and implement
• reduced dependency because the function of each layer is separate from the other layers
• testing is easier because of the separated components
  • components can be tested individually
• cost overheads are fairly low

disadvantages

• scalability is difficult
  • not well-suited for large projects
• can be difficult to maintain
  • a change in a single layer can affect the entire system because it operates as a single unit
• a layer depends on the layer above it

• popularized by Jeffrey Palermo
• code can depend on layers more central, but code cannot depend on layers further out from the core
  • all coupling is toward the center
• the database is not the center, it is external
  • the data model is in focus, whereas in layered data is the foundation
• relies on the dependency inversion principle
• appropriate for long-lived business applications
  • also applications with complex behavior

• invented by Alistair Cockburn (Cockburn, 2010)
• application should be equally controllable by users, other applications, or automated tests
  • for the business logic, it makes no difference whether it is invoked from a user interface, a REST API, or a test framework
• infrastructure modernization should be possible without changing the business logic

advantages

• modifiability
• isolates responsibilities
• once the ports are defined, the work on the components can be divided among developers

disadvantages

• the effort of port-adapter implementation is non-negligible
• for smaller applications, the extra effort is not worth it

• architectural pattern
• MVC pattern was implemented as early as 1974 in the Smalltalk project

• 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

send everything to the UI

send only the aggregated data

make the database aggregate the data

for the progress:

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

@spec create_chart(list(Measurement.t())) :: Plot.t()
def create_chart(last_day) do
//...
data =
  Enum.map(last_day, fn x ->
    {:ok, datetime} = NaiveDateTime.from_iso8601(x.timestamp)
    {datetime, x.temperature}
  end)
//...

• needs a list of measurements (as type)
• returns a Plot type

defmodule Frontend.Measurement do
  use Ecto.Schema

  schema "measurements" do
    field(:timestamp, :string)
    field(:address, :string)
    field(:temperature, :float)
    field(:humidity, :float)
    field(:battery, :float)
  end
end

plot = create_chart(last_day)
Plot.to_svg(plot)

• OOP principle: abstraction
  • hiding the complex reality while exposing only the necessary parts
  • plotting the temperature, other measurements are not required
• SOLID: interface segregation principle
  • many client-specific interfaces are better than one general-purpose interface
• increased coupling
• reusability

@spec create_chart(list(Float), list(String)) :: String.t()
def create_chart(temperatures, timestamps) do
  //...
  data =
    Enum.zip(
      Enum.map(timestamps, fn x ->
        {:ok, datetime} = NaiveDateTime.from_iso8601(x)
        datetime
      end),
      temperatures
    )
  //...

• needs two lists, one with the temperatures, another with the timestamps
• returns a string (SVG)
• produces the same chart
• abstracts dependencies
• cleaner interfaces
• easier to reuse