/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