From 63d3698c186d781ad9710cd8e190f0efdef98a05 Mon Sep 17 00:00:00 2001 From: pintergreg Date: Thu, 3 Oct 2024 08:54:58 +0000 Subject: [PATCH] deploy: c79b70c29ca999b7bd2562012af7dc7c72d72419 --- slides/06_uml.html | 3 +- slides/07_c4.html | 3 +- slides/08_patterns.html | 774 ++++++++++++++++++++++++++++++++++++++++ 3 files changed, 778 insertions(+), 2 deletions(-) create mode 100644 slides/08_patterns.html diff --git a/slides/06_uml.html b/slides/06_uml.html index 122e18d..d0a124b 100644 --- a/slides/06_uml.html +++ b/slides/06_uml.html @@ -119,7 +119,8 @@
-
+

Unified Modeling Language

Gergő Pintér, PhD

gergo.pinter@uni-corvinus.hu

diff --git a/slides/07_c4.html b/slides/07_c4.html index 28ac5c9..a1ec5ae 100644 --- a/slides/07_c4.html +++ b/slides/07_c4.html @@ -36,7 +36,8 @@
-
+

C4 model

Gergő Pintér, PhD

gergo.pinter@uni-corvinus.hu

diff --git a/slides/08_patterns.html b/slides/08_patterns.html new file mode 100644 index 0000000..801dbe3 --- /dev/null +++ b/slides/08_patterns.html @@ -0,0 +1,774 @@ + + + + + + + design patterns + + + + + + + + + + +
+
+ +
+

design patterns

+

Gergő Pintér, PhD

+

gergo.pinter@uni-corvinus.hu

+
+ +
+ +

+
+
+

software design and architecture stack

+
+based on Khalil Stemmel’s figure stemmler2019how? + +
+
+ +
+
+

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) gamma1994design?
      • +
    • +
  • provides solutions to common design problems
    • +
  • categorized into three main groups +
      +
    1. creational
      2. +
    2. structural
      3. +
    3. behavioral
      4. +
    • +
+
+
+

the 23 (GoF) design patterns

+
+
+

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
    • +
+
+
+
+

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

+
+
+
+

bridge pattern (structural)

+

+
+
+

+
+
+

+
+
+
+
+

You aren’t gonna need it (YAGNI)

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

Always implement things when you actually need them, never when you +just foresee that you need them.

+

– Ron +Jeffries

+
+
+
+
+

extreme programming

+
    +
  • advocates frequent releases in short development cycles
    • +
  • intended to improve productivity and introduce checkpoints at which +new customer requirements can be adopted
    • +
  • features +
      +
    • programming in pairs,
      • +
    • doing extensive code review,
      • +
    • unit testing of all code,
      • +
    • not programming features until they are actually needed,
      • +
    • flat management structure
      • +
    • +
  • considered a type of agile software development
    • +
+
+
+
+
+ +
+

hollywood principle (inversion of control)

+ +
+ +
+
+

SOLID principles

+
    +
  • single responsibility principle
    • +
  • open-closed principle
    • +
  • Liskov substitution principle
    • +
  • interface segregation principle
    • +
  • dependency inversion principle
    • +
+
+ +
+ +
+
+

+

https://devopedia.org/solid-design-principles#Merson-2020

+
+
+

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

+
    +
  • named after Barbara Liskov
    • +
+
+
+

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

+
+
+

coupling

+
+
+
    +
  • the degree of interdependence between software modules
    • +
  • coupling is usually contrasted with cohesion +
      +
    • low coupling often correlates with high cohesion, and vice +versa
      • +
    • +
+
+
+ + +
+
+
+
+

source Wikipedia +[1]

+
+
+ +
+

topologies

+ +
+ +
+
+

user statistics example

+
+
+

as a user I want to see my activity to see my progress

+
+
display user statistics including
+
+
    +
  • username
    • +
  • profile image
    • +
  • registration date
    • +
  • progress in course
    • +
  • daily activity in the current month
    • +
+
+
+
+

+
+
+
+
+

architecture v1

+
+
+

+
+

send everything to the UI

+

+
+
+
+
+

architecture v1 - class

+
+
+

+
+

in this case the UI has to calculate the daily activity

+
+
    +
  • tight coupling
    • +
  • single responsibility principle violated
    • +
+
+
+
+
+
+

architecture v2

+
+
+

+
+

send only the aggregated data

+

+
+
+
+
+

architecture v2 - class

+
+
+

+
+

data collector still has the whole user data but that aligns with its +purpose

+

data aggregator calculates everything and the UI only displays it

+
+
+
+
+

architecture v3

+
+
+

+
+

make the database aggregate the data

+

+
+
+
+
+

architecture v3 - SQL

+
+
+

+
+

for the activity matrix:

+
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

+
+
+

+
+

for the progress:

+
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
    • +
+
+

on the other hand, most of these are present in all the three +architectures!

+
+
+
+

references

+
+
+
[1]
Wikipedia contributors, “Coupling +(computer programming) — Wikipedia, the free +encyclopedia.” https://en.wikipedia.org/w/index.php?title=Coupling_(computer_programming)&oldid=1245630908, +2024.
+
+
+
+
+
+ + + + + + + + + + +