Software Development Cross Solution - Index of - Free

Going from multiple responsibilies to a single responsibility
Once you’ve done an analysis, you can take all the methods that
don’t make sense on a class, and move those methods to classes
that do make sense for that particular responsibility.
We used our analysis
to figure out that
these four methods
really aren’t the
responsibility of
Automobile.
Now Automobile
has only a single
responsibility:
dealing with its
own basic functions.
Automobile
+ start() :void
+ stop() :void
+ changeTires(tires : Tire[]) :void
+ drive() :void
+ wash() :void
+ checkOil() :void
+ getOil() :int
Automobile
+ start() :void
+ stop() :void
+ getOil() :int
Q: How does SRP analysis work when a method takes
parameters, like wash(Automobile) on the CarWash class?
A: Good question! For your SRP analysis to make any sense, you
need to include the parameter of the method in the method blank. So
you would write “The CarWash washes [an] automobile itself.” That
method makes sense (with the Automobile parameter), so it
would stay on the CarWash class.
Download at WoweBook.Com
Driver
+ drive(a : Automobile) :void
CarWash
+ wash(a : Automobile) :void
Mechanic
good-enough design
It’s a driver’s
responsibility to drive
the car, not the
automobile itself.
+ changeTires(a : Automobile, tires : Tires[]) :void
A CarWash
class can
handle washing
an automobile.
A mechanic is responsible for
changing tires and checking
the oil on an automobile.
Q: But what if CarWash took in an Automobile parameter
as part of its constructor, and the method was just wash()?
Wouldn’t SRP analysis give you a wrong result?
A: It would. If a parameter that might cause a method to make
sense, like an Automobile for the wash() method on
CarWash, is passed into a class’s constructor, your SRP analysis
might be misleading. But that’s why you always need to apply a good
amount of your own common sense and knowledge of the system in
addition to what you learn from the SRP analysis.
you are here 4 159