Download Object-Oriented Programming: Net Languages, Encapsulation, Polymorphism, Inheritance, and and more Study notes Information Systems Analysis and Design in PDF only on Docsity!
Chapter 9 Class & Method Design Review of the Basic Characteristics of Object Orientation Object-oriented systems traced back to Simula & Smalltalk programming languages Increase in power & decrease in processor cost in 1980s-object-oriented approaches not practical at this time Many of specific details concerning basic characteristics of object-orientation language dependent o Each object-oriented programming language tends to implement some of object- oriented basics in diff ways. C++, Java, & Visual Basic.Net programming languages most predominant object-oriented languages Classes, Objects, Methods, & Messages Object-basic building block of sys o Instance of classes that we use as templates to define objects o Has attributes & its relationships w/ other objects at particular point in time o Has methods-specify what processes that object can perform Methods used to implement operation that specified object behavior o To get object to perform method, message is sent to object o Message-function or procedure call from one object to another object. Encapsulation & Information Hiding Encapsulation o Mechanism that combines processes & data into single object Information Hiding o Suggests only info required to use object available outside object Info hiding related to visibility of methods & attributes Exactly how object stores data or performs methods not relevant o As long as objects functions correct o Only requirement is to use object that are set of methods & messages needed to be sent to trigger them o Only comm. b/w objects should be through object’s methods Key To Reusability o Use an object by sending a message that calls methods is key to reusability b/c it shows internal workings of object from changes in outside sys, & it keeps sys from being affected when changes are made to an object Polymorphism & Dynamic Binding Polymorphism o Ability to take several forms o Object-oriented systems can send same message to set of objects, which can be interpreted differently by diff classes of objects o Based on Encapsulation & Information Hiding, object doesn’t have to be concerned w/ how something is done when using other objects Simply sends message to object & that object determines how to interpret message Accomplished via use of Dynamic Binding o Can be a double-edged sword Dynamic Binding o Ability of object-oriented systems to defer data typing of objects to run time
Example: imagine that you have array of type employee that contains instances of hourly employees & salaried employees (Figure 9-2, Page 321) o Most-object oriented programming languages support Dynamic Binding of methods, & some support dynamic binding of attributes o Important to know what object-oriented programming language is going to be used o Through use of Dynamic Binding, now way to know before run time which specific object will be asked to execute its method In effect, decision made by sys that is not coded anywhere b/c all these decisions made at run time, possible to send message to object that it does not understand object does not have corresponding method this can cause run-time error that, if not programmed to hand correctly, can sys to abort If methods not semantically consistent, developer cannot assume that all methods w/ same name will perform same generic operation. o Example: imagine that you have array of type person that contains instances of employees & customers (Figure 9.3, Page 322) Semantics of each method must be determined individually Substantially increases difficulty of understanding individual objects o Key to Controlling Difficulty: When using polymorphism, ensure that all methods w/ same name implement same generic operation. Inheritance Allows developers to define classes incrementally by reusing classes defined previously as basis for new classes We could define each class separately, but simpler to define one general superclass that contains data & methods needed by subclasses & then have these classes inherit properties of superclass o Subclasses inherit appropriate attributes & methods from superclasses above them Inheritance makes it simpler to define classes Most common inheritance mechanisms o Diff forms of single & multiple inheritance Currently, all object-oriented methodologies, databases, & programming languages permit extending definition of superclass through single inheritance Some object-oriented methodologies, databases, & programming languages allow subclass to redefine some or all of attributes &/or methods of its superclass o With Redefinition capabilities, possible to introduce Inheritance Conflict i.e., an attribute (or method) of a subclass w/ same name as an attribute (or method) of a superclass Example: Figure 9-4, Page 323 o Developers must be aware of effects of modification not only in superclass, but also in each subclass that inherits the modification Through Redefinition Capabilities, possible for programmer to arbitrarily cancel inheritance of methods by placing stubs in the subclass that will override definition of the inherited method
Constraints & Contracts Contract formalizes interaction b/w client & server objects, where client (consumer) object is an instance of a class that sends message to server (supplier) object that executes one of its methods in response to the request Contracts modeled on legal notion of contract, where both parties, client & server objects, have obligation & rights o Partially speaking, contract is set of constraints & guarantees. If constraints met, then server object will guarantee certain behavior Constraints can be written in either Natural Language (e.g., English, Structured English, pseudocode) or Formal Language (e.g., UML’s Object Constraint Language) Type of Constraints 3 Types of Constraints in Object-Oriented Design o Preconditions o Postconditions o Invariants Contracts used primarily to establish preconditions & postconditions for method to be able to execute properly o Precondition is constraint that must be met for method to execute Example: parameters passed to a method must be valid for method to execute Otherwise exception should be raised o Postcondition is constraint that must be met after method executes, or effect of method execution must be undone. Example: method cannot make any of attributes of object take on an invalid value In this case, an exception should be raised, & effect of method’s execution must be undone. Preconditions & Postconditions model constraints on individual method o Invariants model constraints that must always be true for all instances of a class Example: domains or types of attributes, multiplicity of attributes, & the valid values of attributes Includes the attributes that model association & aggregation relationships o Example: if an association relationship is required, an invariant should be created that will enforce it to have a valid value for the instance to exist. o All invariants normally attached to the class We can attach invariants to the CRC cards or class diagram by adding set of assertions to them. o If all invariants placed on class diagram, the diagram will become very difficult to understand Highly recommended to extend CRC card to document invariants instead of attaching them all to the class diagram Elements of a Contract Contracts document the message passing that takes b/w objects o In practice, a contract is created for each method that can receive messages from other objects (i.e., one for each visible method).
o Contracts should be created for each message sent & received by each object; one for each interaction There would be quite a bit of duplication is this were done Contract should contain the info necessary for a programmer to understand what a method is to do (i.e., they are declarative in nature). o Info includes method name, class name, ID number, client objects, associated use cases, description, arguments received, type of data returned, & the pre- & postconditions. Contracts do not have detailed algorithmic descriptions of how method is to work o Not procedural in nature o Detailed algorithmic descriptions typically documented in method specification Contract composed of info required for developer of client object to know what messages can be sent to server objects & what client can expect in return. B/c each contract associated w/ specific method & specific class, contract must document them. o ID number of contract used to provide unique identifier for every contract o The Clients (Consumers) element of contract is list of classes & methods that send message to this specific method This list determined by reviewing sequence diagrams associated w/ server class o The Associated Use Cases element is list of use cases in which this method is used to realize implementation of the use case Use cases listed her can be found by reviewing server class’s CRC card & associated sequence diagrams. Description of Responsibilities provides informal description of what the method is to perform, not how it is to do it. o The arguments received are the data types of parameters passed to the method & the value returned is the data type of the value that the method will return to its clients. o Together w/ the method name, they form the signature of the method. Pre- & postconditions can be written in natural language, Structured Language, pseudocode, or a formal language o Does not matter which one you use o The more precisely they are written, the less likely it is that the programmer will misunderstand them. Highly recommended to use either pseudocode or a formal language such as UML’s Object Constraint Language Method Specification After analyst communicates big picture of how sys needs to be put together, analyst needs to describe individual classes & methods in enough detail so that programmers can take over & begin writing code. Methods on CRC cards, class diagram, & contracts using Method Specifications o Method Specifications-written documents that include explicit instructions on how to write the code to implement the method Project team members write specification for each method & then pass them to programmers- write the code during implementation of the project
Case Statement-advanced form of an If statement that has severally mutually exclusive branches. Pseudocode Pseudocode-language that contains logical structures, including sequential statements, conditional statements, & iteration o Differs from Structured English in that pseudocode contains details that are programming specific, such as initialization instructions or linking, & it also is more extensive so that a programmer can write the module by mirroring the pseudocode instructions. In general, pseudocode is much more like real code, & its audience is the programmer, as opposed to the analyst. o Its format is not as important as the info it conveys Writing good pseudocode can be difficult; imagine creating instructions that someone else can follow w/out having to ask for clarification or making a wrong assumption o Example: someone else may have made the interpretation take a left turn at the first road, w/ or w/out a light o Therefore, when writing pseudocode, pay special attention to detail & readability. If the algorithm of a method is complex, a tool that can be useful for algorithm specification is UML’s activity diagram. o Activity diagrams can be used to specify any type of process. An algorithm specification represents a process. o However, due to the nature of object orientation, processes tend to be highly distributed over many little methods over many objects. o As such, needing to use an activity diagram to specify the algorithm of a method may hint at a problem in the design. Example: the method should be further decomposed or there could be missing classes. The last section of method specification provides space for other info that needs to be communicated to the programmer o Calculations, special business rules, calls to subroutines or libraries, etc. This can also point out changes or improvements that will be made to any of the other design documentation based on problems that the analyst detected during the specification process.
