Software Engineering

Class design Software Engineering

Class design – ADT Abstract Data Types: Why use ADT? Hidden implementation details Changes do not affect whole program More informative interfaces Easier to improve performance Programs easier to verify “Self-documenting” programs “Higher level programming”

Class design – ADT Abstract Data Types: ADT = abstract (mathematical) model + operations defined on it Class = ADT + inheritance + polymorphism

Class design – interfaces Abstraction Encapsulation

Class design – interfaces Abstraction: Example of good abstraction (C++): class Student {public: Student(); Student( FullName name, String address, String studentID ); virtual ~Student(); FullName GetName() const; String GetAddress() const; String GetStudentID() const; ...private: ...};

Class design – interfaces Abstraction: Example of bad abstraction (C++): class StudentList: public ListContainer {public: ... void AddStudent(Student student); void RemoveStudent(Student student); ... Student NextListItem(); Student FirstItem(); Student LastItem(); ...private: ...}; Different levels of abstraction

Class design – interfaces Abstraction: guidelines to build good interfaces Present a consistent level of abstraction in the class interface – each class should implement one and only one ADTHeuristic test for inheritance relations: is inheritance being used only for “is a” relationships? (Answer should be YES)

Class design – interfaces Abstraction: guidelines to build good interfaces Be sure you understand what abstraction the class is implementing

Class design – interfaces Abstraction: guidelines to build good interfaces Provide services in pairs with their opposites – add/remove, activate/deactivate, on/off, ...

Class design – interfaces Abstraction: guidelines to build good interfaces Move unrelated information to separate classes – if you have “isolated” data and routines within a class, they should form a separate class

Class design – interfaces Abstraction: guidelines to build good interfaces Make interfaces programmatic rather than semantic whenever possibleprogrammatic = compiler can checksemantic = e.g. “RoutineA must be called before RoutineB”

Class design – interfaces Abstraction: guidelines to build good interfaces Beware of “erosion” of the interface´s abstraction under modification

Class design – interfaces Abstraction: guidelines to build good interfaces Do not add public members that are inconsistent with the interface abstraction

Class design – interfaces Abstraction: guidelines to build good interfaces Abstraction and cohesion come together and are strongly correlated

Class design – interfaces Encapsulation: guidelines to build good interfaces Minimise accessibility of classes and members - “private” is better than “protected”, and both are better than “public”goal is to preserve the integrity of the interface abstraction

Class design – interfaces Encapsulation: guidelines to build good interfaces Do not expose member data in public float x;float y;float z; Bad design: data (and their representation) are exposed to external manipulation float GetX();float GetY();float GetZ();void SetX(float x);void SetY(float y);void SetZ(float z); Good design: internal data (and how they are represented, and where they are stored, etc.) are protected from external manipulation

Class design – interfaces Encapsulation: guidelines to build good interfaces Avoid putting private implementation details into a class interface

Class design – interfaces Encapsulation: guidelines to build good interfaces Do not make ANY assumption about the class users

Class design – interfaces Encapsulation: guidelines to build good interfaces Avoid “friend classes”

Class design – interfaces Encapsulation: guidelines to build good interfaces Do not put a routine into the public interface just because it uses only public routines

Class design – interfaces Encapsulation: guidelines to build good interfaces Give priority to read-time convenience over write-time convenience – code is read much more than written. When writing code, make it good to be read, even if it demands more work to be written

Class design – interfaces Encapsulation: guidelines to build good interfaces Beware of semantic violations of encapsulationSome examples of semantic violations of encapsulation: Not calling Initialise(), because Operation() calls it Not calling Terminate(), because LastOperation() calls it Not calling Database.Connect(), because Retrieve() calls it Using MAX_ROWS instead of MAX_COLUMNS because you know that every table has same number of rows and columns

Class design – interfaces Encapsulation: guidelines to build good interfaces Beware of tight coupling

Class design & implementation Containment (“has a”): “has a” should be always implemented through containment Sometimes, it may be necessary to implement “has a” through private inheritance. This should be considered bad practice, as it leads to tight coupling and violates encapsulation

Class design & implementation Containment (“has a”): Be critical of classes that contain more than about seven data members SEVEN = heuristic magic number

Class design & implementation Inheritance (“is a”):general considerations For each member routine, will the routine be visible to derived classes? Will it have a default implementation? Will the default implementation be overridable? For each data member, will the data member be visible to derived classes?

Class design & implementation Inheritance (“is a”):general considerations Implement “is a” through public inheritanceBe, however, rigorous about implementing through public inheritance strictly “is a” relationships

Class design & implementation Inheritance (“is a”):general considerations Design and document for inheritance, or prohibit itC++: non-virtualJava: finaletc.

Class design & implementation Inheritance (“is a”):general considerations Liskov substitution principle: all the routines defined in the base class should mean the same thing when they are used in each of the derived classes

Class design & implementation Inheritance (“is a”):general considerations Do not reuse names of non-overridable base-class routines in derived classes

Class design & implementation Inheritance (“is a”):general considerations Move common interfaces, data and behaviour as high as possible in the inheritance tree

Class design & implementation Inheritance (“is a”):general considerations Be suspicious of classes of which there is only one instance: should it be an object instead of a class?

Class design & implementation Inheritance (“is a”):general considerations Be suspicious of classes of which there is only one derived class

Class design & implementation Inheritance (“is a”):general considerations Be suspicious of classes that override a routine and do nothing inside the derived routine operation() ... operation() // empty body operation() ...

Class design & implementation Inheritance (“is a”):general considerations Avoid deep inheritance trees – usually, more than three levels of inheritance suggest overly complex design

Class design & implementation Inheritance (“is a”):general considerations Prefer polymorphism to extensive type checking Make all data private, not protected

Class design & implementation Inheritance (“is a”):general considerations Multiple inheritance can be powerful, but it also can make the program too complex. If possible, avoid it Inheritance (in general) is very powerful, but should always be used with care, so as not to increase program complexity unnecessarily

Class design & implementation Member functions and data: Keep the number of routines in a class as small as possible Disallow implicitly generated member functions and operators you do not want Minimise the number of different routines called by a class Minimise indirect routine calls to other classes – such as rout1.Rout2().Rout3().Rout4()

Class design & implementation Member functions and data: In general, minimise the extent to which a class collaborates with other classes – try to minimise: Number of kinds of objects instantiated Number of different direct routine calls on instantiated objects Number of routine calls on objects returned by other instantiated objects

Why classes? Model real-world objects Model abstractions of real-world objects Reduce program complexity Isolate complexities Hide implementation details Limit effects of change

Why classes? (cont.) • Streamline parameter passing • Facilitate reusable code • Plan for a family of programs • Package related operations

Software Engineering