SYST 17796
[Link]
Week 12: SOLID + DRY
[Link]
ROAD MAP
• Review Patterns
• SOLID and DRY principles
• ICE 5: SOLID + DRY
• Deliverable 3 Check-In/ exam date and
policies
[Link]
PATTERNS REVIEW
MVC
Let’s review how we refactored the previous code to
get a model, a view and a controller for the address
book.
Think of a time where it would make sense to use a
Singleton pattern.
Think of a time where it would make sense to use a
Factory Pattern
[Link]
SOLID + DRY
Definitions
We will end the course with an overview of some design
principles to keep in mind when designing and coding
larger systems.
The principles we will study have the acronym:
– Single Responsibility Principle
– Open Closed Principle
– Liskov Substitution Principle
– Interface Segregation Principle
– Dependency Inversion Principle
And Don’t Repeat Yourself
[Link]
SINGLE RESPONSIBILITY
Principle
Have each class do only one thing and focus its efforts
on that one function (all methods should be serving
that one purpose, or working towards it)
This gives us high cohesion.
Single responsibility test:
The <className> <methodName>s itself.
Let’s try it on the Automobile class from Chapter 8 of your text
book…
[Link]
AUTOMOBILE CLASS
UML Diagram
Methods…which one(s) violate the single responsibility
principle?
Start()
Stop()
checkOil()
getOil()
changeTires(Tire[*])
drive()
wash()
[Link]
OPEN CLOSED
Principle
Classes should be open for extension and closed for
modification.
So, you should design in such a way that the code can be
extended without you having the change your method
bodies.
Subclassing and overriding can accomplish this!
Let’s say you want a self-driving car after all….you could
extend Automobile and override the drive method! This is
a good example of the Open-Closed Principle in practice.
[Link]
LISKOV SUBSTITUTION
Principle
You must be able to use your subclass as a reasonable
substitute for your superclass.
So this one also involves inheritance….
If we wanted to call the checkOil() on our subclass of
AutoMobile (the AutonomousAutomobile class we just
used to demonstrate Open-Closed principle), would it still
make sense?
YES! So we are using inheritance correctly here.
Your book gives a good example of where a 3D board is NOT a
good subclass for a Board in a tiled game. Why not?
[Link]
INTERFACE SEGREGATION
Principle
Keep your interface separate from your model and your
controller!
This is so important because you might want to swap out your
interface.
An application that has both a desktop version and a mobile
version is a perfect example of this. You shouldn’t be re-
writing your logic to deliver your interface on another
device! You should keep the interface as modular as
possible to allow delivery via multiple interfaces.
[Link]
DEPENDENCY INVERSION
Principle
Lower layers should not be aware of high layers.
So now we have to define lower layers and higher level code.
The lower level code is the model code. Our base class,
like AutoMobile.
The higher level code is the logic code that works with the
lower level code, like mechanic.
The higher level module should not depend upon the lower
level module…both should depend upon abstractions.
[Link]
DRY
Don’t Repeat Yourself!
In Software quality assurance we call repeated code clones.
Clones are generally a sign of reduced quality and
increased risk…why would there be increased risk when
you have duplicated code?
If you see duplicated code, the trick is to isolate it to one
place and then put a reference to it in the other places
you found it. Often this is as simple as abstracting a
repeated part of a method into its own method and calling
it twice.
[Link]
ICE 5
Payroll Application
Take a look at the code for ICE 5 which depicts a Payroll
application whereby we add Employees to an Employee
List in the Payroll class, and then when we are done
adding people, we print out our payroll based upon the
number of hours each person worked, and their wage.
The code works well but is not well designed!
Your challenge (depicted in detail in the DropBox description
of ICE 5) is to refactor the code so that its design is
improved but don’t break the functionality! It should still
work the same as it did before, but have a better design.
[Link]
DELIVERABLE 3
Group check in
Please complete Project Deliverable 3
Exam Review posted on Slate
Next Week-Final Exam
[Link]
References
1. McLaughlin, B., Pollice, G. & West, D. (2007). Head first
object-oriented analysis and design. Sebastopol, CA:
O'Reilly.
2. Design Patterns. (2018) Retrieved From
[Link]
Liz Dancy 04/28/2025
