Design Principles

Question 1

Software Quality - internal factors

prob dont have to remember

Answer 1

• modularity
• comprehensibility (Verständlichkeit)
• cohesion (Zusammenhalt): clear responsibilities
• concision (Prägnanz): little code duplication, clear
  code
• correctness

Question 2

Software Quality - external factors

prob dont have to remember

Answer 2

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

Question 3

Software Quality - Main attributes

should be remembered

Answer 3

• 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,…)

Question 4

How to measure software quality?

Answer 4

no generally accepted measure

• many different qualities
• heurisitcs that indicate canbe used -> software metrics

Question 5

software metrics (how to measure quality of code)

Answer 5

• length of code
• cyclomatic complexity (paths through code)
• depth of conditional nesting
• weighted methods per class (depends on
  sire/complexity)
• depth of inheritance tree

Question 6

software metrics - Pros and Cons

Answer 6

+ computed mechanically
+ may indicate bad design

• no notion of semantics of the code
• cannot detect coding errors

Question 7

Code Metric - cyclomatic complexity

Answer 7

Cyclomatic complexity C (independent paths)

C := E - N + 2P
E = #Edges
N = #Nodes
P = #Connected Components

if C > 10 -> rethink design/coding

Question 8

Code Measure - Class Coupling

Answer 8

indicates the amount of dependence between classes and packages
- Class C is coupled to D if C requires D directly or indirectly

Question 9

Design Principle - Coupling done right!

give examples

Answer 9

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

Question 10

Code Measure - Cohesion

give example

Answer 10

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

Question 11

Types of Cohesion: Reasons why elements may be grouped together

Answer 11

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

Question 12

Code Measure - Measuring Cohesion

Answer 12

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

Question 13

How to improve Cohesion?

Answer 13

• factor out common functionality from subclasses

- improve abstraction to summarize attributes

Question 14

Responsible-Driven Design

Answer 14

Software object have responsibilities which are assigned to classes during object-design phase

Question 15

Type of Responsibilities: doing

Answer 15

Performing a task
- executing it themselfs
- initiating action in other objects
- controlling and coordination activities in other 
  objects

Question 16

Type of Responsibilities: knowing

Answer 16

Knowing and providing information to other objects

• knowing private and encapsulated data
• knowing related objects

Question 17

Design Pricipless: Collaboration of two or more classes
When to use delegation?

(give example)

Answer 17

delegation is preferable

• less intrusive on overall design, more focused
• can be changed/determined at runtime

Question 18

Design Pricipless: Collaboration of two or more classes
When to use inheritance?

(give example)

Answer 18

• non dedicated syntax like extends (in Java)
• only static calls -> no polymorphism
• > musst extend exisiting functionality organically

Question 19

why should you programm to interfaces

give example

Answer 19

• 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

Question 20

How to design field access?

give example

Answer 20

make instance fields NEVER public
-> would break information hiding

user accessor methods
-> responsible for aspects of user interface

Question 21

How to recognize and avoid God classes

give example

Answer 21

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

Question 22

Single Responsible design

give example

Answer 22

one responsibility per class
-> class should only have one reason to change

Question 23

what is class proliferation

Answer 23

Too many classes for the size of a given problem

Question 24

what is an object role?

Answer 24

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)