7.Object-OrientedDesignPrinciples分析.ppt

Venkat Subramaniam July-August 1998 Object-Oriented Programming in Java Halliburton Developers Training Program Venkat Subramaniam, Software Engr. Trainer 7. Object-Oriented Design Principles The Pillars of the Paradigm Abstraction Encapsulation Hierarchy Association, Aggregation Inheritance Polymorphism What’s OO? Is it using Objects? Is it using C++, Java, C#, Smalltalk? No, its got to be using UML?! ? What makes a program OO? How do you measure good design? Measuring Quality of an Abstraction Designing Classes Objects An incremental, iterative process Difficult to design right the first time Metrics for class design Coupling inheritance Vs. coupling Strong coupling complicates a system design for weakest possible coupling Cohesion degree of connectivity among the elements of a single module/class coincidental cohesion: all elements related undesirable Functional cohesion: work together to provide well-bounded behavior Law of Demeter “Methods of a class should not depend in any way on the structure of any class, except the immediate structure of their own class. Further, each method should send messages to objects belonging to a very limited set of classes only.” Bad design Perils of a bad design Rigidity Hard to change, results in cascade of changes Fragility Breaks easily and often Immobility Hard to reuse (due to coupling) Viscosity Easy to do wrong things, hard to do right things Needless Complexity Complicated class design, overly generalized Needless Repetition Copy and Paste away Opacity Hard to understand Principles Guiding Principles that help develop better systems Use principles only where they apply You must see the symptoms to apply them If you apply arbitrarily, the code ends up with Needless Complexity DRY Don’t Repeat Yourself “Every Piece of Knowledge must have a single, unambiguous, authoritative representation within a system” One of the most difficult, but most seen H