Chapters 45 Design Principles Correctness Robustness Flexibility Reusability

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

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

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

Formal approaches to correctness n Invariants n Class invariants – Unchanging relationships among variables – 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

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

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

Interface to classes Original form Shipment set. Vehicle() perishable() get. Width() print. Route() get. Type() get. Length() get. Duration() set. Type() Dimensions get. Width() get. Length() get. Weight() Transp. Means Goods. Type get. Duration() get. Type() set. Vehicle() set. Type() print. Route() perishable() Shipment Dimensions Shipment Transp. Means Goods. Type

Package interfaces purchases Pricing Furniture Clothing Appliance «singleton» Purchases. IF Selection Clothing. Tryout

Example of package interfaces chat. Server Conversation Financial billing Accounting Conversationservices chat. Client Conversation. Manager Server. Comm Bill Participantservices Messagereception Display Client. Comm

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

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

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

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

Refactoring: promote attribute class Automobile { int mileage; … } // Promote it to a class Mileage { int nominal. Mileage = 0; int chassis. Mileage = 0; int engine. Mileage = 0; … public int computer. Effective. Mileage() { … } } class Automobile { Mileage mileage; // Promoted to a class … }

Refactoring: introducing abstracts Person SSN Name get. SSN() get. Name() Faculty SSN Name get. SSN() get. Name() office get. Office() Staff SSN Name get. SSN() get. Name() dept get. Dept() Student SSN Name get. SSN() get. Name() major get. Major()

Improving Robustness 1. Protection from faulty Input o User input o Input, not from user • • Data communication Function calls made by other applications 2. Protection from developer error – Faulty design – Faulty implementation

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

Constraints on Parameters 1 Example: int compute. Area(int a. Length, int a. Breadth) { … } q Capture parameter constraints in classes if feasible int compute. Area( Rectangle. Dimension a. RDimension ) q Specify all parameter constraints in method comments a. Length > 0 and a. Breadth > 0 and a. Length >= a. Breadth

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

Wrapping Parameters in a class Replace int compute. Area( int a. Length, int a. Breadth) {. . } With int compute. Area(Rectangle a. Rectangle) {. . } where class Rectangle { … } … Rectangle( int a. Length, int a. Breadth ) { if( a. Length > 0 ) this. length = a. Length; else …. . } Rectangle class checks the parameters.

Flexibility q Aspects of flexibility qadding more of the same kind of functionality n Example (banking application): handle more kinds of accounts without having to change the existing design or code qadding different functionality n Example: add withdraw function to existing deposit functionality qchanging functionality n Example: allow overdrafts

Flexibility: more of the same kind class Website { Member[] members; void register(Member a. Member) { … } …. } Web. Site register() members 0. . n Member Make the design flexible enough to accept new kinds of members! Next page

Flexibility: more of the same kind Web. Site members YMember XMember 0. . n Member Standard. Member The open-close principle!

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

Flexibility: more of different func. Trip print. Itinerary() Some. Application. Class Method(s) call print. Itinerary() Standard. Trip print. Itinerary() Some. Application. Class Standard. Trip print. Itinerary() Land. Trip print. Itinerary() Print out the part common to all subclasses Sea. Trip print. Itinerary()

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

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

Reusability – class reuse n n Describe the class completely. Make the class name and functionality match a real world concept Define a useful abstraction 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 n n A House may depend on an Entry. Door since every house has an entry door A Piano may depend on Piano. Manufacture

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

Reusability – class combinations Customer compute. Bill() Regular. Customer compute. Bill() Leveraging inheritance: The base class Customer provides compute. Bill() for all subclasse Subclass Regular. Customer may use super. compute. Bill(). abstract class Customer { class Regular. Customer extends public int computer. Bill() { Customer { // do required computation forpublic int compute. Bill() { // customers of all types int base. Amnt = return value; super. computer. Bill(); } // add specials to base. Amnt; } return value; }

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

Reusability – class combinations Customer compute. Bill() Customer compute. Bill( Orders ) Orders value() Leveraging dependency: Customer has a method computer. Bills() which takes a parameter of class Customer { class Orders { public int computer. Bills(Orders some. Orders) …{ int value = some. Orders. compute. Value(); public int compute. Value() { return total; // do computation } return value; } }

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

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

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

Summary of Chapter 5 q Flexibility – readily changeable q Reusability – in other applications q Efficiency – in time – in space