diff --git a/lectures/figures/change-ahead.jpg b/lectures/figures/change-ahead.jpg new file mode 100644 index 0000000..ac6178c Binary files /dev/null and b/lectures/figures/change-ahead.jpg differ diff --git a/lectures/figures/good_code.jpg b/lectures/figures/good_code.jpg new file mode 100644 index 0000000..a2ab678 Binary files /dev/null and b/lectures/figures/good_code.jpg differ diff --git a/lectures/week7.html b/lectures/week7.html new file mode 100644 index 0000000..902bdf6 --- /dev/null +++ b/lectures/week7.html @@ -0,0 +1,1792 @@ + + + + + + + + + + + +talk slides + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+
+
+
+ +
+

Design patterns

+
+
+
+
+ +
+

Why do we need them ?

Design Patterns: Elements of Reusable Object-Oriented Software by E. Gamma, R. Helm, R. Johnson and J. Vlissides (the gang of four)

+
    +
  • Designing object oriented code is hard
    • +
  • designing reusable object-oriented software is even harder!
    • +
+ +
+
+
+
+ +
+
+
+
+
+
+ +
+

Code Design $=$ decomposition into objects


+
    +
  • Some objects have real world counterparts (e.g. objects of type planet)
    • +
  • others don't (e.g. array, matrices, streams).
    • +
+ +
+
+
+
+ +
+

Design requirements

    +
  • Solution specific to a problem
    • +
  • General enough to address future problems
    • +
  • Performance Issues
    • +
  • Avoid/Minimize re-design
    • +
  • Vocabulary for design ideas
    • +
  • Minimize costs (development time)
    • +
+ +
+
+
+
+ +
+

Reuse solutions

    +
  • Object-oriented organisation repeat patterns
    • +
+

The design patterns

+ +
+
+ +
+
    +
  • Knowing the patterns $\Rightarrow$ quick application to your problems
    • +
  • Help to produce more reusable systems
    • +
  • Design patterns names $\Rightarrow$ vocabulary for team work
    • +
+
+
Motto: Designing for change
+
+
+
+
+ +
+

Design patterns: What they are

Design patterns have four essential elements:

+
    +

  • Pattern name: associates problem with solutions&consequences
    $\Rightarrow$ Improves communication and documentation

    +
    • +

  • Problem: Scenario/conditions of when to apply a pattern

    +
    • +

  • Solution: Description of the arrangement of classes and objects

    +
    • +

  • Consequences: Results and trade-offs. (allows to know design alternatives)

    +
    • +
+ +
+
+ +
+

Remarks

    +
  • The appropriate design pattern depends on the programming language.
    • +
  • Several design patterns are often combined together
    • +
+ +
+
+
+
+ +
+

Design patterns pros&cons

    +
  • Pros:
      +
    • consider/evaluate different design solutions
      • +
    • easier understanding of existing code (matching patterns)
      • +
    • easier start of a project (using general design patterns)
      • +
    +
    • +
+ +
+
+ +
+


+
    +
  • Cons:
      +
    • Strictly applying design patterns reduces creativity
      • +
    • Standard solutions may not be applied (scientific programming is complex)
        +
      • New cases = new (more complex) solutions
        • +
      • In high performance computing: optimization is a strong constraint
        • +
      +
      • +
    +
    • +
+ +
+
+
+
+ +
+
Design patterns

A useful source of inspiration
+ but no bible! +
+
+
+
+
+ +
+

Design patterns examples

+ +
+
+
+
+ +
+

Iterator

    +

  • General description: Gives access to elements of a container without exposing its internal representation

    +
    • +

  • Our problem (Particles):

    +
      +
    • Particles stored in an container
      • +
    • Perform computations/IOs on the particles
      • +
    • Traverse the container in different(random) ways
      • +
    • Access elements without knowing the internal structure of the container (list, vector, set, ...)
      • +
    +
    • +
+ +
+
+
+
+ +
+ +
+ +
+ +
+ +
+ +
+
+ +
+ +
+ +
+ + 
struct List {
+  using Element = Planet;
+
+  // define a sub type
+  struct ListIterator;
+
+  int size();
+  ListIterator begin();
+  ListIterator end();
+};
+
+struct List::ListIterator {
+  Element &operator*();
+  void operator++();
+  bool operator!=(ListIterator &e);
+};
+
+ + +
+ +
+ +
+
+
+
+ +
+ +
+ +
+ + 
struct List {
+  struct ListIterator;
+
+  int size();
+  void add(Element e) { container.push_back(e); };
+
+  ListIterator begin();
+  ListIterator end();
+
+private:
+  std::vector<Element> container;
+};
+
+struct List::ListIterator {
+
+  ListIterator(Element &current) { this->ptr = &current; }
+  Element &operator*() { return *this->ptr; };
+  void operator++() { ++this->ptr; };
+  bool operator!=(ListIterator e) { return e.ptr != this->ptr; };
+
+private:
+  Element *ptr;
+};
+
+List::ListIterator List::begin() { return ListIterator(this->container[0]); };
+List::ListIterator List::end() {
+  return ListIterator(this->container[this->size()]);
+};
+
+int main() {
+  int p1 = 1;
+
+  List list;
+
+  for (auto &&v : list) {
+    std::cout << v << std::endl;
+  }
+}
+
+ + +
+ +
+ +
+
+
+
+ +
+
    +
  • Consequences:
      +
    • Standardize container's interface
      • +
    • Can vary how to traverse a container (different iterator types)
      • +
    • Concurrent traversal of a container (double loop)
      • +
    +
    • +
