Page 129 - DCAP405_SOFTWARE_ENGINEERING

Software Engineering

Notes be there the classes implementing the interface will have to implement those methods as well.
For example if we create an interface called Worker and add a method lunch break, all the
workers will have to implement it. What if the worker is a robot?
As a conclusion Interfaces containing methods that are not specific to it are called polluted or fat
interfaces. We should avoid them.

Single Responsibility Principle

A class should have only one reason to change.

In this context a responsibility is considered to be one reason to change. This principle states that
if we have two reasons to change for a class, we have to split the functionality in two classes.
Each class will handle only one responsibility and on future if we need to make one change we
are going to make it in the class which handle it. When we need to make a change in a class
having more responsibilities the change might affect the other functionality of the classes.
Single Responsibility Principle was introduced Tom DeMarco in his book Structured Analysis
and Systems Specification, 1979. Robert Martin reinterpreted the concept and defined the
responsibility as a reason to change.

Liskov’s Substitution Principle

Derived types must be completely substitutable for their base types.
This principle is just an extension of the Open Close Principle in terms of behavior meaning that
we must make sure that new derived classes are extending the base classes without changing
their behavior. The new derived classes should be able to replace the base classes without any
change in the code.
Liskov’s Substitution Principle was introduced by Barbara Liskov in a 1987 Conference on
Object Oriented Programming Systems Languages and Applications, in Data abstraction and
hierarchy.

Self Assessment

Fill in the blanks:
6. Abstractions should not depend on ………………...
7. Derived types must be completely …………………… for their base types.

8.4 Design Concepts

In order to deal with the complexity, software is designed in layers. When a programmer is
worrying about the detailed design of one module, there are probably hundreds of other modules
and thousands of other details that he cannot possibly worry about at the same time. For
example, there are important aspects of software design that do not fall cleanly into the categories
of data structures and algorithms. Ideally, programmers should not have to worry about these
other aspects of a design when designing code.

This is not how it works, however, and the reasons start to make sense. The software design is
not complete until it has been coded and tested. Testing is a fundamental part of the design
validation and refinement process. The high level structural design is not a complete software
design; it is just a structural framework for the detailed design. We have very limited capabilities

122 LOVELY PROFESSIONAL UNIVERSITY