星期六, 十月 07, 2006

Design Principles : The Open-Closed Principle

OCP - The Open-Closed Principle

Software entities (classes , modules , functions , etc. ) should be open for extension , but closed for modification.

Abstraction is the key

Related design pattern
  • Strategry pattern
  • Template method

Design Principles : Single-Responsiblity Principle

SRP - Single-Responsibility Principle

A class should have only one reason to change.

Why?

If class have more than one reason , then there will be more than one reason to change.

An axis of change is an axis of change only if the changes actually occur. It is not wise to apply the SRP , or any other principle for that matter , if there is no symptom.

Agile Design

Symptoms of poor design
  • Rigidity
  • Fragility
  • Immobility
  • Viscosity
  • Needless Complexity
  • Needless Repetition
  • Opacity
Principles
  • SRP
  • OCP
  • LSP
  • DIP
  • ISP
What's agile design?
  • Always multiply your estimates by three
  • Requirements always change
  • Writing software would be a lot easier if it weren't for customers
Since the requirements will always change, it is necessary to do some extra work before implementation , so this will leave space when you later add more function by , for this part you can also follow OCP prinicple.

Design Principles : The Interface Segregation Principle

ISP - The Interface Segregation Principle

Clients should not be fored to depend upon interfaces that they do not use.

Use : Adapter pattern

Design Principles : Liskov Substitution Principle

LSP - Liskov Substitution Principle

What is wanted here is something like the following substitution property : If for
each object o1 of type S there is an object o2 of type T such that for all programs
P defined in terms of T the behavior of P is unchanged when o1 is substituted for o2
then S is a subtype of T.

RTTI usage
Design by contract

Design Principles : The Dependency Inversion Principle

DIP - The Dependency Inversion Principle

A. High Level Modules should not depend upon low level modules. Both should defend upon
abstractions.
B. Abstractions should not depend upon details. Details should depend upon abstraction.

Use : Strategy Pattern

Bug fixing steps

From Header First Design Pattern.

1. The user experiences a problem and determines that it is a software problem.
2. The user reports the problem to a software specialist.
3. The software specialist verifies that there is a software problem.
4. The specialist reports the source of the problem to a developer.
5. The developer determines what is wrong with the product.
6. The developer fixes the product.
7. A development group inspects the fix to ensure that it is correct.
8. A test group tests the fix to ensure that it fixes the problem.
9. The test group tests the fix to ensure that it doesn't cause other problems.
10. The developers change the documentation to reflect the fix.
11. The release group rebuilds the product with the fix included.
12. The release group distributes the rebuilt product to the users.
13. The user installs the rebuilt product.
14. The user confirms that the fix actually corrected the problem.

Welcome!

Welcome to my research lab. :-)
Here I will share my experience on technical stuff.