Kĩ thuật lập trình - Chapter 9: Class and method design
Query operations should not be redefined
Methods that redefine inherited ones should only restrict the semantics of the inherited ones
The underlying semantics of the inherited method should never be changed
The signature (argument list) of the inherited method should never be changed
36 trang |
Chia sẻ: huyhoang44 | Lượt xem: 656 | Lượt tải: 0
Bạn đang xem trước 20 trang tài liệu Kĩ thuật lập trình - Chapter 9: Class and method design, để xem tài liệu hoàn chỉnh bạn click vào nút DOWNLOAD ở trên
Chapter 9:Class and Method DesignObjectivesBecome familiar with coupling, cohesion, and connascence.Be able to specify, restructure, and optimize object designs.Be able to identify the reuse of predefined classes, libraries, frameworks, and components.Be able to specify constraints and contracts.Be able to create a method specification.BASIC CHARACTERISTICS OF OBJECT ORIENTATIONElements of OOSADClassesObjectsAttributesStatesMethodsMessagesEncapsulation & Info HidingHiding the content of the object from outside viewCommunication only through object’s methodsKey to reusabilityPolymorphism & Dynamic BindingSame message triggers different methods in different objectsDynamic binding means specific method is selected at run timeImplementation of dynamic binding is language specificNeed to be very careful about run time errorsNeed to ensure semantic consistencyPolymorphism ExampleInheritanceSingle inheritance -- one parent classMultiple inheritance -- multiple parent classesRedefinition and inheritance conflictMost inheritance conflicts are due to poor classificationRumbaugh’s RulesQuery operations should not be redefinedMethods that redefine inherited ones should only restrict the semantics of the inherited onesThe underlying semantics of the inherited method should never be changedThe signature (argument list) of the inherited method should never be changedDESIGN CRITERIACouplingInterdependency among modulesInteraction coupling through message passingLaw of DemeterMessages should be sent only by an object:to itselfto objects contained in attributes of itself or a superclassto an object that is passed as a parameter to the methodto an object that is created by the methodto an object that is stored in a global variableTypes of Interactive Coupling14Cohesion“Single-mindedness of a module”Method cohesionClass cohesionTypes of Method CohesionTypes of Class CohesionConnascenceCreating the need to change another module as a result of changing oneMinimize overall connascenceMinimize across encapsulation boundariesMaximize within encapsulation boundaryTypes of ConnascenceOBJECT DESIGN ACTIVITIESAdditional SpecificationFirst review the current set of modelsSufficient but only necessary classes to solve problemNo missing attributes or methodsNo extraneous attributes or methodsExamine visibilitySignatures for each methodName of the methodParameters or arguments to passType of value the method will return to the calling methodDefine constraintsPre-conditionsPost conditionsInvariantsHow to handle violations (exceptions in C++ and Java)?Identify Opportunities for ReusePatternsFrameworkClass librariesComponentsRestructure the DesignFactoringMap design to current languageNormalizationAssure all inheritance relationships support only generalization/specialization semanticsOptimizing the DesignReview access pathsReview attributes of each classReview direct and indirect fan-outConsider execution order of statements in often-used methodsAvoid re-computation by creating derived attributes and triggersCONSTRAINTS AND CONTRACTSTypes of ConstraintsPreconditionMust be true before the method executesPost-conditionMust be true after the method finishesInvariantMust always be trueInvariants on a Class DiagramContractsContracts document message passing between objectA contract is created for each method that is publicly visible in a classShould contain enough information for the programmer to understand what the method is supposed to doElements of a ContractMethod nameClass nameID numberClient objectsAssociated use casesDescriptionArguments receivedType of data returnedPreconditionsPost-conditionsSample Contract FormMETHOD SPECIFICATIONMethod Specification SyntaxNo formal syntax specificationGeneral informationEventsMessage PassingAlgorithm SpecificationStructured EnglishPseudocode Example(Get CD-info module) Accept (CD_title) {Required} Accept (CD_artist) {Required} Accept (CD_category) {Required} Accept (CD_length)ReturnSummaryBasic Characteristics of Object OrientationDesign CriteriaObject Design ActivitiesConstraints and ContractsMethod Specification
Các file đính kèm theo tài liệu này:
- ch09_7268.ppt