/2012
254
17/10/
Quality AssuranceCoding Principles II
SO
FTE
NG
Coding Principles II
eala
nd Part II - Lecture 13
klan
d | N
ew Z
eve
rsity
of A
uck
The
Uni
v
1
Today’s Outline/2012
y 2
5417/10/
• ModularityI f ti Hidi
SO
FTE
NG
• Information Hiding
eala
ndkl
and
| New
Ze
vers
ity o
f Auc
kTh
e U
niv
2
/2012
254
17/10/
SO
FTE
NG
Modularity
eala
nd
Modularity
klan
d | N
ew Z
e
LEGO is not a toy.It’s a way of life.
vers
ity o
f Auc
k y(Mike Smith)
The
Uni
v
3
Modularity/2012
y• Complex systems can usually be divided into simpler pieces
called modules
254
17/10/ called modules
• Module: self-contained component of a system– Has a well-defined interface to other modules
S t it i t f f it i l t ti
SO
FTE
NG
– Separates its interface from its implementation– Usually corresponds to a set of data types and code,
similar to Java packagesM d l t (i t th t d f d l )
eala
nd
• Modular systems (i.e. systems that are composed of modules) are easier to understand, develop and maintain– When dealing with a module the details of other modules can
be ignored (separation of concerns)
klan
d | N
ew Z
e be ignored (separation of concerns)– Modules can be developed independently– Better isolation between modules can prevent failure in one
module to cause failure in other modules
vers
ity o
f Auc
k module to cause failure in other modules– Modules can be exchanged by other modules– Modules can be reused in several systems
The
Uni
v
4
Component Frameworks/2012
p• Component frameworks support
the development and connection Multimedia stream processing
254
17/10/ the development and connection
of modules– Format for specifying module
interfaces
SO
FTE
NG
interfaces– Functionality for loading,
connecting and running modules
eala
nd
modules• Module interconnection languages
allow to specify the module interconnections in a system on a Image processing with Blender
klan
d | N
ew Z
e interconnections in a system on a high level– Programming-in-the-small:
coding a module
Image processing with Blender
vers
ity o
f Auc
k coding a module– Programming-in-the-large:
assembling a system with d l
The
Uni
v
5
modules
Separation of Concerns/2012
p• How to deal with complexity in a system?
S ti f (S C)
254
17/10/ • Separation of concerns (SoC)
– Separate issues (break down large problems into pieces) and concentrate on one at a timeB k i t di ti t f t
SO
FTE
NG
– Break a program into distinct features that overlap in functionality as little as possible
– Concern: a piece of a program, usually a feature or a particular program behavior
eala
nd
particular program behavior• Can be achieved in various ways
– Traditionally approached through modularityI OO t i t l d th d
klan
d | N
ew Z
e – In OO: separate concerns into classes and methods– In UIs: separate content from presentation and presentation
from application logicS i O i t d A hit t (SOA) lit f ti lit
vers
ity o
f Auc
k – Service-Oriented Architecture (SOA): split up functionality into different (web-) services
– Aspect-Oriented Programming (AOP): separate concerns into "aspects"
The
Uni
v
6
aspects
Cohesion and Coupling/2012
p g• Rule for the design of modules: “low coupling, high cohesion”
A d l h ld b hi hl h i
254
17/10/ • A module should be highly cohesive
– It should form a meaningful, self-contained unit– The parts in the module fit and work together closely
SO
FTE
NG
• Between modules there should be low coupling– Little dependencies between modules– A module is independent from the internal
eala
nd
pimplementation of another module
– Changing the implementation of one module does not require changing other modules
klan
d | N
ew Z
e
– The interaction between modules is restricted (through a stable interface)
– Each module should be understandable without having to d t d th d t il f th d l
vers
ity o
f Auc
k understand the details of other modules• Cohesion and coupling are usually related:
low coupling goes with high cohesion and vice versaI OO l ss ti s b t l ss s (l li ) if
The
Uni
v
7
• In OO: less connections between classes (low coupling) if we group related methods of a class together (high cohesion)
Coupling in OO Programming/2012
p g g g
Coupling is increased between two classes A
254
17/10/ and B if:
– A has an attribute that has type B– A calls a method of B
class A extends B {B b1;B m1(B b2) {
SO
FTE
NG
– A calls a method of B– A has a method which uses B
(return type, parameter or local var)
B m1(B b2) {B b3 = b1.m2(b2); return b3;
}
eala
nd
– A is a subclass of (or implements) BDisadvantages of high coupling include:
H d t d t d l i
}}
klan
d | N
ew Z
e – Hard to understand a class in isolation
– Change of one class often
vers
ity o
f Auc
k gforces changes in other classes
– Hard to reuse or test a class because dependent class must also be
The
Uni
v
8
because dependent class must also be available
Spaghetti Codevs Modular System
/2012
vs. Modular SystemSpaghetti Code
254
17/10/ • Haphazard connections, probably grown
over time• No visible cohesive groups
SO
FTE
NG
• No visible cohesive groups• High coupling: high interaction between
random parts 10 parts, 13 connections
eala
nd
• Understand it all or nothing
M d l S t
klan
d | N
ew Z
e Modular System• High cohesion within modules• Low coupling between modules
vers
ity o
f Auc
k Low coupling between modules• Modules can be understood separately• Interaction between modules is well-
l
The
Uni
v
9understood and thoroughly specified 10 parts, 13 connections,
3 modules
Layered Architecture/2012
y
• Example: Windows OS
254
17/10/
p• Layered architecture:
– Modules stacked t h th
SO
FTE
NG
onto each other– Often each level
can only access the
eala
nd
can only access the one below it
• Lowest level talks
klan
d | N
ew Z
e
directly to hardware• The higher, the more
abstraction from
vers
ity o
f Auc
k abstraction from concrete hardware
The
Uni
v
10
Separate Subsystems:Libraries and “Engines“
/2012
Libraries and EnginesAI Collision
Detection
254
17/10/
Scripting
Detection
SO
FTE
NG
PhysicsE i
p gEngine
AnimationE i • Example: game
eala
nd
Engine Engine • Example: game• Common problem:
making them
klan
d | N
ew Z
e
RenderingEngine
SceneManager
SoundEngine
gwork together
vers
ity o
f Auc
k
Input
ggg
The
Uni
v
11
InputSubsystem
Separate Subsystems:P r ll l Pr c ss s
/2012
Parallel Processes• Example: Google
M i d t l d
254
17/10/ • Massive data load
requires massive parallelism
SO
FTE
NG
p m• Several modules
working together tl d
eala
nd
concurrently and asynchronously
• Scalable
klan
d | N
ew Z
e Scalable architecture
• Modules can be
vers
ity o
f Auc
k
optimized independently
The
Uni
v
12
/2012
254
17/10/
SO
FTE
NG
Information Hiding
eala
nd
Information Hiding
klan
d | N
ew Z
e
Out of sight, out of mind.
vers
ity o
f Auc
kTh
e U
niv
13
Information Hiding/2012g
• Hide information that does not need to be i ibl i d t l / d l /
254
17/10/ visible in order to use a class/module/program
• Too much information can be confusing: what is important for usage and what not?
SO
FTE
NG
• Too much information can lead to undesired dependencies– If internals are visible & accessible, someone might
eala
nd
If nternals are v s ble & access ble, someone m ght use/change them (e.g. create a “hack” to use something in an unintended manner)
– If internals are changed then external code that relies on
klan
d | N
ew Z
e If internals are changed then external code that relies on them might not work anymore
• Allowing only restricted access gives us more flexibilityClass/module/program can be (ex)changed without breaking
vers
ity o
f Auc
k – Class/module/program can be (ex)changed without breaking other parts
– Many design decisions can be hidden and the system design l ith t ll si
The
Uni
v
14
can evolve without collapsing
Scope/2012
p• Where we declare a variable determines where it can be
d (i it )
254
17/10/ accessed (i.e. its scope)
• Scope of instance variables > scope of local variables in methods > scope of local variables in statement blocks
SO
FTE
NG
• The scope of a variable should be as small as possible• If a variable can be accessed where it should not be accessed:
confusion and mistakes
eala
nd
confus on and m stakesclass C {public int x;private int y;
class C {public int x;
klan
d | N
ew Z
e private int y;private int z;void m() {y = 0;
void m() {int y = 0;
vers
ity o
f Auc
k y = 0;for(z=0; z<10; z++)y += z;
return y;
int y = 0;for(int z=0; z<10; z++)y += z;
return y;
The
Uni
v
15
return y;} }
return y;} }
Access Modifiers/2012 Can be used to control access to groups of parts
1. public: bl h
254
17/10/ accessible everywhere
2. protected or no modifier (“default”): ibl i h k
SO
FTE
NG
accessible in the same package
3. private: l ibl f i hi h l
eala
nd
only accessible from within the class in which they are declared
G l l l if ( f )
klan
d | N
ew Z
e General rule: expose parts only if necessary (same as for scope)
Limitations of access modifiers:
vers
ity o
f Auc
k
• Only for pre-defined groups• Access rights only depend on who (what other class) wants
access, not how they actually need to use it (e.g. only 1 method)
The
Uni
v
16
The Concept of Interfaces/2012
p
There are different kinds of interfaces
254
17/10/ • User Interfaces
– Not just for software: any kind of tool– Usually it may change
SO
FTE
NG
Usually it may change,sometimes it must not change
• APIs: important for programs that use them• Java interfaces: important for classes that use other classes
eala
nd
• Java interfaces: important for classes that use other classes through them
/
klan
d | N
ew Z
e
The intention is always the same:• The interface defines and restricts
how something can be used
User/Client
I t f
vers
ity o
f Auc
k g• Users/clients perform operations
only through the interface• If the internal implementation changes Implementation
Interface
The
Uni
v
17
If the internal implementation changes, the users/clients do not have to change
Implementat on
Java Interfaces/2012
• Access modifiers can only control access depending on who uses
254
17/10/ a class/method/field
• With interfaces we can restrict access in a more flexible manner:
SO
FTE
NG
manner:– A class can implement several interfaces– Use a different interface depending on Client
eala
nd
• who uses it (which other class)• what it is used for
H ft i i t f
ClientClass
1 2 3
klan
d | N
ew Z
e • However: often using interfaces vs. accessing a class directly is a conscious decision
Interface AInterface B
vers
ity o
f Auc
k
– Programmers need to know that they should use interfaces
– Programmers need to know Implementation
Class
The
Uni
v
18
– Programmers need to know which interfaces to use 1 or 2 or 3 ?
Interfaces Example/2012p
public class USSEnterpriseimplements Maintenance, SafeControl, FullControl {
254
17/10/ public void navigate(Point dest) { … }
public void warpJump(Point dest) { … }public int checkSystems() { … }
SO
FTE
NG
public void selfDestruct() { … }}
i t f i t {
eala
nd
interface Maintenance {public int checkSystems();
}
klan
d | N
ew Z
e
interface SafeControl extends Maintenance {public void navigate(Point dest);public void warpJump(Point dest);
vers
ity o
f Auc
k public void warpJump(Point dest);}
interface FullControl extends SafeControl {
The
Uni
v
19
public void selfDestruct();}
Interfaces Example/2012p
Maintenance e = new USSEnterprise();
Scotty accessing the system:
Acc ss c n b
254
17/10/ Maintenance e = new USSEnterprise();
int status = e.checkSystems();
Spock accessing the system:
Access can be safely restricted by accessing h h
SO
FTE
NG
SafeControl e = new USSEnterprise();e.warpJump(new Point(103, 789));
Spock accessing the system: through an appropriate interface.
eala
nd
e.selfDestruct(); This won’t compile!!!
Borg accessing the system:
klan
d | N
ew Z
e
USSEnterprise e = new USSEnterprise();e.selfDestruct(); // Boooom!
Borg accessing the system:
vers
ity o
f Auc
k
• Choose an appropriate interface to access a class• Accessing a class directly may lead to dependencies and other
The
Uni
v
20
g y y pmistakes that could have been detected by the compiler
Enforcing Usage of Interfaces with Factories
/2012
Interfaces with Factoriesprotected class USSEnterpriseimplements Maintenance SafeControl FullControl {
254
17/10/ implements Maintenance, SafeControl, FullControl {
protected USSEnterprise() {} … }
public class EnterpriseFactory {
SO
FTE
NG
public static Maintenance getMaintenance() {return (Maintenance) new USSEnterprise();
}
eala
nd
public static FullControl getFullControl(String pw) {if(pw.equals("please"))return (FullControl) new USSEnterprise();
klan
d | N
ew Z
e
else throw new RuntimeException("Alarm!!!");}// similar for SafeControl
vers
ity o
f Auc
k
Now access only possible through interfaces:
}
The
Uni
v
21Maintenance e = EnterpriseFactory.getMaintenance();int status = e.checkSystems();
Today’s Summary/2012
y y
• Modularity means that a system is composed of
254
17/10/
y y pself-contained parts (modules) with well-defined interfaces
SO
FTE
NG
– Can be achieved by “separation of concerns”– Rule of thumb: “low coupling, high cohesion”
eala
nd
• Information hiding means that only the information is visible that is actually necessary to use something
klan
d | N
ew Z
e
– Access is only possible through well-specified interfaceI l t ti i t l hidd d b
vers
ity o
f Auc
k – Implementation internals are hidden and can be (ex)changed without breaking the system
The
Uni
v
22
Quiz/2012
Q
1. What advantages do modular systems offer?
254
17/10/
g y
2. Why do we want modules to be lowly coupled?
SO
FTE
NG
y m y p
3. What is the purpose of interfaces?
eala
nd
3. What is the purpose of interfaces?
klan
d | N
ew Z
eve
rsity
of A
uck
The
Uni
v
23