Software Construction

and Management
CSE-2073

Lecture 7 and 8

Dr. Muhammad Adeel

dr.muhammad.adeel.ntu@gmail.com
Find Real-World Objects
 Identify the objects and their attributes (data).
 Determine what can be done to each object.
 Determine what each object is allowed to do to others
 Determine the parts of each object that will be visible to
other objects — public/private.
 Define each object’s public interface.

2
Form Consistent Abstractions
 The principal benefit of abstraction: allows you to ignore
irrelevant details
 A good class interface allows you not to worry about the
internal workings of the class.
 The interface to a well-designed routine provides the benefit
at a lower level of detail
 The interface to a well-designed package/subsystem
provides the benefit at a higher level of detail.

3
 Abstraction allows you to take a simpler view of a complex concept

4
Poor Abstraction: Example
Class Employee {
…
public FullName GetName();
public Address GetAddress();
public PhoneNumber GetWorkNumber();
…
public bool IsJobClassificationValid(JobClassification jobClass);
public bool IsZipCodeValid(Address address);
public bool IsPhoneNumberValid(PhoneNumber phoneNumber);

public SqlQuery GetQueryToCreateNewEmployee();

public SqlQuery GetQueryToModifyEmployee();
public SqlQuery GetQueryToRetrieveEmployee();
…
}

The routines that expose SQL query details are at a much lower
level of abstraction than the Employee class, and they break
the Employee abstraction.

5
Encapsulate Implementation Details
 Encapsulate implementation details
 Encapsulation picks up where abstraction leaves off
 Abstraction says, “You’re allowed to look at an object at a
high level of detail.”
 Encapsulation says, “Furthermore, you aren’t allowed to look
at an object at any other level of detail”

6
Encapsulation rule
 Place data and the operations that perform on that data in the
same class
 Use responsibility-driven design to determine the grouping of
data and operations into classes

7
Housing-materials analogy
 encapsulation is a way of saying that you can look at the
outside of the house
 but you can't get close enough to make out the door's details.
 You are allowed to know that there's a door, and you're
allowed to know whether the door is open or closed,
 but you're not allowed to know whether the door is made of
wood, fiberglass, steel, or some other material, and
 you're certainly not allowed to look at each individual wood
fiber.

8
Inherit — When Simplifies Design
 Can provide great benefits when used well
 Can do great damage when used naively.
 Faculty extends LinkedList
 Erie extends City

9
Information Hiding
 Two categories of secrets
 Hiding complexity so that your brain doesn’t have to deal
with it unless you’re concerned with it
 Complicated data types, file structures, algorithms
 Hiding sources of change so that when change occurs, the
effects are localized

 The interface to a class should reveal as little as possible

about its inner workings.
 A class is a lot like an iceberg: 7/8 is under water, and only
1/8 above the surface.

10
 A good class interface is like the tip of an iceberg, leaving
most of the class unexposed

11
Identify Areas Likely to Change
 Identify items that seem likely to change.
 The requirements include a list of potential changes?
 Indicates the likelihood of each change?
 Separate items that seem likely to change.
 Compartmentalize each volatile component into its own
class or into a class with other volatile components likely to
change at the same time.
 Design the interfaces so that changes are limited to the
inside of the class and the outside remains unaffected.

12
A Few Areas Likely to Change
 Business rules
 Congress changes the tax structure
 A union renegotiates its contract, or
 An insurance company changes its rate tables.
 Hardware dependencies
 Input and output
 Nonstandard language features
 Data-size constraints
 Declare an array of size 100 vs named constant

13
A Few Areas Likely to Change
 Difficult design and construction areas
 Might be done poorly and need to be done again
 Status variables
 Indicate the state of a program and tend to be changed more
frequently than most other data.
 Example: error-status
 Originally define an variable as boolean and decide later that it
would be better implemented as an enumerated type (non, fatal,
warning)
 Approaches
 Don’t use boolean for a status variable.
 Use routines rather than checking the variable directly.

14
Anticipate Different Degrees of Change
 Think about the chance a change will occur.
 If likely, make sure the system can handle it easily.
 Only extremely unlikely changes should be allowed to have
drastic consequences for more than one class in a system.

 Factor in the cost of anticipating change.

 If a change is not terribly likely but easy to plan for, you
