1. Chapters 4&5 Design Principles: Correctness, Robustness, Flexibility, Reusability, and Efficiency

2. Correctness and Sufficiency Goal: Goal: –That each artifact satisfies designated requirements, and that together they satisfy all of the application’s requirements. Approaches to correctness Approaches to correctness –Informal approaches –Formal approaches

3. Sufficient Designs A design sufficient to implement the requirements. a correct design Also called … the design must be entirely understandable It follows that … the design very modular A common way to achieve this is to make …

4. Formal approaches to correctness Invariants Invariants –Unchanging relationships among variables Class invariants Class invariants –Keep objects in correct states –Make attributes private so no one can change the state of an object directly. –Encapsulate private attributes with operations –Operations act as guards keep the object in a correct state –Operations throw exceptions when a request may put the object into a wrong state

5. Invariants for Class Automobile mileage > 0 mileage < 1000000 vehicleID has at least 8 characters value >= -300 ($300 is the disposal cost of a worthless automobile) originalPrice >= 0 ( type == “REGULAR” && value <= originalPrice ) || ( type == “VINTAGE” && value >= originalPrice )

6. Introducing Interfaces The interface of a module defines the uses of the module. The interface of a module defines the uses of the module. Interface to classes Interface to classes –It is often beneficial to group them into several interfaces when a class supports many methods –The interface segregation principle Interface to packages Interface to packages –Group the functions of the package into interfaces –Use a designated object to provide the interfaces

7. Interface to classes Shipment setVehicle() perishable() getWidth() printRoute() getType() getLength() getDuration() setType() Shipment Dimensions getWidth() getLength() getWeight() TranspMeans getDuration() setVehicle() printRoute() GoodsType getType() setType() perishable() Shipment Dimensions TranspMeans GoodsType Original form

8. Package interfaces Pricing purchases Furniture Clothing Appliance Selection ClothingTryout «singleton» PurchasesIF

9. Participant- services Conversation- services Example of package interfaces chatServer chatClient Display ConversationManager ClientComm ServerComm billing AccountingBill Financial Message- reception Conversation

10. Modularization: choosing classes Domain classes Domain classes –Particular to the application –Examples: BankCustomer, BankTransaction, Teller –Typically not GUI classes –Sufficient to classify all requirements Non-Domain classes: Non-Domain classes: –Generic to all software systems –Examples: abstract classes, utility classes –Arise from design and implementation considerations Select domain classes first and then add non- domain classes Select domain classes first and then add non- domain classes

11. Modularization: choosing packages An essential part of choosing an application’s architecture An essential part of choosing an application’s architecture Decompose the system into a set of three to ten packages Decompose the system into a set of three to ten packages

12. Modularization: choosing packages Mechanics Application tracking trajectory of rocket carrying orbit- bound satellite into position Position Ground control On board navig. Alternative 1 Control Trajectory Weather Alternative 2

13. Refactoring Refactoring: Change the design and implementation with changing the behavior Refactoring: Change the design and implementation with changing the behavior Philosophy of Extreme programming Philosophy of Extreme programming –Design only for the requirements given –Revise the design and implementation when more requirements are added Refactoring examples Refactoring examples –Promote a primitive attributes to class –Introducing abstract base classes or interface

