The document provides an introduction to object-oriented programming (OOP) principles, focusing on design patterns, coupling, cohesion, and their importance in creating manageable and effective object-oriented software. It emphasizes the tension between coupling and cohesion in design and introduces the Model-View-Controller (MVC) architecture as a critical design pattern for maintaining flexibility and separation of responsibilities. Additionally, it discusses the benefits and potential drawbacks of employing design patterns in software development.

1. Introduction
to Patterns
Michael Heron

2. Introduction
 In the beginning there was the code.
 And the code was without form.
 And programmers said
 Let there be functions.
 And programmers saw the functions, and
saw that they were good.
 And then the programmer said.
 Let there be objects.

3. Object Oriented Programming
 Objects represent an excellent tool for
developing object oriented programs.
 However, like anything they can be used badly.
 There are issues of scale that come along with
developing an object oriented program.
 Many objects can become unmanageable.
 Coupling and Cohesion are constant problems.
 A good class has high cohesion.
 Related methods and attributes are
encapsulated together.

4. Object Oriented Programming
 For large programs, objects soon become
difficult to manage.
 Too many classes
 Too many interrelationships.
 Unordered and difficult to gain a broad view.
 Good designs require a higher level
abstraction.
 Abstractions that consist of related groups of
objects.

5. Objects – Bare Bones
 What defines an object?
 Objects have attributes (defined in the class)
 Objects have behaviors (defined in the class)
 Object have a state
 A better view is that an object is a cog in a
more complicated machine.
 It is a moving part with a specific responsibility in
a system.
 Representing a certain kind of unit, for example.

6. Building Objects
 How do we build objects?
 There are several methods.
 Natural language analysis is a useful tool.
 Underline nouns, verbs and adjectives in a
requirements document.
 Organic evolution
 Start with a class, build on it from there.
 Pattern based analysis
 Analyse the overall structure of the system.
 Create classes to fill specific roles.

7. Coupling and Cohesion
 One of the biggest problems OO developers
have is ensuring a good OO design.
 What is a good OO design, you ask?
 Certainly for people unfamiliar with how OO is
best done, it’s hard to objectively rate an
object architecture.
 Two objective measures exist for this though.
 As a rule, we are aiming for high cohesion
and low coupling.

8. Coupling
 Coupling relates to the amount of
interconnectedness of classes.
 We want this to be as low as is reasonably
possible.
 A coupling relationship is any composition,
aggregation, or inheritance.
 The more connections made between
objects and classes, the harder it is to make
any changes.
 Because of the knock-on effect associated.

9. Coupling
 If your program has high coupling, there are
several disadvantages built in:
 Changes in one object may result in
unexpected side-effects elsewhere in a
program.
 Often the cause is not at all obvious.
 Classes are difficult to understand at a glance.
 They make use of so much external
functionality.
 Classes are difficult to test.
 They cannot be easily extracted from their
context.

10. Coupling
 There are several types of coupling that exist.
 It’s not just the amount of coupling that matters,
but also the type of coupling.
 Content coupling is when one class directly
accesses data local to another class.
 This is terrible and should be avoided always.
 Data coupling is when a public interface is used to
exchange to exchange parameters.
 This is better.
 There are other kinds.
 We don’t have to go into them to any great
degree for now.

11. Cohesion
 Cohesion is the level to which an object
adheres to a single set of responsibilities.
 We want this as high as is reasonably possible.
 In a good object oriented program, each
object has one firmly defined responsibility.
 If you have a BankBalance class, it should
contain only the functionality for manipulating
the balance.
 It should not contain, for example, the address
of its owner.

12. Cohesion
 The dangers that come from low cohesion
are the same as that of high coupling.
 They’re really just two ways of reflecting the
same basic concept.
 Low cohesion is an insidious problem.
 Programs with low cohesion tend to become
even less coherent over time.
 It is a consequence of badly analysed and
badly designed programs.
 You’ll learn how to do this properly in third year.

13. The Tension of OO
Development
 Object Oriented programs are a tension
between coupling and cohesion.
 We increase cohesion by increasing
coupling.
 We reduce coupling by decreasing
cohesion.
 As OO developers we have to find a
happy medium between the two.
 In some cases, simple rationalisation of a
design can remove problems.

14. Design Patterns
 Design patterns fill the role of ‘high level
design’ in object oriented programs.
 They are a shorthand for particular collections of
objects, arranged in a particular way.
 Design patterns are battle-tested.
 A pattern only enters into common acceptance
when it has been shown to work in many
situations.
 Design patterns are generalised.
 A design pattern is to object design what an
algorithm is to lines of code.

15. Design Patterns
 Design patterns fall into one of several broad
categories.
 There are some competing definitions for these.
 In this module we’ll look at three families of
design patterns.
 Creational Patterns
 Behavioural Patterns
 Structural Patterns
 There are more, but these will give you a
grounding in the selection and use of
patterns.

16. Unified Modeling Language
 We are going to use a shorthand notation
form to represent design patterns.
 UML Class Diagrams – you may have
encountered these before.
 We will very briefly review them today.
 So that you can recognize what is happening
when they are used later.
 It’s important for developers to have a shared
vocabulary for discussing design issues.

17. Object Oriented Programs
 The relationship between objects and classes
becomes very complex in many computer
programs.
 Some means of representing this complexity
‘at a glance’ is useful.
 This is what a class diagram is used for.
 It gives the static view of a program’s