should think harder about anticipating it.

15
 Keep Coupling Loose
 Coupling - how tightly a
module (class or routine)
is related to other
modules.
 Loose Coupling -
modules have small,
direct, visible, and
flexible relations to other
modules.
 Try to create modules
that depend little on
other modules.

16
Coupling Criteria
 Size: number of connections between modules
 A 1-parameter routine is more loosely coupled to its calling
modules than a 6-parameter routine
 methodA(para a) vs methodB(para a, para b, para c, para d. para e,
para d)
 A class with 4 public methods vs a class with 40 public
methods.
 Visibility: prominence of the connection between two
modules
 Passing data in a parameter list is making an obvious
connection - good
 Modifying global data so that another module can use that
data is a sneaky connection – bad

17
Kinds of Coupling
 Simple-data-parameter coupling
 All the data passed between modules are of primitive data types and all the
data is passed through parameter lists
 simple parameters, or data structures all of whose elements are used by called
module
 Normal and acceptable

An example of data coupling is illustrated as a

module which retrieves customer address using
customer id.
String getCustomerInfro(String CustomerID);
String getCustomerAddress(String CustomerID)

18
Kinds of Coupling
 Object-parameter coupling
(a) Object1 requires Object2 to pass it an Object3.
(b) Object1 requiring Object2 to pass it only primitive data
types
 (a) is tighter than (b) because (a) requires Object2 to know
about Object3.

 obj3=o2.getObj3();
 int i=o2.getIntI();

19
Kinds of Coupling - cont
 Semantic coupling
 One module makes use not of some syntactic element of
another module but of some semantic knowledge of another
module’s inner workings.
 M2 uses global data after the data modified by M1.
 This requires M2 to assume that M1 has modified the data in the
ways M2 needs, and that M1 has been called at the right time.
 M1 passes a control flag to M2 that tells M2 what to do
 This requires M1 to make assumptions about the internal workings of
M2.

20
Global variable couping
 Example 1
 Modules cca and ccb can access and change the value of
global_variable
 Example 2:
 Modules cca and ccb both have access to the same database, and can both
read and write the same record

21
Control Coupling
 Module p calls module q

 Message:
 I have failed — data

 Message:
 I have failed, so write error message ABC123 —
control
Kinds of Coupling - cont
 Semantic coupling - cont
 Dangerous - changing code in the used module can break
code in the using module in ways that are completely
undetectable by the compiler.

 The point of loose coupling

 An effective module provides an additional level of
abstraction — reducing overall program complexity and
allowing you to focus on one thing at a time.

23
24
25
Look for Common Design Patterns
 The cores of ready-made solutions that can be used to
solve many of common problems.
 Reduce complexity by providing ready-made abstractions
 Reduce errors by institutionalizing details of common
solutions
 Provide heuristic value by suggesting design alternatives
 “Which of these patterns fits my design problem?”

26
Popular Design Patterns
 Abstract factory
 Supports creation of sets of related objects by specifying the
kind of set but not the kinds of each specific object.
 Adapter
 Converts the interface of a class to a different interface.
 Bridge
 Builds an interface and an implementation in such a way that
either can vary without the other varying.
 Composite
 Consists of an object that contains additional objects of its own
type so that client code can interact with the top-level object and
not concern itself with all the detailed objects.

27
Popular Design Patterns - cont
 Decorator
 Attaches responsibilities to an object dynamically, without
creating specific subclasses for each possible configuration of
responsibilities.
 Façade
 Provides a consistent interface to code that wouldn’t otherwise
offer a consistent interface.
 Factory Method
 Instantiates classes derived from a specific base class without
needing to keep track of the individual derived classes anywhere
but the Factory Method.
 Iterator
 A server object that provides access to each element in a set
sequentially.

28
Popular Design Patterns - cont
 Observer
 Keeps multiple objects in synch with one another by making an
object responsible for notifying the set of related objects about
changes to any member of the set.
 Singleton
 Provides global access to a class that has one and only one
instance.
 Strategy
 Defines a set of algorithms or behaviors that are dynamically
interchangeable with each other.
 Template Method
 Defines the structure of an algorithm but leaves some of the
detailed implementation to subclasses.

29