14. Refactoring: promote attribute class Automobile { int mileage;// Promote it to a class …} class Mileage { int nominalMileage = 0; int chassisMileage = 0; int engineMileage = 0; … public int computerEffectiveMileage() { … } } class Automobile { Mileage mileage;// Promoted to a class …}

15. Refactoring: introducing abstracts Person SSN Name getSSN() getName() Faculty SSN Name getSSN() getName() office getOffice() Staff SSN Name getSSN() getName() dept getDept() Student SSN Name getSSN() getName() major getMajor()

16. Improving Robustness 1.Protection from faulty Input oUser input oInput, not from user Data communicationData communication Function calls made by other applicationsFunction calls made by other applications 2.Protection from developer error –Faulty design –Faulty implementation

17. Initializing variables & objects Desirable practice Desirable practice –Initialize all variables before using them –Initialized variables may offer more valuable info on debugging Initialize objects Initialize objects class Client { MyClass c = new MyClass(1, ‘a’); // take class default }Better class MyClass { static MyClass getInstance() { static MyClass getInstance() { return new MyClass(1, ‘a’); return new MyClass(1, ‘a’); }} Class Client { MyClass c = MyClass.getInstance(); …}

18. Constraints on Parameters 1 Example: int computeArea(int aLength, int aBreadth) { … }  Capture parameter constraints in classes if feasible int computeArea( RectangleDimension aRDimension )  Specify all parameter constraints in method comments aLength > 0 and aBreadth > 0 and aLength >= aBreadth

19. Constraints on Parameters 2  Callers obey explicit requirements on parameters oProblem is method programmers have no control over callers  Check constraints first within the method code if( aLength <= 0 ) …… –Throw exception if this is a predictable occurrence –Otherwise abort if possible –Otherwise return default if it makes sense in context And generate warning or log to a file And generate warning or log to a file

20. Wrapping Parameters in a class Replace int computeArea( int aLength, int aBreadth) {..} With int computeArea(Rectangle aRectangle) {..} where class Rectangle { … Rectangle( int aLength, int aBreadth ) { if( aLength > 0 ) this.length = aLength; else ….. } … } Rectangle class checks the parameters.

21. Flexibility  Aspects of flexibility  adding more of the same kind of functionality Example (banking application): handle more kinds of accounts without having to change the existing design or code Example (banking application): handle more kinds of accounts without having to change the existing design or code  adding different functionality Example: add withdraw function to existing deposit functionality Example: add withdraw function to existing deposit functionality  changing functionality Example: allow overdrafts Example: allow overdrafts

22. Flexibility: more of the same kind WebSite register() Member 0..nmembers class Website { Member[] members; void register(Member aMember) { … } …. } Make the design flexible enough to accept new kinds of members!  Next page

23. Flexibility: more of the same kind WebSite Member 0..n StandardMemberXMemberYMember members The open-close principle!

24. Flexibility: more of different func. A list of related functions – –Example: add print to an air travel itinerary functions – –Solution: add the new function to the existing set An existing base class – –Example: add “print road- and ship- to air itinerary ”  next page Neither – –Example: add “print itineraries for combinations of air, road and ship transportation” –Solution: design patterns

25. Flexibility: more of different func. Trip printItinerary() StandardTrip printItinerary() SomeApplicationClass Method(s) call printItinerary() Trip printItinerary() SeaTrip printItinerary() SomeApplicationClass LandTrip printItinerary() StandardTrip printItinerary() Print out the part common to all subclasses

26. Reusability Design reuse – –Design patterns – –Frameworks Implementation reuse – –Foundation classes (e.g., Java API) – –Library functions

27. Reusability – function reuse Specify completed or well document –Pre- and post-conditions, assumptions, etc Avoid unnecessary coupling with the enclosing class Avoid unnecessary coupling with the enclosing class –Make static if feasible –Include parameterization Use meaningful names Use meaningful names –Understandability promotes reusability Explain the algorithm Explain the algorithm –Reusers need to know how the algorithm works. If the algorithm comply with the government or company’s regulation. If the algorithm comply with the government or company’s regulation.

28. Reusability – class reuse Describe the class completely. Make the class name and functionality match a real world concept Make the class name and functionality match a real world concept Define a useful abstraction Define a useful abstraction Reduce dependencies on other classes Reduce dependencies on other classes –When class A depends on B, no use of A can be made without B. Thus it limits reuse of A. –Sometimes, certain dependencies may be acceptable in some applications A House may depend on an EntryDoor since every house has an entry door A House may depend on an EntryDoor since every house has an entry door A Piano may depend on PianoManufacture A Piano may depend on PianoManufacture

29. Reusability – class dependencies Customer Piano CustomerPianoPianoOrder Class Piano is dependent on class Customer. This limits the reusability of Piano. Why a piano warehouse application needs to know Customer? A possible solution is to separate the relationship between Customer and piano into a new class, PianoOrder. Now Customer and Piano Are independent of each other – both can be easily reused. The mediator design pattern!

30. Reusability – class combinations Customer computeBill() RegularCustomer computeBill() Leveraging inheritance: The base class Customer provides computeBill() for all subclasses. Subclass RegularCustomer may use super.computeBill(). Customer computeBill() class RegularCustomer extends Customer { public int computeBill() { int baseAmnt = super.computerBill(); // add specials to baseAmnt; return value; } abstract class Customer { public int computerBill() { // do required computation for // customers of all types return value; }

31. Reusability – class combinations Customer computeBill() Bill compute() Leveraging aggregation: Computation for bills is delegated to an aggregate class Bill Customer computeBill() class Bill { … public int compute() { // do computation return value; } class Customer { private Bill bill; public int computerBill() { int value = this.bill.compute(); return value; }

32. Reusability – class combinations Customer computeBill( Orders ) Orders value() Leveraging dependency: Customer has a method computerBills() which takes a parameter of Orders. Customer computeBill() class Orders { … public int computeValue() { // do computation return value; } class Customer { public int computerBills(Orders someOrders) { int value = someOrders.computeValue(); return total; }

33. Efficiency - time  Design for Other Criteria, Then Consider Efficiency –Design for flexibility, reusability, … –At some point, identify inefficient places –Make targeted changes to improve efficiency  Design for Efficiency From the Start –Identify key efficiency requirements up front –Design for these requirements during all phases  Combine These Two Approaches –Make trade-offs for efficiency requirements during design –Address remaining efficiency issues after initial design

34. Efficiency - Space-Time Trade-offs Time to process one item Typical target Space

35. Summary of Chapter 4  Correctness of a Design or Code –Supports the requirements –In general, many correct designs exist  Robustness of a Design or Code –Absorbs errors –-- of the user –-- of developers

36. Summary of Chapter 5  Flexibility –readily changeable  Reusability –in other applications  Efficiency –in time –in space