+ +
+
+ +
+ +
+ +
+ + 
  List list;
+
+  for (auto &&v : list) {
+    std::cout << v << std::endl;
+  }
+
+ + +
+ +
+ +
+
+
+
+ +
+

Singleton

    +

  • General description: Ensure that a class has only one instance, and provides a global point of access

    +
    • +

  • Our problem (Particles):

    +
      +
    • Only one container of particles
      • +
    • Uniqueness enforced by the container himself
      • +
    • Access the container of particles from everywhere (global)
      • +
    • Contain planets or ping-pong balls (polymorphic)
      • +
    +
    • +
+
+ +
+
+ +
+ +
+ +
+ +
+ +
+ +
+
+
+
+ +
+ +
+ +
+ + 
class Singleton {
+
+private:
+  Singleton();
+
+  friend Singleton &get();
+};
+
+ + +
+ +
+ +
+
+ +
+
+ +
+
+ +
+ +
+ +
+ + 
Singleton *unique_instance = nullptr; // no encapsulation
+
+Singleton &get() { // not part of Singleton::
+  if (unique_instance == nullptr)
+    unique_instance = new Singleton();
+
+  return *unique_instance;
+}
+
+ + +
+ +
+ +
+
+
+
+ +
+

Static members and static members (C++)

    +
  • static variable/member is a unique and permanent variable
    • +
+ +
+
+ +
+ +
+ +
+ + 
class A {
+public:
+  static int a;
+};
+
+int A::a = 1;
+
+ + +
+ +
+ +
+
+ +
+
    +
  • what happens when we do this ? and why ?
    • +
+ +
+
+ +
+ +
+ +
+ + 
  A a1;
+  A a2;
+
+  a1.a = 2; // also modifies a2.a
+
+ + +
+ +
+ +
+
+
+
+ +
+
    +
  • static method applies with no instance
    • +
+ +
+
+ +
+ +
+ +
+ + 
class B {
+
+public:
+  static int foo();
+};
+
+ + +
+ +
+ +
+ +
+ + 
  // do not need an instance to be called
+  B::foo();
+
+ + +
+ +
+ +
+
+
+
+ +
+

Static members and static members (python)

class A:
+    # in the scope of the class
+    a = 1
+
+    def __init__(self):
+        pass
+
+
+a1 = A()
+a2 = A()
+
+a1.a = 2 # also modifies a2.a
+
+ +
+
+
+
+ +
+
    +
  • static method applies with no instance
    • +
+
class B :
+
+    @staticmethod
+    def foo(cls):
+        print(cls)
+
+
+# do not need an instance to be called
+B.foo()
+
+ +
+
+
+
+ +
+

Singleton generic solution

+
+
+ +
+ +
+ +
+ +
+ +
+ +
+
+ +
+
    +
  • Consequences:
      +
    • controlled creation of the unique instance
      • +
    • Transverse/global access to instance (with class name)
      • +
    • Polymorphic behavior
      • +
    +
    • +
+ +
+
+
+
+ +
+ +
+ +
+ + 
struct Particles {
+  static Particles &get();
+
+private:
+  Particles();
+  static Particles obj;
+};
+
+struct Planets : public Particles {
+  static Particles &get();
+};
+
+ + +
+ +
+ +
+ +
+ + 
  Particles &obj = Planets::get();    // creation
+  Particles &obj2 = Particles::get(); // access
+
+ + +
+ +
+ +
+
+ +
+ +
+ +
+ +
+ +
+ +
+
+
+
+ +
+

Abstract Factory

    +

  • General description: Provides an interface for creating dependent/coherent objects +without specifying their concrete classes.

    +
    • +

  • Our problem (Particles)

    +
      +
    • Particles code working for various particle types
      • +
    • A run deals with a single particle type
      • +
    • Other objects (IO, Compute) must be matching the (unique) particle type
      • +
    • "Automatic" creation of all the objects
      • +
    +
    • +
+ +
+
+
+
+ +
+
    +
  • Abstract Factory
      +
    • The system is independent of how the objects are created/composed
      • +
    • Related objects are designed to be used together: needs to be enforced
      • +
    • Objects are polymorphic (manipulated by interface)
      • +
    +
    • +
+ +
+
+
+
+ +
+

Example with Series

+
+
+ +
+ +
+ +
+ +
+ +
+ +
+
+ +
+
    +
  • Consequences:
      +
    • Isolating concrete/daughter classes
      • +
    • Creating packages of objects made easy
      • +
    • Promotes consistency among objects
      • +
    • Supporting new kinds of objects is difficult (modify the creation routines)
      • +
    +
    • +
+ +
+
+
+
+
+ + + + + + +