Upload
norma-lindsey
View
218
Download
0
Tags:
Embed Size (px)
Citation preview
CS 4240: The OO Paradigm Revisited
Readings: Chap. 1 of Design Patterns Explained
OO (some review)Coupling, cohesion
Old problems Before OO, functional decomposition
Break problem down Function deals with subproblem Hierarchical. Levels of abstraction
Problems: Control and coordination centered in main method Required changes have big impacts Logic may be distributed Data changes affect may modules
Functions: What we call them:
functions, methods, modules Functions are a core construct in OO
and non-OO programs Principals of good functions apply in
either language But less of a problem in OO – can you
think why?
Good qualities in functions: Lots written about this! Clean Code: A Handbook of Agile SW
CraftsmanshipRobert C. Martin Read Chapter 3 in UVa digital library
version
Good Qualities in Functions Small
How small? Do One Thing: Strong Cohesion
Why? One level of abstraction per function
Thus, functions fall into levels of abstraction Name reflects the one task it does
Interface Qualities of Functions
What about its interface? Inputs, return value/arguments Other sources of data or “output”
Side effects
Some rules?
Good Qualities in Functions (2)
Number of arguments: small “Bundling” arguments
Flag arguments What are they? What bad thing do they
suggest is happening? Avoid side effects Avoid output arguments
Good Qualities in Functions (3)
Don’t Repeat Yourself (DRY) Command/Query Separation
Do something. Or answer something.Don’t do both.
Returning Errors Return value? Output argument?
Burden on caller? Exceptions: what advantages?
Design Representation If you’re just programming with
functions (not OO), how could you represent your system?
Comments on Struct. Chart How are data and functions tied together? Can procedural abstraction be done? Data abstraction? How sensitive to change are parts of this
design? Where? Page 8 of DPE text: can a function cope with
variability in data? (Will this be an issue?)
Requirements See textbook’s discussion on
requirements and why they change.
Bottom line:
Change is inevitable. Deal with it.
Design Principles (again) Decomposition leads to modularity Properties of modules:
Internal “goodness” Inter-module relationships
Cohesion Coupling
Note: old terms first defined for function-oriented modules
Cohesion of a module “How closely operations [what’s
encapsulated] in a module are related.” Think of:
Strength of purpose A cohesive group of people works well
together towards a goal Extreme of non-cohesive OO module:
a god class
Coupling between modules “strength [or goodness] of the connection
between two modules.” We want quality connections. Why?
Flexibility, independence of modules “Looser” connections, less brittle system Reusability
Goal: Loosely-coupled modules, each highly cohesive
Coupling: What’s “Good”? How do modules “connect”?
Invoke operations in each other [dynamic] Small operations, or start/invoke something larger
Pass data to each other [dynamic] Defined in terms of each other [static]
General: Simple, as little as possible (data) Direct connections, very visible Flexible
E.g. report an event, but not tell the other module how to handle it
Back to Functional Decomposition
Side effects Finding bugs is the problem, not fixing
them
Change to data impact many functions Snowball effect, cascade of changes
OO Improves This Because Modules become responsible for:
Encapsulating data Controlling access, maintaining intergrity
Encapsulating operations on data Functionality is bound to data Why is this an example of DRY principle?
For a modules in OO, we define: Responsibilities, data, operations
Classes in Java, C++ “My responsibilities?” What my role is! Clear how data and operations are defined when
we write a Java class, but what about responsibilities? Implied by operations?
Answer: Note in the code. Maybe in the comments. Certainly
in the design (even if implicit) Responsibilities matter a lot in understanding the
design.
Step back: Perspectives of modules Martin Fowler (UML Distilled) talks about
three levels of perspectives to talk about modules (or SW development)
Note we’re practicing abstraction in doing this! Explain why to me later on!
Note: it’s easier to understand this if you think about limiting it to objects for now
Levels of perspective in OO Conceptual
Domain-level, problem-level -- not yet considering solutions
What is an object’s responsibilities? Specification
Solution-level, but an abstract view Interfaces, not internal implementation
Implementation Code level: full details of how it’s coded
So… What’s an Object? Depends on what level you’re using, where
you’re at in development Conceptual: set of responsibilities Specification: set of methods (an interface) that
meets its responsibilities Implementation: coding you’ve learned to do
Designers work at Specification level (mostly) Analysts work at Conceptual level (mostly)
Classes, Objects and Instantiation
Review! What’s an instance? What’s instantiation?
Do we need classes to do OO programming? No. But why are they helpful? Define common properties. (DRY again.)
Abstract Types Review: abstract class vs. interface How are they used? What’s common
about them?
Explain: Collections of these. References to these.
Review: polymorphism What are the mechanics of
polymorphism in OO? (Implementation level perspective)
At a higher level, what’s it for?
Cohesion How diverse are the things inside an
“entity” A what? Module, function,… In OO a class.
What’s this mean? Class should represent a single
abstraction Or, it should address a single general
responsibility
Problems Created by Bad Cohesion Hard to understand the class If two abstractions grouped into one class,
that implies a one-to-one relationship What if this changes?
Often we specialize a class along a dimension This new thing is like the existing one except we
extend it in one area (dimension) Problems arise when each of the several
abstractions need such specialization
Note meaning of “specialization” here
The “Multiplicity” Problem Consider an Account class that holds:
Customer name, address, tax ID, Account status, etc.
What if one customer needs two accounts? Two Account objects, but each stores name
and address What if one account has two owners?
You can’t do this, unless you create a collection in each Account to hold owner info
Specializing along Dimensions Let’s say we need variations on class Account
First, based on account type: Cash Account, Credit Account
Second, based on customer type: Individual Account, Institutional Account
These are two dimensions, but are they mutually exclusive?
We often compose along two dimensions E.g. Individual Cash Account, Individual Credit Account,
etc. Specialization often implemented as inheritance:
Do we really want multiple inheritance?
Inheritance Diamonds
Account
Cash Account Credit Account Individual Account Instiutional Account
Individual Cash Account Individual Credit Account
Two more classes here
Structures like this cause messy problems!
Separating Abstractions
Account
Cash Account Credit Account Individual Customer Instiutional Customer
Customer
*
owner
1..*
Composition across dimensions achieved by aggregation (“PART-OF”)
You can see how this improves earlier problem too
An OO Design Principle…
Prefer aggregation over inheritance!
Keep in mind: Often at the conceptual perspective, the
“IS-A” relationship is true But at the design/implementation level, we
don’t use inheritance
How to Achieve Better Cohesion Some of this is just good OO experience We can learn from database normalization
Eliminate redundancy Attributes should have a single value and should not
have structure (repeating groups of things) Attributes always describe an instance of its
containing class That’s what attributes are all about! State values that
define a particular instance
Note: there are always tradeoffs! Sometimes we combine abstractions into one class for efficiency.
Coupling and Class Design How dependent an object/class is on
the world around it How many connections Nature of the connections Will changes cause a “ripple effect”?
Our goals: Reduce coupling if possible Improve nature of necessary coupling
Forms of Coupling (from Richter) Identity Coupling
An object contains a reference or pointer to another object
Eliminate associations or make them one-way
Representational Coupling An object refers to another through that
object’s interface How it does this affects the degree of coupling
Forms of Coupling (cont’d) Subclass Coupling
Object refers to another object using a subclass reference for that object
Not the more general superclass or interface A client should refer to the most general
type possible Why? Subclasses may be added later, possibly
by someone else Try to write code that minimizes
dependencies on subclass details Instead rely on the common interface defined in
the superclass or interface
Reminder: Use Java Interfaces to Avoid Subclass Coupling Java’s interfaces; C++ classes with pure
virtual functions and no data members Interfaces define a role not a class-
abstraction Many classes can pay that role
THE POINT: We can define reference to a thing in terms of
the role (interface) instead of the class type
Forms of Coupling (cont’d) Inheritance coupling
A subclass is coupled to its superclass at compile-time
In general, prefer late to early Seems like the only way to do things, but
ask: While the program executes, does an object need to change its subclass?
Aggregation is supported at run-time We’ll see the State design pattern later
Shy Code and the Law of Demeter
See handout on the Law of Demeter Summary: An object’s method should only
call other methods that belong to: Itself (the current object) Any parameter object that was passed to it An object it created Any of its components objects
What does this rule out? (Ponder that.) Delegation