Design challenges

Design is a wicked problem

Design is a sloppy process
Design is about tradeoffs and priorities
Design involves restrictions
Design is non deterministic
Design is heuristic process
Design is emergent
Design characteristics
Minimal complexity
Ease of maintenance
Loose coupling
Extensibility
Reusability
High fan-in
Low to medium fan-out
Portability
Leanness
Stratification
Standard techniques
Levels of design
1. Software system
2. Division into sub systems/packages
3. Division into classes within packages
4. Division into data and routines within classes
5. Internal routine design
6 Working with classes

Benefits of ADTs
You can hide implementation details
Changes dont effect whole program
You can make the interface more informative
Its easier to improve performance
The program is more obviously correct
The program becomes more self documenting
You dont have to pass data all over your program
You are able to work with real world entities rather than low
level structures
Good abstraction good class interfaces
Present consistent level of abstraction in class interface
Be sure you understand what abstraction the class is
implementing
Provide services in pairs with their opposites
Move unrelated information to another class
Make interfaces programmatic rather than semantic when
possible
Beware of erosion of the interfaces abstraction under
modification
Dont add public members that are inconsistent with interface
abstraction
Consider abstraction and cohesion together.
Good encapsulation
Minimize accessibility of classes and members
Dont expose member data in public

Avoid putting private implantation details into class interfaces

Dont make assumptions about classes users
Avoid friendly classes
Dont put routine into the public interface just because it uses
only public routines
Favor read time convenience to write time convince
Be very very wary of semantic violations of encapsulation
Watch for coupling thats too tight.
Inheritance
Implement is a through public inheritance
Design and document for inheritance or prohibit it
Adhere to liskov substitution principal
Be sure to inherit what you want to inherit
Dont override a non overridable member function
Move common interfaces, data, and behavior as high as
possible in inheritance tree
Be suspicious of classes of which there is only one instance
Be suspicious of base class of which there is only one derived
class
Be suspicious of classes that override a routine and do
nothing inside derived routine
Avoid deep inheritance trees
Prefer polymorphism to extensive type checking
Make all data private, not protected
Member functions and data
Keep no of routines in a class as small as possible

Disallow implicitly generated member functions or operators

you dont want
Minimize the no of routines called by a class
Minimize indirect routine calls to other classes
In general minimize the extent to which a class collaborates
with other classes.
Constructors
Initialize all member data in constructors if possible
Enforce singleton property by using private constructor
Prefer deep copies to shallow copies until proven otherwise
Reasons to create a class
Model real world objects
Model abstract objects
Reduce complexity
Isolate complexity
Hide implementation details
Limit effect of changes
Hide global data
Streamline parameter passing
Make central points if control
Facilitate reusable code
Plan for family program
Package related operations
Accomplish specific refactoring