Please enable JavaScript.

Coggle requires JavaScript to display documents.

SQ (Bad code (Rigid (kleine Veränderungen ziehen größere Veränderungen …

- - - - progreamming by intention
        
        focus on one problem at a time
        
        Imagine how the rest of the code could be
        '
        
        the Test we make up defines names and attrs and so on...
      - thinking in Test rather then tasks
        
        tests should be
        
        atomic
        
        isolated
    - - fake it it, until you make it
        
        then triangulate
        
        new test until you fit the requirement
        
        Breadth-first strat
        
        higher-level functionality fisrt
        faking lower levels
        
        depth-fisrt strat
        
        lower lvl first
        compose higher lvl after lower done
    - - make it look good
        
        make new Test for new funkctionality
    - - think of perfekt code as if it alreaady exists
  - - - unit -> Integration -> System
      - requested features working?,..
    - - : features speed? memory/CPU used?
    - - code well organized (clean)?
    - - good user experience & performance?
  - - - trustable
        
        no test testing
        
        Maintaniable
        +
        
        F.I.R.S.T.
        
        Fast
        
        running often.
        
        Independant
        
        from other tests
        
        repeatable
        
        run anywhere
        
        self-validating
        
        True or False
        
        timely
        
        test writing right befor production code
        
        Atomic
        
        small tests
        
        hundererst of tests
- - - - one calss -> one job -> one boss
        
        indicators to break a class down
        
        many pulblic fonction
        
        unrelated functions (using different group of instances var.)
        -> lack of cohesion
        
        modifying the same classes for every new requirement
    - - everything open for extension
        but close to modification
        
        while adding a new class, never modify an old one to handle it
        
        fillSquare
        
        fillCicrle
        
        fillTriangle
        
        ...
        
        wird zu
        
        Abstract class
        (or interface)
        
        compose better then extend
        
        generalze dont care how the funcion works
        
        never ask a object "who are u?"
        say "do it ur way!"
    - - high lvl not on low lvl debendend
        
        dont depend on detail
        
        never depend on concret class.
        always on abstarct calsses
        
        A :arrow_right: B :arrow_right: C
        A dependend to C but dosnt know C
        BAD
      - Modules
        
        Layer interaction e.g.
        
        presentation
        
        buissnes
        
        persitance
        
        database
        
        packages e.g.
        Logic :arrow_right: Graphics :arrow_right: 3D library
        
        Better: Boundary
        
        Package 1 {Class A; Interface B}
        
        Package 2 {Class BImpl; Interface C}
        
        Package 3 {Class CImpl}
        
        no direct debendancy on B Class fo rA
      - everything is coupled :angry:
        
        Solution:
        
        cut into implemetation and Interface
        
        High level from low level
        
        seperate excangable :arrow_right: detail
        
        make detail implement an interface
        
        Depen on own Abstarction
        
        talk to my interface
      - Depend only on abstarction or interface
        
        Nver call directly outside the package
      - plugins, frameworks...
      - Adapter
        
        button takes a lampAdapter with takes a lamp
        
        basically a wrapper class
      - Tamplate
        
        seperate Algorithm form imolementation
        
        override single steps of a algorithm
      - Stragegy
        
        seperate algorithem from implementation
        this time with interface
        
        different pathfinders e.g.
    - - no fat interfaces
        
        What ar Fat
        
        to many public Functions
        
        Class with different types of clients
        
        serverell clients use only different part of the methods #
        
        Why
        
        lac of dicipline
        
        interface pollution
        
        lazy
        
        violating cohesion
        (singel respnsibility Princible)
        
        LCOM plugins
        
        Encapsulating
        having all methods public
        mixind high and low lvl abstraction
        
        What to do
        
        make several interfaces the fat interface extends
        
        many client-specific interfaces
        
        or Adapter pattern #
        
        make some methods privade
        how its done
        seperate how and what
        
        Composigion over Inheritance
      - Client interface
        services provided to classe
        public Funktions
    - - Parent an dchild have the same Behavior
        same output with the same in put
      - can replace every class with a childclass
        
        behave like ur parent
        
        Square is no Rectangle
        
        Concequences
        
        Fragile
        Rigid
        often brak open close
        
        not the same public behavior
        
        or adopt a new one
        
        every object oriented langueage...
      - Subtypes must be substitutable for their base ttypes
- - - - Boolean
        has or hans't
        
        Correctness
        
        behaves according to specifications
        
        Robustness
        
        correctness :heavy_plus_sign: reasonable behavavior outside specifikations
      - statistical
        how much has it
        
        Dependability
        propability for correctness
        
        Reliability
        
        mean time to failure
        design flaws
        
        Security
        
        high-stakes Reliability
        violant attacks
        mean time to detection
        Mean time to exploit
        
        Confidentiality
        
        unauthorized access
        
        Integrity
        
        prevent loss or damage to data
        
        Authentication
        
        user privileges
        identify each user
        
        Availability
        
        ability to continue deliver its service
    - - Latency
        respond time
      - Throughput
        batch interactions per second
      - Efficiency
        resource optimalization
      - Capacity
        simultan users
      - Scalability
        what happens when workload grows?
    - - Ease of use
        
        simplicit system interaction
        
        unifomity of interaction patterns
        
        abailiability of help menus
        
        use of simple vocabulary
        
        tolerance to misuse
        
        ...
      - Ease of Learning
        
        intuitiveness of interaction
        
        conisitency of interaction
        
        uniformity of system outputs
        
        ...
      - Customizability
        
        options for endusers
        
        add features
      - Calibrability
        
        let endusers specify operational requirements
      - Interoperability
        
        work in conjunction with other applications
    - - Dev-cost
      - Maintainability (cost)
      - Portability
        cost of migration
      - Reusability
    - - Design Integrity
      - Modularity
      - Testability #
      - Adaptability
        
        easy to add features
- - - - Inheritance
        extends
      - Aggregate
        clear diamand
        dont care where u were born
      - Composition
        full diamand
        born with me die with me
      - dependency
        dotline simple head
        use a function from B just once
      - implements
        dotline clear head
        implements
- - - - replacing parameters with defaults step by step
      - generating to many construcotrs
        couppeling inside the class
    - - reflection
        
        extract all methods (and invoke them)
      - Nullary Constructer + getters and setters for everything
      - set all parameters seperatly
        Object is availiable while not fully constructed
    - - return an instance of the class
        
        private constructor
        newInstance(...) Methode -> return new A(..)
        
        These new Constructor can be named
      - flexible
        readable
    - - static Inner Classes
        
        private constructer
        setting the parameters in a Builder
        creating the Objekt all at once on Builde