CORRECT Answers
High coupling (bad) - CORRECT ANSWER -Accesses internal variables without the use
of functions
-C++ friends
-Instance variable is another Object
Medium Coupling - CORRECT ANSWER -Passing entire data structures when only some
data is needed
-No variables are other objects
-Still accessing the object's variables without functions (directly)
Low Coupling - CORRECT ANSWER -Constant object passed through
-Variables of passed through object are only accessed through functions
Low Cohesion (bad) - CORRECT ANSWER Non-related function belong to one class
High cohesion (good) - CORRECT ANSWER Related tasks grouped into one class
Encapsulate what varies - CORRECT ANSWER -Put the parts of your code that changes
into separate classes e.g class for flybehaviour where it is overwritten by by flywithwings and
flynoway instead of creating new classes for each duck
-Less duplicate behaviour since ducks that are similar might override the same function and have
the same new function
Code to interface not an implementation - CORRECT ANSWER -Depend on abstractions
, not concrete classes
-Don't just create a baseball player class and baseball team class, create an athlete interface with
different sport classes and a general team class so team works with any sport, not just baseball
, Favour composition over inheritance - CORRECT ANSWER -Use "has-a" relationships
(composition) instead of "is-a" relationship (inheritance), whenever possible
-Bad = rubber duck inheriting from duck and overriding functions
-Good = the ducks having classes that represent their behaviour... flywithwings, flynoway
S - Single Responsibility Principle - CORRECT ANSWER -A class should only have one
reason to change AKA only one job
-Bad (too many responsibilities) = report class for getting data, formatting data, and saving to file
-Good = one report class, one formatting class, one saver class
-Or think car example with automobile, car wash, driver, and mechanic
O - Open / Closed Principle - CORRECT ANSWER -Classes should be open for extension
but closed for modification
-Extend class instead of changing source code if we need different behaviour as doing otherwise
can introduce bugs
-Use inheritance
-Instead of a bunch of if statements in a shape class, have different shape classes override the
function they need
L - Liskov substitution principle - CORRECT ANSWER -Subtypes must be suitable for
their base types
-When you inherit from a base class, you must be able to substitute your subclass for that base
class without affecting program correctness
-Think rectangle and square example, better to just inherit from shape
I - Interface Segregation Principle (ISP) - CORRECT ANSWER -Many client-specific
interfaces are better than one general purpose interface. Clients should not be forced to depend
upon interfaces that they do not use.
-Don't add new methods appropriate to only one or a few implementation classes e.g. a glass
door does not need a timerclient like a timeddoor