Evaluating a Class Design Evaluating Class Design 1

  • Slides: 9
Download presentation
Evaluating a Class Design Evaluating Class Design 1 Evaluation is needed to accept, revise

Evaluating a Class Design Evaluating Class Design 1 Evaluation is needed to accept, revise or reject a class design. Five aspects to be evaluated: – – – Abstraction: Responsibilities: Interface: Usage: Implementation: Computer Science Dept Va Tech January 2002 does it provide a useful one? are they reasonable for the type? is it clean, simple? do we provide the “right” set of methods? reasonable? OO Software Design and Construction © 2002 Mc. Quain WD & Keller BJ

Tests for Adequacy of Abstraction Evaluating Class Design 2 Identity: Are class purpose and

Tests for Adequacy of Abstraction Evaluating Class Design 2 Identity: Are class purpose and method purposes well-defined and connected? Clarity: Can purpose of class be given in brief, dictionary-style definition? Uniformity: Do operations have uniform level of abstraction? Computer Science Dept Va Tech January 2002 OO Software Design and Construction © 2002 Mc. Quain WD & Keller BJ

Good or Bad Abstractions? Evaluating Class Design 3 class Date: Date represents a specific

Good or Bad Abstractions? Evaluating Class Design 3 class Date: Date represents a specific instant in time, with millisecond precision. class Time. Zone: Time. Zone represents a time zone offset, and also figures out daylight savings. Computer Science Dept Va Tech January 2002 OO Software Design and Construction © 2002 Mc. Quain WD & Keller BJ

Tests for Adequacy of Responsibilities Evaluating Class Design 4 Clear: Does class have specific

Tests for Adequacy of Responsibilities Evaluating Class Design 4 Clear: Does class have specific responsibilities? Limited: Do responsibilities fit the abstraction (no more/less)? Coherent: Do responsibilities make sense as a whole? class Complex { Complete: Does class completely capture the abstraction? private: double Real, Imag; public: Complex(double R = 0. 0, double I = 0. 0); double get. Real() const; double get. Imag() const; void set. Real(); void set. Imag(); double Magnitude() const; }; Computer Science Dept Va Tech January 2002 OO Software Design and Construction © 2002 Mc. Quain WD & Keller BJ

Tests for Adequacy of Interface Evaluating Class Design 5 Naming: Do names clearly express

Tests for Adequacy of Interface Evaluating Class Design 5 Naming: Do names clearly express the intended effect? Symmetry: Are names and effects of pairs of inverse operations clear? Flexibility: Are methods adequately overloaded? Convenience: Are default values used when possible? Computer Science Dept Va Tech January 2002 OO Software Design and Construction © 2002 Mc. Quain WD & Keller BJ

Example of Poor Naming Evaluating Class Design 6 class Item. List { private: //.

Example of Poor Naming Evaluating Class Design 6 class Item. List { private: //. . . public: void Delete(Item item); // Take Item’s node out of list and delete Item void Remove(Item item); // Take Item’s node out of the list but do not // delete Item void Erase(Item item); // Keep Item’s node in List, but with no information }; Computer Science Dept Va Tech January 2002 OO Software Design and Construction © 2002 Mc. Quain WD & Keller BJ

Tests for Adequacy of Usage Evaluating Class Design 7 Examine how objects of the

Tests for Adequacy of Usage Evaluating Class Design 7 Examine how objects of the class are used in different contexts (see below…) Incorporate all operations that may be useful in these contexts… up to a point… class Location { private: int x. Coord, y. Coord; //coordinates public: Location(int x = 0, int y = 0); int x. Coord(); //return x. Coord value int y. Coord(); //return y. Coord value }; // usage: Location point(100, 100); // shift point: point = Location( point. x. Coord()+5, point. y. Coord()+10 ); Computer Science Dept Va Tech January 2002 OO Software Design and Construction © 2002 Mc. Quain WD & Keller BJ

Revised Location Class Evaluating Class Design 8 class Location { private: int x. Coord,

Revised Location Class Evaluating Class Design 8 class Location { private: int x. Coord, y. Coord; //coordinates public: Location(int x = 0, int y = 0); int XCoord(); //return x. Coord value int YCoord(); //return y. Coord value void Shift. By(int dx, int dy); // shift by relative coordinates }; // Revised usage: Location point(100, 100); point. Shift. By(5, 10); Computer Science Dept Va Tech January 2002 // shift point OO Software Design and Construction © 2002 Mc. Quain WD & Keller BJ

Implementation Evaluating Class Design 9 Least important, mostly easily changed aspect to be evaluated.

Implementation Evaluating Class Design 9 Least important, mostly easily changed aspect to be evaluated. – – – poorly engineered designs lead to problematic implementations massaging a problematic implementation (without redesign) rarely produces any effective improvement it’s only code… the issues here are primarily language syntax and semantics Overly complex implementation may mean: – – class is not well conceived class has been given too much responsibility Computer Science Dept Va Tech January 2002 OO Software Design and Construction © 2002 Mc. Quain WD & Keller BJ

Class class Class for Name Class Class classClass class Class for Name Class Class class
Evaluating Notes for Evaluating Learning Objectives 1 EvaluatingEvaluating Notes for Evaluating Learning Objectives 1 Evaluating
Evaluating Functions Evaluating Functions Evaluating functions is justEvaluating Functions Evaluating Functions Evaluating functions is just
evaluating your design When designing our evaluating refiningevaluating your design When designing our evaluating refining
maths class Chinese class music class English classmaths class Chinese class music class English class
Class 1 Class 2 Class 3 Class 4Class 1 Class 2 Class 3 Class 4
Class limit Class Boundaries Class Mark Class LimitClass limit Class Boundaries Class Mark Class Limit
basis class derived class Basis class Parent classbasis class derived class Basis class Parent class