Design Principles Flashcards
Software Quality - internal factors
prob dont have to remember
- modularity
- comprehensibility (Verständlichkeit)
- cohesion (Zusammenhalt): clear responsibilities
- concision (Prägnanz): little code duplication, clear
code - correctness
Software Quality - external factors
prob dont have to remember
- Validity (ability to perform as defined)
- Robustness (ability to react appropriate to abnormal
conditions - Extensibility (ease of adapting to changes of
requirements) - Reusability (ability to serve for the construction of
different applications) - Compatibility (ease of combining elements with other
applications) - Portability (ease of transferring products to other
hardware and environments) - Efficiency (ability to use hardware resource
economically) - Ease of use (easy to learn and apply)
- Functionality (meet user expectations)
Software Quality - Main attributes
should be remembered
- Maintainability (able to evolve to meet changing
requirements of customers) - Efficiency (Does not waste system resources)
- Usability (must be usable by intended user)
- Dependability (Verlässlichkeit) (doesnt cause damage
in event of system failure, reparability,…)
How to measure software quality?
no generally accepted measure
- many different qualities
- heurisitcs that indicate canbe used -> software metrics
software metrics (how to measure quality of code)
- length of code
- cyclomatic complexity (paths through code)
- depth of conditional nesting
- weighted methods per class (depends on
sire/complexity) - depth of inheritance tree
software metrics - Pros and Cons
+ computed mechanically
+ may indicate bad design
- no notion of semantics of the code
- cannot detect coding errors
Code Metric - cyclomatic complexity
Cyclomatic complexity C (independent paths)
C := E - N + 2P
E = #Edges
N = #Nodes
P = #Connected Components
if C > 10 -> rethink design/coding
Code Measure - Class Coupling
indicates the amount of dependence between classes and packages
- Class C is coupled to D if C requires D directly or indirectly
Design Principle - Coupling done right!
give examples
Avoid tight coupling
- one change can result in cascade of changes
- classes hard to understand in isolation
- hard to reuse and low in modularity
Avoid very loose coupling
- Object-Oriented: connected objects to exchanges
messages
- need for independent objects that do all work
- may lead to unnecessary complexity
Code Measure - Cohesion
give example
measures the strength of relation among elements of a class -> all operations and data within a class should naturally belong to the concept modelled by the class
Types of Cohesion: Reasons why elements may be grouped together
undesirable
- coincidental (no meaningfull relation)
- temporal (all class elements executed together)
- sequential (one method is input to another)
- communicational (all functions/methods access same
input/output)
- functional (all elements contribute to achieve a single
well-defined responsibility) (ideal case)
ideal
Code Measure - Measuring Cohesion
LCOM
Class C, its fields F and methods M (except constructores)
undirected graph G
-> LCOM(C) #connected components (CC) of G
A high value indicates low cohesion
How to improve Cohesion?
- factor out common functionality from subclasses
- improve abstraction to summarize attributes
Responsible-Driven Design
Software object have responsibilities which are assigned to classes during object-design phase
Type of Responsibilities: doing
Performing a task - executing it themselfs - initiating action in other objects - controlling and coordination activities in other objects
Type of Responsibilities: knowing
Knowing and providing information to other objects
- knowing private and encapsulated data
- knowing related objects
Design Pricipless: Collaboration of two or more classes
When to use delegation?
(give example)
delegation is preferable
- less intrusive on overall design, more focused
- can be changed/determined at runtime
Design Pricipless: Collaboration of two or more classes
When to use inheritance?
(give example)
- non dedicated syntax like extends (in Java)
- only static calls -> no polymorphism
- > musst extend exisiting functionality organically
why should you programm to interfaces
give example
- interfaces provide independence of functionality from
implementation - does not exposes implementation details in public
methods - more stable than direct implementation
- to change implementations, sufficient to change
constructor
How to design field access?
give example
make instance fields NEVER public
-> would break information hiding
user accessor methods
-> responsible for aspects of user interface
How to recognize and avoid God classes
give example
class is failing SRP -> split and relocate responsibilities low cohesion, non communicating classes -> split and relocate responsibilities uses classes with public field accessors -> can indicate that responsibilities are located in wrong class -> redesign and relocate
=> distribute responsibilities uniformly among top-level classes
Single Responsible design
give example
one responsibility per class -> class should only have one reason to change
what is class proliferation
Too many classes for the size of a given problem
what is an object role?
A way to model behavior of an existing class in for example an association
(instead of class Father extends Person create an method in Person that creates an Person object called Father)
