The University of Sydney Page 1
SOFT3202
Presented by Josh Burridge
Lecture content in this unit has been
developed by:
Professor Bernhard Scholz
Dr Basem Suleiman
Josh Burridge
Software Construction & Design 2
The University of Sydney Page 2
What are we doing today?
– Revising old design principles
– Introducing new design principles
– Discussing the analysis of code
– Task 4 intro
– Major Project discussion
The University of Sydney Page 3
SOFT3202
Design Principles
The University of Sydney Page 4
SOFT3202 – Design Principles
SOLID
– Single Responsibility Principle.
– Open/Closed Principle.
– Liskov Substitution Principle.
– Interface Segregation Principle.
– Dependency Inversion Principle.
– Robert Martin's "Agile Software Development,
Principles, Patterns, and Practices"
The University of Sydney Page 5
SOFT3202 – Design Principles
GRASP – General Responsibility Assignment Software
Patterns/Principles
– Information Expert
– Creator
– Controller
– Low Coupling (evaluative)
– High Cohesion (evaluative)
– Polymorphism
– Pure Fabrication
– Indirection
– Protected Variations
– Craig Larman's "Applying UML and Patterns – An Introduction to
Object-Oriented Analysis and Design and Iterative Development"
The University of Sydney Page 6
SOFT3202
Design Principles – Let’s talk
about some more
The University of Sydney Page 7
SOFT3202 – Design Principles
KISS
– Keep It Simple Stupid, or Keep It Stupidly
Simple
– Make things as simple as possible, and no
simpler
The University of Sydney Page 8
SOFT3202 – Design Principles
YAGNI
– You Aren't Gonna Need It
– See https://martinfowler.com/bliki/Yagni.html
– Refers not to design quality (you are gonna
need that) – it refers to features
The University of Sydney Page 9
SOFT3202 – Design Principles
DRY
– Don't Repeat Yourself
– Refers to more than just lines of code!
The University of Sydney Page 10
SOFT3202 – Design Principles
Single authoritative representation of data /
Single Source Of Truth (SSOT)
– DRY principle applied to knowledge/data
– You should be able to change a single item of
knowledge in one spot only, not have to repeat
that change
– http://wiki.c2.com/?DontRepeatYourself
The University of Sydney Page 11
SOFT3202 – Design Principles
Coupling, Cohesion, Connascence
– Coupling
–What ‘bits’ of your software depend on
what other bits? What talks to what? What
requires changing if you change something
else?
The University of Sydney Page 12
SOFT3202 – Design Principles
Coupling, Cohesion, Connascence
– Cohesion
– Are your bundles of ‘stuff’ coherent?
• Are the methods in a class all acting on a
common set of data in that class
• Does a class need to gather a bunch of
info from outside itself to work?
• Are the classes in a package working
together to solve some broader common
purpose?
The University of Sydney Page 13
SOFT3202 – Design Principles
Coupling, Cohesion, Connascence
– Connascence
– A qualifier for ‘how coupled is coupled’
– Describes a hierarchy of coupling such that ‘how
many lines between boxes’ on a UML diagram
is broken down to actually how rigid this makes
the system.
– https://codesai.com/posts/2017/07/two-
examples-of-connascence-of-position
– https://dl.acm.org/doi/10.1145/130994.131
004
The University of Sydney Page 14
SOFT3202 – Design Principles
Coupling, Cohesion, Connascence
– Connascence
The University of Sydney Page 15
SOFT3202 – Design Principles
Law of Demeter
– “Only talk to your friends”
– How deep do your dependencies ‘dig’?
– If A depends on B and B depends on C, then A
depends on C – but how much?
– A calls B.getC().haveCdoSomething();
– A calls B.doSomething();
B calls C.doSomething();
– What is the connascence difference here?
The University of Sydney Page 16
SOFT3202 – Design Principles
Prefer Composition Over Inheritance
– http://wiki.c2.com/?CompositionInsteadOfInher
itance
– If a choice exists, inject dependencies to modify
behaviour polymorphically rather than create a
complex hierarchy
– Make use of interfaces to specific behaviour
The University of Sydney Page 17
SOFT3202 – Design Principles
Program to Interfaces, not Implementations
– Easier to mock
– Easier to swap out
– Better for interface segregation
The University of Sydney Page 18
SOFT3202 – Design Principles
Hollywood Principle
– "Don't call us, we'll call you“
– Is at the core of OO rather than procedural
design
– Inversion Of Control
– http://wiki.c2.com/?HollywoodPrinciple
– https://www.youtube.com/watch?v=zHiWqnT
Wsn4
|if you watch any video this semester, make it
this one)
The University of Sydney Page 19
SOFT3202 – Design Principles
– Consider this code:
if (employee.employeeDepartment == "sales"
&& employee.employeeTenureInYears >
thresholds.commissionRequiredTenure &&
employeeType == EmployeeTypes.SALARY) {
The University of Sydney Page 20
SOFT3202 – Design Principles
– Compare with:
boolean employeeQualifiesForTenure =
employee.employeeDepartment == "sales" &&
employee.employeeTenureInYears >
thresholds.commissionRequiredTenure &&
employeeType == EmployeeTypes.SALARY;
if (employeeQualifiesForTenure) {
The University of Sydney Page 21
SOFT3202 – Design Principles
Other simple things
– Use descriptive variable names. The wider the
scope, the more detailed the name
– Keep functions SMALL – decompose them if
they are big.
– Keep classes SMALL – same here
– Good design doesn’t live in the package level
– it lives in the lines of code. It doesn’t matter
how good your class structure is if your code
inside is awful
The University of Sydney Page 22
SOFT3202
Analysing Code
The University of Sydney Page 23
SOFT3202 – Analysing Code
– “You need to be twice as smart to read code
as you are to write it”
– Consequence: if you write code as cleverly as
you can you will be half as smart as you need
to be to read it afterwards
– Clever code is bad code – it is hard to read. It
is therefore hard to maintain and extend
– Your job as a developer is to write the dumbest
possible code that works (see KISS)
The University of Sydney Page 24
SOFT3202 – Analysing Code
– Dumb code can still be
– Elegant
– Idiomatic
– Performant (to a point)
– Dumb code that is well written is best.
– Your job as a software developer is to write
that dumb working code, and to do your best
to keep it dumb even where there is pressure to
make it ‘clever’
The University of Sydney Page 25
SOFT3202 – Analysing Code
– Your job when analysing code for design is
largely detecting cleverness where it shouldn’t
exist
– “Could it be simpler?” (common)
– “Is it too simple?” (very rare)
– “Does it work” (best question to ask first)
The University of Sydney Page 26
SOFT3202 – Analysing Code
– The part that makes this difficult is that very
often a little cleverness in one spot is necessary
to avoid a lot of cleverness somewhere else
– Design patterns are mostly this little bit of
cleverness
– The trick lies in identifying whether they
actually are avoiding cleverness, or just adding
it
The University of Sydney Page 27
SOFT3202 – Analysing Code
Excerpt from your actual exam specification (more info in Week 13
lecture)
– Feature Modifications Made: Describe the visible changes to your
application from the perspective of a user running it, from the
perspective of features which have changed/added/been removed,
and any changes to the method the user accesses them.
– Base Code Discussion: Describe the way your base code influenced
your implementation of your extension. In particular highlight which
aspects of your base code made your implementation easier or more
difficult than it could have been. You should ensure you reference
design patterns in this discussion, whether ones you used, or ones you
did not.
– Resulting code discussion: Describe the way your code has ended
up after implementing your extension. In particular highlight what
positive or negative impacts your extension has had on the
maintainability, extensibility, and modularity of your code.
The University of Sydney Page 28
SOFT3202 – Analysing Code
– Exam: dynamic, your code has just changed
– Task 4: static, you will be analysing code in-place
– Key Criteria
(for us – see
https://en.wikipedia.org/wiki/List_of_system_qual
ity_attributes):
– Maintainability
– Extensibility
– Modularity
– These contain every principle discussed today (and
more)
The University of Sydney Page 29
SOFT3202 – Analysing Code
– Maintainability
– Maintenance is a computer-aided process, but
a human-driven one
– Includes all forms of testing
– Includes code readability, clarity, idiom, style,
documentation
– Includes how likely bugs are to develop, hide,
recur through regression.
The University of Sydney Page 30
SOFT3202 – Analysing Code
– Extensibility
– Deals with the addition of new features
– How simple to add a new feature right now?
– How simple to add many new features over
time?
– What potential for bugs in new code exists
when adding new features? Old code?
The University of Sydney Page 31
SOFT3202 – Analysing Code
– Modularity
– How decoupled and cohesive is the code?
– How reusable are the components?
– Is SRP and interface segregation being
followed?
The University of Sydney Page 32
SOFT3202 – Analysing Code
– Key: ‘analysing the software design’ is a
massive undertaking and probably not very
useful
– Analysing an aspect of the software, or
analysing a specific pull request (see: code
reviews), or analysing the software in the
context of a proposed change is far more
useful
The University of Sydney Page 33
SOFT3202
Task 4
The University of Sydney Page 34
SOFT3202 – Task 4
– Intended to help you with your exam report
– Not to pull significant amounts of time away
from your major project
– Your task: to analyse the design of an existing
piece of software and consider the impact of
this design on a proposed new feature
The University of Sydney Page 35
SOFT3202 – Task 4
– Overall steps:
– Look at the code and understand it
– Think about a potential change
–Write about how the code design supports
or inhibits this change
– Handicap mode if required:
– Actually make the change
– Spend time you don’t really need to with the
benefit of knowing more about the effects of
the design
The University of Sydney Page 36
SOFT3202 – Task 4
– The code: Glank/Java-Games/Tetris
– Nothing special, not plucked out to show an
example of great or terrible code, just something
a) Written in Java
b) Suitably complex without being overwhelming
c) Not dependent on a bunch of obscure
libraries
– Seems likely to have been written while the
author was a student or recently afterwards
(developing a public code presence like this as a
student is a great idea – we will talk about using
your major project as a “look at what I can do”
portfolio piece in the last lecture)
The University of Sydney Page 37
SOFT3202
Major Project
The University of Sydney Page 38
SOFT3202 – Major Project
– Most of you will have had marks released
– A small number are still waiting on marking – I
will be sorting those out tonight
– There are some good observations and some
poor observations
The University of Sydney Page 39
SOFT3202 – Major Project
– There were some very impressive submissions in
terms of UI/usability – I am anticipating some
very nice pieces of software by the end of
Week 13
– Consider the following for inspiration:
The University of Sydney Page 40
SOFT3202 – Major Project
The University of Sydney Page 41
SOFT3202 – Major Project
– It usually looks like it takes a lot more work
than it actually does to achieve something like
this
– JavaFX does most of the work for you – learn
the tools of your trade, and use them properly
– Many submissions were the flat grey default
(not unexpected for Milestone 1, but please
work on this for Milestone 2)
The University of Sydney Page 42
SOFT3202 – Major Project
– Design-wise there were some common issues:
– Model logic in the view
– Testing consequences
– Lack of testing, or poor testing
– Forgetting the most basic Java knowledge
– Don’t ignore warnings
–Generics: unsafe/unchecked = you are
doing something wrong, FIX IT!
– Basic code readability
The University of Sydney Page 43
SOFT3202 – Major Project
– Check Ed for more details about your API: filter
to your API categories and read every post.
Missing out on these discussions could cost you a
lot. They are considered part of the
specification.
The University of Sydney Page 44
SOFT3202 – Major Project
– Implementation & Design discussion