Object Design Basics Spring/2002 Distributed Software Engineering C: unocourses4350slidesDefining. Threads 1
Java’s constructs for Objects • • • Interfaces Abstract classes Classes Subclasses Inner classes Anonymous classes Spring/2002 Distributed Software Engineering C: unocourses4350slidesDefining. Threads 2
Nested classes • • Static member classes. Non-static member classes. Anonymous classes. Local classes. Spring/2002 Distributed Software Engineering C: unocourses4350slidesDefining. Threads Inner classes 3
Which member class to use • If a nested class needs to be visible outside of a single method, or its too long inside of the method, use a private member class. • If each instance of the member class needs a reference to its enclosing instance, make it private non-static class. • Otherwise make it static. • Use anonymous classes for those one-time-use classes. Spring/2002 Distributed Software Engineering C: unocourses4350slidesDefining. Threads 4
Exceptions • Built-in • User defined • Use of finally clause Spring/2002 Distributed Software Engineering C: unocourses4350slidesDefining. Threads 5
![try { int i = 0; while(true) { a[i++]. f(); } } catch(Array. Index.](https://present5.com/presentation/97c0d54275d16a86ba0e3b4d773f77bb/image-6.jpg "try { int i = 0; while(true) { a[i++]. f(); } } catch(Array. Index.")
try { int i = 0; while(true) { a[i++]. f(); } } catch(Array. Index. Out. Of. Bounds. Exception e){ } Use exceptions only for exceptional conditions!!! Do not use them for control flow of normal situations. Spring/2002 Distributed Software Engineering C: unocourses4350slidesDefining. Threads 6
finally try{ … } catch( …. ) { … } … finally { …. } Spring/2002 Distributed Software Engineering C: unocourses4350slidesDefining. Threads 7
finally • Code in finally is executes after try terminates either normally, abnormally or via return or break. • Commonly use to release resources held by the object, I. e. to tell the garbage collector about an unused object. • But: there is no guarantee that those statements will get executed promptly. • So: – Nothing time critical should be done in them. – Never depend on a finalizer to update critical persistent state. – Even better: Do not rely on finally clause. Spring/2002 Distributed Software Engineering C: unocourses4350slidesDefining. Threads 8
finally • What to do: – Provide an explicit termination method and require clients to invoke it when needed resources are not longer needed. – This method records that object is no longer valid, so if any other method in the instance gets invoked an Illegal. State. Exception should be thrown. – The method will invocation be the only line in the body of finally. • It may be invoke later, rather than never at all. Spring/2002 Distributed Software Engineering C: unocourses4350slidesDefining. Threads 9
Exception use • Use checked exceptions for conditions for which the caller can reasonably be expected to recover. • An API with a checked exception is telling the user that user is expected to recover from the condition that throws the exception. User can disregard it, but it is a poor tactic. Spring/2002 Distributed Software Engineering C: unocourses4350slidesDefining. Threads 10
Exception use • Use run-time exceptions to indicate programming errors. • User is not expected to recover from these. • The largest percentage of these errors are pre-condition violations. • Runtime exceptions are expected to appear and be resolved during program development. Spring/2002 Distributed Software Engineering C: unocourses4350slidesDefining. Threads 11
Exception use • Favor use of standard Java exceptions – – – – Illegal. Argument. Exception Illegal. State. Exception Null. Pointer. Exception Index. Out. Of. Bounds. Exception Concurrent. Modification. Exception Unsupported. Operation. Exception Arithmetic. Exception Numer. Format. Exception Spring/2002 Distributed Software Engineering C: unocourses4350slidesDefining. Threads 12
Exception use • Avoid confusion by allowing an exception to be passed on to higher levels, where the exception might not make reasonable sense • An abstraction should catch a low-level exception and in its place throw an exception that is explainable in terms of the abstraction. • Example: the add method to a bounded queue implemented using an array, can throw an Index. Out. Of. Bounds. Exception. This does not make much sense for the client of the queue, as he is not expected to know the implementation choice in general. So the add method should catch the exception and throw it as Full. Queue. Exception. Spring/2002 Distributed Software Engineering C: unocourses4350slidesDefining. Threads 13
Documenting exception • Always declare checked exceptions individually, and document precisely the conditions under which each one is thrown using the Javadoc @throws tag. • Document as well those exceptions which are Run. Time. Exceptions. Spring/2002 Distributed Software Engineering C: unocourses4350slidesDefining. Threads 14
Exceptions are objects! • Any checked exception should contain all the data, along with its queries, that caused the exception. • Since we expect the caller to possibly recover from it, having that information will help the course of action to take. Spring/2002 Distributed Software Engineering C: unocourses4350slidesDefining. Threads 15
Exception’s string message • All Runtime. Exceptions are expected to produce a system crash which will produce the exception string that caused the crash. • Make sure that strings contains all the information needed to be able to understand what happens of what was possibly expected. • Simple example: an Index. Out. Of. Bounds. Exception should produce a message that states the lower bound, the upper bound of the array, along with the index value that caused the exception. Spring/2002 Distributed Software Engineering C: unocourses4350slidesDefining. Threads 16
Strive for failure atomicity • Generally speaking: a failed method should strive to leave the object in the original state prior to invocation. • From the point of view of the client: a method get all done, or nothing gets done! Spring/2002 Distributed Software Engineering C: unocourses4350slidesDefining. Threads 17
How to accomplish failure atomicity: making the object remain consistent. • Get if for free if your object is immutable. • For mutable objects: – Check conditions (parameters) before making changes. – Order algorithm so that the part that may fail occurs before the part that make changes. – Use temporary objects to perform the algorithm, and replace the object’s state if successfully accomplished. – Write recovery code in the catch clause. • All these solutions work in a singly-threaded method. In a multi-threaded application all bets are off, and need to recourse to other ways to handle object’s consistency. Spring/2002 Distributed Software Engineering C: unocourses4350slidesDefining. Threads 18
Beware • Do not ignore exception handling! • Exception handling with blank braces should raise flags. • An ignore exception can later cause another exception in an unrelated piece of code! • There are cases where you may ignore an exception, write a comment for the reason why is safe to ignore it! Spring/2002 Distributed Software Engineering C: unocourses4350slidesDefining. Threads 19
Java support for encapsulation • Field modifiers: – public – private – protected – none Spring/2002 Distributed Software Engineering C: unocourses4350slidesDefining. Threads 20
Static uses in Java 1. 2. To define constants. To define methods 1. These methods are called class methods, because they are independent of any of the instances of a class. 2. Instance methods rely on the state of the object, while class methods must be independent of them. 3. Using inheritance, static methods cannot be overwritten, they can only be overloaded. A typical programmer’s error is to overwrite a static method in a subclass, but in reality is only being overloaded. 4. Thus, polymorphism does not work with static methods. Spring/2002 Distributed Software Engineering C: unocourses4350slidesDefining. Threads 21
Static uses in Java 1. Static method invocation is qualified not with an object reference, but with the actual class name. 2. The variables manipulated in a static method must be local variables or static variables. Spring/2002 Distributed Software Engineering C: unocourses4350slidesDefining. Threads 22
Best programming practices • USE DESIGN BY CONTRACT. – Identify class invariants and make sure all methods maintain them. – Method specification includes require and ensure clauses as doc comments. • Develop a test plan as part of analysis/design phase. • Test each class independently from the system you are developing. • Even better, use JUnit to make testing automated while supporting iterative design. Spring/2002 Distributed Software Engineering C: unocourses4350slidesDefining. Threads 23
Best programming practices • When writing code, get used to re-read your code carefully to uncover commonly made design flaws: – Repetitive code – Large methods – Lack of use of polymorphism – Large objects – …. Etc • This activity goes by the name of refactoring • Successful refactoring needs to be supported by automated testing. Changing code without testing it is asking for big trouble down the line. Spring/2002 Distributed Software Engineering C: unocourses4350slidesDefining. Threads 24
Fundamental System Decomposition: MVC • Any system written using object must exhibit the following decomposition: – Model: the set of classes which solve problem. These component is independent of the interface being uses by the system. – UI: the set of classes to provide an interface to the model. – Data: the set of classes that provide data to the UI or the Model. Spring/2002 Distributed Software Engineering C: unocourses4350slidesDefining. Threads 25
Static diagram for fundamental decomposition presents consumes Data Model UI consumes Spring/2002 Distributed Software Engineering C: unocourses4350slidesDefining. Threads 26
Fundamental Software Development Principles • Cohesion: A module should model one well defined concept; its functionality must only deal with supporting the concept being modeled. • Coupling : a module’s collaborators should be small in number and it should interact through a well defined interface. Spring/2002 Distributed Software Engineering C: unocourses4350slidesDefining. Threads 27
Tools for Design: Inheritance and Composition • Inheritance – strong coupling between components – allows modification of components being reused – Making a new class involves programming – static relationship • Composition – powerful reuse technique, difficult to understand by examining static program text. – Composition’s core class can be changed at run-time Spring/2002 Distributed Software Engineering C: unocourses4350slidesDefining. Threads 28
Delegation • Composed object uses its components to implement its interface. Usually a composed object receives a messages which it forwards to one of its components for execution. This is called delegation. Spring/2002 Distributed Software Engineering C: unocourses4350slidesDefining. Threads 29
Uses of inheritance • Identifying common functionality among a collection of classes • providing an implementation of a method in an abstract class • providing an alternative implementation • refining the implementation of a method • extending functionality of an existing class Spring/2002 Distributed Software Engineering C: unocourses4350slidesDefining. Threads 30
Concrete classes, abstract classes, interfaces • When should we subclass, when should we compose? • When to use an abstract class, when to use an interface? Spring/2002 Distributed Software Engineering C: unocourses4350slidesDefining. Threads 31
Abstract classes • To model a generalized object • Specification of an abstract class ought to be stable • Should factor out common implementation details of its subclasses • Mechanism used to exploit polymorphism • Abstract classes can be extended without breaking running code. Spring/2002 Distributed Software Engineering C: unocourses4350slidesDefining. Threads 32
Interfaces • Model to generalize functionality • they are by definition abstract, no aspects of its implementation is fixed. • A way to multiple inheritance: A class can implement one or more interfaces • Allows for a more generalized used of polymorphism • Interfaces cannot be modified • They are the key to pluggability Spring/2002 Distributed Software Engineering C: unocourses4350slidesDefining. Threads 33
Interfaces and the software life-cycle • Design: serve as a stabilizing element in the specification and implementation of classes • Implementation: compiler checks that class implementing interface fullfills contract • Integration: well-established interfaces are glue for composed classes and subsystems • Testing: logical errors are limited to a subset of methods Spring/2002 Distributed Software Engineering C: unocourses4350slidesDefining. Threads 34
Inheritance and composition • Advantages of inheritance: – code reuse – polymorphism – extension of an existing class • dis-advantages of inheritance – superclass and subclass are strongly coupled; changes to superclass affect suclass, and subclass cannot change specification of superclass methods – It’s a static feature Spring/2002 Distributed Software Engineering C: unocourses4350slidesDefining. Threads 35
• Advantages of composition – code reuse as black box reuse – can change composed object’s core class at runtime; ie, it’s a dynamic property of object – Supports stronger encapsulation than inheritance. Changes to core class does not affect specification of composed class. And vice-versa, changes to composed class do not affect core class. Spring/2002 Distributed Software Engineering C: unocourses4350slidesDefining. Threads 36
• Dis-advantages of composition – lose polymorphism. !!! – Can gain it back: compose with interfaces and have core classes implement those interfaces Spring/2002 Distributed Software Engineering C: unocourses4350slidesDefining. Threads 37
Mis-uses of inheritance • To model roles • To provide implementation alternatives to a given abstraction • To model option features of an object • Consequences: – class explosion Spring/2002 Distributed Software Engineering C: unocourses4350slidesDefining. Threads 38
• Favor composition over inheritance • Inheritance should not be used just for code reuse or to take advantage of polymorphism • It is harder to maintain inheritance based code than composition based code. • Use inheritance – when the complete interface of the superclass applies to the subclass candidate – there is a permanent is-a relationship – superclass is stable. – For specialization Spring/2002 Distributed Software Engineering C: unocourses4350slidesDefining. Threads 39
• Composition can be used – some features of core class are irrelevant, ie, new class is not a true functional subtype – to provide implementation to some specific functionality. – high proportion of code of base class need to be rewritten – Use composition to extend functionality by delegating to more appropriate objects. • Interfaces can be used – to maintain separation of between specification and implementation – to provide reuse and polymorphism across hierarquies Spring/2002 Distributed Software Engineering C: unocourses4350slidesDefining. Threads 40
Accommodating update of object’s class • Example: modeling with inheritance Worker Sales. W Hourly. W Fixed. W • “transmute” problem: via copying & delete • With composition: use “simple” assignment to component being updated. Spring/2002 Distributed Software Engineering C: unocourses4350slidesDefining. Threads 41
Example • Need to model student • Later on need to model PT, FT student (beware not to model attributes with classes) Student PT Spring/2002 FT Distributed Software Engineering C: unocourses4350slidesDefining. Threads 42
• Later own, need to consider graduate student Student PT Grad FT PTGrad Spring/2002 Distributed Software Engineering C: unocourses4350slidesDefining. Threads FTGrad 43
Later on. . . Add student worker Student PT Grad FT PTGrad FTGrad AGGGGHHHHHHHHH!! Spring/2002 Distributed Software Engineering C: unocourses4350slidesDefining. Threads 44
Alternative • Define : Student with subclasses undergrad, Grad. Student • Define: Status with subclasses PT, FT • Define: Worker with subclasses FTW, PTW • Now based on student we compose to get – a student who is part-time and ft worker – a grad student full time and part time worker Spring/2002 Distributed Software Engineering C: unocourses4350slidesDefining. Threads 45
Example: Account class • Designed to include – customer information: • name • address • account identification number • Design not cohesive: two abstractions – customer information – account Spring/2002 Distributed Software Engineering C: unocourses4350slidesDefining. Threads 46
Cohesion • Limitations introduced due to the one-to-one correspondence of the two abstractions – one customer with several accounts – join accounts Spring/2002 Distributed Software Engineering C: unocourses4350slidesDefining. Threads 47
Class specialization Account Cash Acc Porfolio Ac Individual Institution Composing on the two dimensions: class explosion. One possible solution: multiple inheritance. More trouble that what solves. Problem: inheritance diamond. Spring/2002 Distributed Software Engineering C: unocourses4350slidesDefining. Threads 48
Account Cash Acc Spring/2002 1. . * owner * Porfolio Ac Individual Distributed Software Engineering C: unocourses4350slidesDefining. Threads Customer Institutional 49
Inheritance vs composition • Examples: – Sensor, remote Sensor – Subclasses of Thread, not a good choice – Subclasses of Observable Spring/2002 Distributed Software Engineering C: unocourses4350slidesDefining. Threads 50
Rules to achieve cohesion • An attribute should have a single value and not have structure (repeating groups) – Account with many different currencies – balance has as value list of <currency, balance> • An attribute should describe an instance of its containing class – customer name, address, etc do not describe an Account instance Spring/2002 Distributed Software Engineering C: unocourses4350slidesDefining. Threads 51
An example • Design a Button class to control a lightbulb • software to reside on table lamp • Somehow fact that user has pressed button is communicated to software Spring/2002 Distributed Software Engineering C: unocourses4350slidesDefining. Threads 52
First solution contains Button Not reusable Spring/2002 Light. Bulb Reusable Distributed Software Engineering C: unocourses4350slidesDefining. Threads 53
Second solution Button Light. Bulb. Button Pump. Button contains Light. Bulb Spring/2002 Distributed Software Engineering C: unocourses4350slidesDefining. Threads 54
Third solution contains Button. Server Light. Bulb Reusable Spring/2002 Not so Reusable Distributed Software Engineering C: unocourses4350slidesDefining. Threads 55
Forth solution contains Button. Server contains Light. Server Reusable Spring/2002 Light. Bulb Reusable Distributed Software Engineering C: unocourses4350slidesDefining. Threads 56
Trade-off Evaluation • Second Solution : less code but – locks the relationship between a Button object and object it controls • Fourth solution : more flexible. – Any Button object can be used to control any derivative of Button. Server. – allows many different objects to be controlled by the same Button at different times. Spring/2002 Distributed Software Engineering C: unocourses4350slidesDefining. Threads 57
Engineering Tradeoff • Choice of solution to use involves an engineering tradeoff. • Fourth solution: – flexibility V. S. – speed and complexity overhead • Second solution – resource frugal V. S. – much less flexibility Spring/2002 Distributed Software Engineering C: unocourses4350slidesDefining. Threads 58
• Design 1 is the simplest; • simplicity of design does not necessarily relate – simplicity of maintenance, – possibility or simplicity of reuse. • in order to create a design that is maintainable and reusable, some conceptual effort must be applied. Spring/2002 Distributed Software Engineering C: unocourses4350slidesDefining. Threads 59
• There is a cost to applying object-oriented design. • Good object-oriented design will generally be more complex than procedural design • Extra complexity: – infrastructure to manage dependencies • Don’t begrudge extra complexity. Payoff – maintainance – reuse Spring/2002 Distributed Software Engineering C: unocourses4350slidesDefining. Threads 60
Cohesion • Abstraction unit model one concept • functionality to support concept only – Design goal: minimize features • A class with high cohesion : – maintains – localizes – protects features necessary to perform primary role Spring/2002 Distributed Software Engineering C: unocourses4350slidesDefining. Threads 61
Cohesion • Provide “enough” features to support role • This implies: – not adding derived functionality that can be perform with them • This enables – superimposed layers to control components in different ways • Goal: high cohesion of components Spring/2002 Distributed Software Engineering C: unocourses4350slidesDefining. Threads 62
Coupling • module’s collaborators – should be small in number – should interact through well defined interface • Unit minimizes demands on environment • Goal: low coupling and type of coupling Spring/2002 Distributed Software Engineering C: unocourses4350slidesDefining. Threads 63
Representational coupling • Should not depend on representation or computational detail of another one • Addresses: – interchangeable parts – multiple representations – prototype evolution – system evolution – performance tuning – Extensibility – External components – Standarization – Testability – Frameworks Spring/2002 Distributed Software Engineering C: unocourses4350slidesDefining. Threads 64
Value coupling • classes should be written so that operations are independent of particular values – when special values occur, use classes to classify and manipulate them(State pattern) Spring/2002 Distributed Software Engineering C: unocourses4350slidesDefining. Threads 65
Subclass coupling • a client refers to a subclass object through subclass reference rather than superclass reference. • In Java use of abstract classes and interfaces to raise reuse opportunity Spring/2002 Distributed Software Engineering C: unocourses4350slidesDefining. Threads 66
Code coupling (Control? ) • The definition of concrete operations should be decoupled from the context in which they are employed • Sequential vs. concurrent execution – Example: how to get an item to a list vs when to get it. – Should be possible to define how to get it for either situation Spring/2002 Distributed Software Engineering C: unocourses4350slidesDefining. Threads 67
Inheritance Coupling • this is a compile-time binding • cannot be discarted at execution time • This is the old problem: • inheritance vs. composition – if you compose: • may design zero or more instances of the object • can set/change its value at run-time. Spring/2002 Distributed Software Engineering C: unocourses4350slidesDefining. Threads 68
Rise of Coupling in OO • An OO system is a network of interactive objects – interaction between objects creates the coupling (dependence) – the interaction results due to implementation of relations among the objects – Thus coupling in OO system is necessary, but – it creates dependencies among classes, components, subsystems • activity of good analysis and design: management of dependencies Spring/2002 Distributed Software Engineering C: unocourses4350slidesDefining. Threads 69
What’s wrong with dependencies? • End result due to lack of management of these dependencies: – Brittle software: changes propagate beyond expected boundaries – OR – Hard software: it does not respond to changes • Opposite this state of affairs: – units of abstraction localize possible changes – and – abstraction units are change-responsive: flexible Spring/2002 Distributed Software Engineering C: unocourses4350slidesDefining. Threads 70
How to get flexible abstractions? • Actively design for that characteristic – Start with cohesion & coupling of abstractions • look for : high cohesion, low / kind of coupling – identify and abstract/encapsulate what varies – Test flexibility of your abstractions • produce an active list of possible changes to measure flexibility against. NNB Spring/2002 Distributed Software Engineering C: unocourses4350slidesDefining. Threads 71
Binding of Coupling • Static coupling – established at compilation time – need definitions of dependents for compilation • Dynamic coupling – two classes are dynamically coupled if their instances call methods of one or the other at run -time Spring/2002 Distributed Software Engineering C: unocourses4350slidesDefining. Threads 72
Transitivity in Dependencies • If A depends on B, B depends on C, hence A depends on C Spring/2002 Distributed Software Engineering C: unocourses4350slidesDefining. Threads 73
Coupling Best practices • Identify subsystems – closed for changes – reused as a whole – well-defined purpose • Reduce static coupling between different subsystems’ classes. Pay special attention to transitive coupling • Reduce dynamic coupling Spring/2002 Distributed Software Engineering C: unocourses4350slidesDefining. Threads 74
Software Principles • Information Hiding principle: • . A client does not need to know how a module (system) work to use it. • . A client should not be allowed to extend the system knowing how the system works. • Software Continuity principle: small changes in the specification should produce small changes in the implementation of the module (system) Spring/2002 Distributed Software Engineering C: unocourses4350slidesDefining. Threads 75
Software Principles. Cont. . • • • The OCP (Open-Closed Principle), The LSP (Liskov substitution Principle), The DIP (Dependency Inversion Princ), The ISP (Interface Segregation Principle), The RREP (Reuse/Release Equivalency principle), • The CCP (Common Closure Principle), Spring/2002 Distributed Software Engineering C: unocourses4350slidesDefining. Threads 76
Software Principles. Cont. . • • • The CRP (Common Reuse Principle) The ADP (Acyclic Dependencies Principle), The SDP (Stable Dependencies Principle) The SAP (Stable Abstractions Principle) The Lo. D (Law of Demeter) Spring/2002 Distributed Software Engineering C: unocourses4350slidesDefining. Threads 77
Скачать презентацию Object Design Basics Spring 2002 Distributed Software Engineering C
97c0d54275d16a86ba0e3b4d773f77bb.ppt