1 / 71

JAVA DESIGN Building Better Apps and Applets

JAVA DESIGN Building Better Apps and Applets. Peter Coad Object International, Inc. www.oi.com pc@oi.com 1-919-772-9350 fax -9389 direct line -7734 direct fax -8916. Version Date: Jan. 2, 1998. Purpose and Agenda. Purpose To gain insights into better design Agenda

teal
Télécharger la présentation

JAVA DESIGN Building Better Apps and Applets

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. JAVA DESIGNBuilding Better Apps and Applets • Peter Coad • Object International, Inc. • www.oi.com pc@oi.com • 1-919-772-9350 fax -9389 • direct line -7734 direct fax -8916 Version Date: Jan. 2, 1998

  2. Purpose and Agenda • Purpose • To gain insights into better design • Agenda • 1. Design with Composition, Rather than Inheritance. • 2. Design with Interfaces. • 3. Design with Threads. • 4. Design with Notification. • 5. Build with Java. "Building materials profoundly affect design techniques."

  3. 1. Design with Composition, Rather than Inheritance • Inheritance extends attributes and methods. • "What’s the same; what’s different." • Weak encapsulation with respect to superclasses • Awkward accommodation of change over time • Composition delegates work to other objects. • Message-based encapsulation • Gracious accommodation of change over time

  4. Inheritance: Good Uses (i) MomentInterval dateTime number Reservation Purchase dateTimeExpiration amount notifyPendingExpiration total publicabstractclass MomentInterval extends Object { /*code*/ } publicclass Reservation extends MomentInterval { /*code*/ } publicclass Purchase extends MomentInterval { /*code*/ }

  5. Inheritance: Good Uses (ii)

  6. Inheritance: Problems (i)

  7. Inheritance: Problems (ii)

  8. Inheritance: When to Use It

  9. Composition publicclass Passenger extends Object { private Vector reservations; /*created by constructor*/ }

  10. Composition and Change (i)

  11. Composition and Change (ii)

  12. Combo

  13. 2. Design with Interfaces • A common set of method signatures • Interfaces let you connect to and message... • An object in any class that implements that interface • Rather than an object in a specific class. publicinterface IName { public String getName(); publicvoid setName(String aName); } interface public Person extends Object implements IName { public String getName() {/*code*/} publicvoid setName(String aName) {/*code*/} } Person IName implementer

  14. Why Design with Interfaces? • Abstraction of common method signatures • Abstract upwards and avoid method signature overload. • Interaction substitution • Interact with objects from one class as if it were an object from another class. • Part substitution • Unplug an object from one class and plug in an object from another class.

  15. Interface Strategies (First Set) --Factor Out a. Strategy: factor-out common method signatures. b. Strategy: factor-out proxies. c. Strategy: factor-out by analogy. d. Strategy:factor-out future expansion.

  16. a. Common Method Signatures (i) • Strategy: factor-out common method signatures. Person Store Sale Customer name number dateTime number address n 1 n 1 1 n grandTotal calcTotal howMuch howMuch calcTax n 1-n 1 1 Item SaleLineItem number quantity description 1 n calcTotal price calcTax howMany

  17. a. Common Method Signatures (ii) Store ICount Customer Person Sale number howMany number name dateTime n 1 n 1 1 n ITotal address ICount ISell ICount ITotal 1-n calcTotal n ITax 1 calcTax 1 Item ISell SaleLineItem number ITotal quantity description ITax 1 n price ISell ICount publicinterface ISell extends ITotal, ITax {}

  18. b. Proxies (i) • Strategy: factor-out proxies. Passenger Person type name IName 1 1 number address getName INameAddress setName IAddress getAddress setAddress INameAddress Person Passenger IName name type IAddress address number 1 1 INameAddress INameAddress

  19. b. Proxies (ii) INameAddress NameAddressUI IName n IAddress display publicclass NameAddressUI { private Vector nameAddresses; /*created by constructor*/ publicvoid addNameAddress(INameAddress aNameAddress) { this.nameAddresses.addElement(aNameAddress); } publicvoid display() { Enumeration nameAddressList = this.nameAddresses.elements(); while (nameAddressList.hasMoreElements()) { StringnameAddress = (String) nameAddressList.nextElement(); /*display using nameAddress.getName()*/ /*display using nameAddress.getAddress()*/ } } }

  20. c. By Analogy (i) • Strategy: factor-out by analogy. FlightDescription hasAvailableSeat reserveSeat cancelSeat IDateReserve FlightDescription available (date) reserve (date, reserver) IDateReserve cancel (date, reserver)

  21. c. By Analogy (ii) DateReserveUI IDateReserve available (date) invokeAvailable n reserve (date, reserver) invokeReserve cancel (date, reserver) invokeCancel FlightDescription IDateReserve

  22. c. By Analogy (iii) IDateReserve DailyWorkOrder available (date) reserve (date, reserver) n reserveResources cancel (date, reserver) Equipment Worker Workspace IDateReserve IDateReserve IDateReserve publicclass DailyWorkOrder { private Vector dateReservables; /*created by constructor*/ publicvoid addDateReserves(IDateReserve aDateReserve) { this.dateReservables.addElement(aDateReserve); } publicvoid reserveResources() { Enumeration dateReservableList = this.dateReservables.elements(); while (dateReservableList.hasMoreElements()) { IDateReserve dateReservable = (IDateReserve) dateReservablesList.nextElement(); dateReservable.reserve(); } } }

  23. d. Future Expansion (i) • Strategy:factor-out for future expansion. Zone IActivate IActivate n activate deactivate 1 Sensor IActivate Coad notation UML notation

  24. d. Future Expansion (ii) IActivate Zone activate deactivate n IActivate Sensor IActivate

  25. d. Future Expansion (iii) IActivate Zone activate deactivate n IActivate Sensor Motor RobotArm Switch IActivate IActivate IActivate IActivate publicclass Zone { private Vector activatibles; /*created by constructor*/ publicvoid addActivate(IActivate anActivate) { this.activatibles.addElement(anActivate); publicvoid activate() { Enumeration activatableList = this.activatables.elements(); while (activatableList.hasMoreElements()) { IActivatable activatable = (IActivate) activatableList.nextElement(); activatable.activate(); } } }

  26. Interface Strategies (Second Set) -- Design-In e. Strategy: design-in, from features to interfaces. f. Strategy: design-in, from role to interfaces to proxies. g. Strategy: design-in, from collections to interfaces. h. Strategy: design-in, from scenarios to interfaces. i. Strategy: design-in, from intra-class roles to interfaces. j. Strategy: design-in, from plug-in methods to interfaces.

  27. e. Features to Interfaces (i) • Strategy: design-in, from features to interfaces. • Look for a common feature, one you need to provide in different contexts. • Identify a set of common method names that correspond to that feature. • Add an interface. • Identify implementers. • Features: • Total outstanding balances for a borrower • Total outstanding balances for an applicant. • List accounts and limits for a borrower. • List accounts and limits for an applicant.

  28. e. Features to Interfaces (ii) IAccount totalOustandingBorrowingBalance listBorrowingAccountsAndLimits BorrowingAccount Applicant Borrower 0-1 1 0-1 1 getBalance IAccount IAccount publicinterface IAccount { publicdouble totalOutstandingBorrowingBalance(); public Enumeration listBorrowingAccountsAndLimits(); }

  29. f. Role to Interface to Proxies (i) • Strategy: design-in, from role to interface to proxies. • Take a role and turn its method signatures into a role-inspired interface. • Let a party or a role offer that same interface by: • Implementing that interface, and • Delegating the real work to the original role player. Borrower totalApprovedLimits totalAvailableLimits

  30. f. Role to Interface to Proxies (ii) Borrower IBorrow totalApprovedLimits totalAvailableLimits IBorrow Borrower Party Applicant 0-1 1 n 1 IBorrow IBorrow IBorrow Person Organization IBorrow totalApprovedLimits totalAvailableLimits

  31. f. Role to Interface to Proxies (iii) • publicinterface IBorrow { • publicdouble totalApprovedLimits(); • publicdouble totalAvailableLimits(); • } • public Borrower extends Object implements IBorrow { • publicdouble totalApprovedLimits() {/*real work*/} } • publicdouble totalAvailableLimits() {/*real work*/} • } • public Applicant extends Object implements IBorrow { • private Borrower borrower; /*add/remove with add/remove methods*/ • publicdouble totalApprovedLimits() { • returnthis.borrower. totalApprovedLimits (); /*delegate*/} • publicdouble totalAvailableLimits() { • returnthis.borrower. totalAvailableLimits (); /*delegate*/} • }

  32. g. Collections and Members to Interfaces (i) • Strategy: design-in, from collections and members to interfaces. • Does your object hold a collection of other objects? If so: • Consider its potential method signatures. • If other collections might offer the same set of method signatures, then design-in that common interface. • Is your object a member within a collection? If so: • If that object needs to provide an interface similar to the collections it is in, then design-in that common interface. • Identify implementers.

  33. g. Collections and Members to Interfaces (ii) ITotalApprovedLimit totalApprovedLimit ICompareAppliedVsApproved compareAppliedVsApproved Approval Application n 1 ITotalApprovedLImit ITotalApprovedLimit ICompareAppliedVsApproved ICompareAppliedVsApproved

  34. h. Scenarios to Interfaces(i) • Strategy: design-in, from scenarios to interfaces. • Look for similar interaction patterns. • Add an interface-implementer column. • Use this naming convention: I<what it does> Implementer • Add an interface: I<what it does>. • Identify implementers.

  35. h. Scenarios to Interfaces (ii) Name: Assess profit and risk (i). Applicant Application Borrower BorrowingAccount Constraints: assessProfit assessRisk assessProfit assessProfit assessRisk assessRisk assessRisk assessProfit assessProfit ( ; profit) assessProfit assessProfit ( ; profit) n n assessProfit assessProfit assessRisk assessRisk ( ; risk) n n assessRisk assessRisk ( ; risk) assessRisk assessRisk n n assessRisk assessRisk Name: Assess profit and risk (ii). Applicant IAssessProfitAndRisk Implementer Constraints: assessProfit assessProfit assessRisk assessRisk assessProfit assessProfit ( ; profit) assessProfit assessProfit ( ; profit) assessRisk assessRisk ( ; risk) assessRisk assessRisk ( ; risk)

  36. h. Scenarios to Interfaces (iii) IAssessProfitAndRisk IAssessRisk Application assessProfit assessRisk IAssessRisk Applicant IAssessRisk n 1 IAssessProfitAndRisk Borrower 0-1 1 BorrowingAccount n 1 IAssessProfitAndRisk IAssessProfitAndRisk assessRisk

  37. i. Intra-Class Roles to Interfaces (i) • Strategy: design-in, from intra-class roles to interfaces. • Identify roles that objects within a class can play. • Establish an interface for each of those roles. • Identify implementers.

  38. i. Intra-Class Roles to Interfaces (ii) ITransferSource Account transferTo ITransferSource ITransferDestination ITransferDestination transferFrom Name: Transfer from one account to another. Account [from] Account [to] Constraints: transferFrom transferTo transferFrom transferFrom (amount, transferTo ; result) transferTo transferTo (amount ; result)

  39. j. Plug-In Methods to Interfaces (i) • Strategy: design-in, from plug-in methods to interfaces. • Look for useful functionality you’d like to "plug in.” • Add a plug-point, using an interface. • Identify implementers.

  40. j. Plug-In Methods to Interfaces (ii) Term IValidateTerm 1 validateTerm validate Name: Validate a term. Term IValidateTerm Implementer Constraints: validate validateTerm validate validate ( ; result) validateTerm validateTerm ( ; result) • publicclass Term extends Object { • private IValidateTerm validater; • publicint validate() { • return validater.validateTerm(); } • publicinterface IValidateTerm { • publicint validateTerm(); }

  41. 3. Design with Threads • A thread is a stream of program execution.

  42. Multiple Threads this.mainThread = new Thread (this); this.mainThread.start();

  43. Why Threads

  44. Threads and Shared Values (a)

  45. Threads and Shared Values (b)

  46. Threads and Synchronized Methods (a) Name: Reserve space. FlightDescription ScheduledFlight Constraints: reserve reserve reserve reserve (passenger, date; reservation) SYNC SYNC reserve reserve (passenger; reservation) ENDSYNC ENDSYNC reserve reserve SYNC SYNC reserve reserve (passenger; reservation) ENDSYNC ENDSYNC publicclass ScheduledFlight extends Object { publicsynchronized Reservation reserve(Passenger aPassenger, Date aDate) {/*code*/} }

  47. Threads and Synchronized Methods (b) • At the start of a sync’d method,ð just one thread may enter. • That thread can invoke non-syncsð no waiting. • That thread can invoke syncs in the same objectð no waiting. • That thread can invoke syncs in other objectsð potential waiting, potential for deadlock.

  48. Threads and Synchronized Methods (c) .

  49. Thread Strategies (a) • "Short Synchronized Methods" Strategy • Keep synchronized methods short and to the point. • "Thread Gatekeeper" Strategy • Use a thread gatekeeper, an object that permits just one thread at a time into a collection of cross-messaging objects.

  50. Thread Strategies (b) • "Four Thread Designs" Strategy • Single • Prioritized objects (hi-pri objects, low-pri objects) • Prioritized methods (hi-pri methods; low-pri methods) • Combo

More Related