architecture.
 Other techniques exist too.
 They vary in effectiveness.

18. Class Diagrams
 At their simplest,
class diagrams are
just boxes with lines
connecting them to
other boxes.
 They show the
relationship
between classes
only.

19. Class Diagrams
 At the next level of usefulness, class
diagrams also contain information about
attributes and methods.
 Attributes in the second row
 Methods in the third
 At their best, class diagrams contain class
relationships, methods, attributes, and the
visibility of each.
 They also explicitly show multiplicity.

20. Class Diagram with Attributes

21. Why Use A Class Diagram?
 There are several reasons why using a
class diagram leads to a more complete
view of a project.
 It shows the relationship between classes in
a way that allows you to trace accessibility.
 It shows at a glance the amount of
coupling in a project.
 It shows at a glance the amount of
cohesion in a project.
 It shows at a glance the impact of change.

22. Representing Design Patterns
 A design pattern is a collection of (usually)
several different classes.
 It defines the interaction of these objects at a
higher level of abstraction.
 There are several kinds of documentation for
patterns.
 The one in most common usage is the Pattern
Language devised by the Gang of Four in the
book Design Patterns.
 We’re not going to get bogged down in the
details.

23. Benefits of Patterns
 Part of what design patterns bring to the
field of software engineering is a common
vocabulary for design
 Shorthand solutions for certain kinds of
recurring programming problems.
 Design patterns are ‘best practice’, and
thus allow for portability of the ‘lessons
learned’ of experienced developers.
 They are an aid to learning.

24. Benefits of Patterns
 They fit in easily with existing modern
programming techniques.
 Design patterns complement object
orientation and agile development.
 Design patterns reduce the need for
future large-scale refactoring.
 Tried and tested, and the result of
successive refactoring of their own.

25. Criticisms of Patterns
 Some of the patterns that are in common usage are
simple workarounds for missing language features.
 Some patterns are repetitions of things supported
syntactically in other languages.
 Can lead to systems that are heavily over-
engineered.
 Use with care.
 When you have a hammer…
 Patterns represent good solutions to recurring problems,
but they are no substitute for effective analysis.
 Counter-productive when building expertise.
 You learn more from failure than you do from success.

26. The Model View Controller
 Before we look at the various kinds of design
patterns, I want to spend the rest of this
lecture discussing the one most critical to
modern programs.
 It is the Model View Controller Architecture.
 It is a design pattern through which maximum
flexibility is maintained for the developer.
 It allows for easy portability between
functionality and interface.
 It is an example of a structural pattern.

27. Setting the Scene
 Imagine this!
 Mister Moneybags, hugely successful
software publisher, comes to you and says
‘Code me a fruit machine’
 You go away, open up Eclipse and
develop the best fruit machine anyone has
ever seen!
 Mister Moneybags says, ‘Excellent work!
Now I want it so that we can put a dozen
different games onto the same codebase’

28. Horrors!
 The monolithic design of putting all code
into a single class (or even several classes)
has one big issue.
 Reusability.
 It is common practice for beginning
developers to embed functionality into
the code that handles the presentation.
 What this does is tightly bind your
functionality to the context in which it is
delivered.

29. MVC
 The Model View Controller architecture
addresses this by providing a clean
separation of roles in a program.
 The Model, which handles the ‘business logic’
 The view, which handles the presentation of the
state of the model to the user
 The controller, which allows for the user to
interact with the model.
 In simple programs, the view and the
controller may be the same class.
 Often they will not be.

30. MVC - Model
 The model defines all the state and
functionality of a system.
 Everything except presenting information to the
user.
 The model makes no assumptions with
regards to the view of the data.
 It doesn’t matter to the model if the view is a
GUI, a phone display, or a text interface.
 The model may be represented by a single
class.
 More usually, it will be represented by several
classes.

31. MVC - View
 The view handles the presentation.
 It’s the user interface.
 The view has absolutely no code for altering
the state of the system.
 It sends queries to the model, and the model
sends the answers back.
 The only code contained within the view is
view-specific code.
 Turn an array of strings into a combo box, as an
example.

32. MVC - Controller
 The controller is what provides the user’s
ability to manipulate the system.
 It’s usually represented by the event handlers for
the controls that belong to the view.
 In an ideal world, the controller is an entirely
separate class to the view.
 For small, simple programs this is often over-
engineering.
 The controller defines the ‘stitching’ between
the view and the model.

33. The MVC
 The MVC is a ‘mega pattern’
 Usually its constituent bits will be made up of
other patterns themselves.
 The separation of the model and the view is
the key to the pattern.
 By default, Visual Studio will couple the view
and controller into a single class.
 This is not bad strictly speaking, but something
that can be altered for complex systems.

34. Value of Decoupling
 Why is it so important we separate out the
model from the view?
 Division of responsibilities allows for parallel
development.
 Model best handled by technical teams.
 View best handled by graphical, UI specialists.
 All that teams must agree on is the interface
between the different parts of the system.
 It allows for flexibility of deployment.
 A new interface can be ‘bolted on’ with
minimal difficulty.

35. Summary
 Design patterns are awesome.
 They are an aggregate abstraction for interactions
of objects.
 The patterns we will discuss belong to three main
families.
 Creational
 Structural
 Behavioral
 Design patterns lead to good OO programs.
 With the caveat that they can also lead to heavily
over-engineered systems if used indiscriminately.