0% found this document useful (0 votes)
1 views11 pages

Chapter06

The document discusses principles of object-oriented programming, focusing on designing classes that are understandable, maintainable, and reusable. Key concepts include responsibility-driven design, coupling, cohesion, and the importance of refactoring to maintain code quality. It emphasizes that software must be continuously maintained to avoid obsolescence and highlights the significance of high cohesion and low coupling for effective software design.

Uploaded by

alyaqein
Copyright
© All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
1 views11 pages

Chapter06

The document discusses principles of object-oriented programming, focusing on designing classes that are understandable, maintainable, and reusable. Key concepts include responsibility-driven design, coupling, cohesion, and the importance of refactoring to maintain code quality. It emphasizes that software must be continuously maintained to avoid obsolescence and highlights the significance of high cohesion and low coupling for effective software design.

Uploaded by

alyaqein
Copyright
© All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd

SW08 - Object-Oriented Programming and Principles

Designing classes

How to write classes in a way that


they are easily understandable,
maintainable and reusable

2.0

Main concepts to be covered

• Responsibility-driven design
• Coupling
• Cohesion
• Refactoring

© M. Kölling, University of Southern Denmark 1


SW08 - Object-Oriented Programming and Principles

Software changes
• Software is not like a novel that is
written once and then remains
unchanged.
• Software is extended, corrected,
maintained, ported, adapted…
• The work is done by different people
over time (often decades).

Change or die
• There are only two options for
software:
– Either it is continuously maintained
– or it dies.
• Software that cannot be maintained
will be thrown away.

© M. Kölling, University of Southern Denmark 2


SW08 - Object-Oriented Programming and Principles

World of Zuul

Code quality
Two important concepts for quality of
code:

• Coupling
• Cohesion

© M. Kölling, University of Southern Denmark 3


SW08 - Object-Oriented Programming and Principles

Coupling
• Coupling refers to links between
separate units of a program.
• If two classes depend closely on
many details of each other, we say
they are tightly coupled.
• We aim for loose coupling.

Loose coupling
Loose coupling makes it possible to:
• understand one class without reading
others;
• change one class without affecting
others.
• Thus: improves maintainability.

© M. Kölling, University of Southern Denmark 4


SW08 - Object-Oriented Programming and Principles

Cohesion
• Cohesion refers to the the number
and diversity of tasks that a single
unit is responsible for.
• If each unit is responsible for one
single logical task, we say it has high
cohesion.
• Cohesion applies to classes and
methods.
• We aim for high cohesion.
9

High cohesion
High cohesion makes it easier to:
• understand what a class or method
does;
• use descriptive names;
• reuse classes or methods.

10

© M. Kölling, University of Southern Denmark 5


SW08 - Object-Oriented Programming and Principles

Cohesion of methods

• A method should be responsible for


one and only one well defined task.

11

Cohesion of classes

• Classes should represent one single,


well defined entity.

12

© M. Kölling, University of Southern Denmark 6


SW08 - Object-Oriented Programming and Principles

Code duplication
Code duplication
• is an indicator of bad design,
• makes maintenance harder,
• can lead to introduction of errors
during maintenance.

13

Responsibility-driven design
• Question: where should we add a
new method (which class)?
• Each class should be responsible for
manipulating its own data.
• The class that owns the data should
be responsible for processing it.
• RDD leads to low coupling.

14

© M. Kölling, University of Southern Denmark 7


SW08 - Object-Oriented Programming and Principles

Localizing change
• One aim of reducing coupling and
responsibility-driven design is to
localize change.
• When a change is needed, as few
classes as possible should be
affected.

15

Thinking ahead
• When designing a class, we try to
think what changes are likely to be
made in the future.
• We aim to make those changes easy.

16

© M. Kölling, University of Southern Denmark 8


SW08 - Object-Oriented Programming and Principles

Refactoring
• When classes are maintained, often
code is added.
• Classes and methods tend to become
longer.
• Every now and then, classes and
methods should be refactored to
maintain cohesion and low coupling.

17

Refactoring and testing


• When refactoring code, separate the
refactoring from making other
changes.
• First do the refactoring only, without
changing the functionality.
• Test before and after refactoring to
ensure that nothing was broken.

18

© M. Kölling, University of Southern Denmark 9


SW08 - Object-Oriented Programming and Principles

Design questions
Common questions:
• How long should a class be?
• How long should a method be?

• Can now be answered in terms of


cohesion and coupling.

19

Design guidelines
• A method is too long if it does more
then one logical task.
• A class is too complex if it represents
more than one logical entity.

• Note: these are guidelines - they still


leave much open to the designer.

20

© M. Kölling, University of Southern Denmark 10


SW08 - Object-Oriented Programming and Principles

Review
• Programs are continuously changed.
• It is important to make this change
possible.
• Quality of code requires much more
than just performing correct at one
time.
• Code must be understandable and
maintainable.

21

Review
• Good quality code avoids duplication,
displays high cohesion, low coupling.
• Coding style (commenting, naming,
layout, etc.) is also important.
• There is a big difference in the
amount of work required to change
poorly structured and well structured
code.

22

© M. Kölling, University of Southern Denmark 11

You might also like