05
Jan
Chapter 1: Object Technology Equally, by isolating the
Chapter 1: Object Technology Equally, by isolating the driver from the internals, and only permitting a trained engineer access to the components, a second benefit is obtained. If the car develops a fault, then an engineer may replace the faulty component. The change has, however, been effected without any operational change. The driver still uses the car in exactly the same way. Only the repair of the faulty component has changed. These ideas are also mirrored in object technology. They present the same benefits to software as they do to cars. In a software object the attributes are hidden from a user but may be replaced without affecting user software that relies on that object abstraction (information hiding). In a software object behaviour is defined by its operations and not by its private representation. The operations govern what we can ask a software object to perform. If we supply an unacceptable value when invoking an operation, then the effect can be denied, ensuring the correct state of the object. For example, a debit operation applied to a bank account might only be permitted if sufficient funds are available. Since object attributes and operations only define their abstraction and no other, they usually exhibit loose coupling with other objects. This is highly desirable because strong coupling makes software components harder to understand, change or correct. For example, when defining an object s operation we need not concern ourselves with the requester (client) of that operation. Only the effect of that operation on the receiving object s attributes need be considered. Equally, the client requesting a service need not be concerned with how that request is achieved by the recipient object. 1.2.3 Object interaction is expressed as messages Figure 1.1 demonstrated that objects interact with each other by sending a message from the sender requesting the recipient object to carry out one of its advertised operations. In figure 1.1 a University object requests the age of a Student object. Equally, a bank object may send one of its account objects a credit operation. Here, the bank is the sending object and the account is the receiving object. A message identifies the recipient object and the name for the operation to be performed. The message name represents one of the operations of the class to which the recipient belongs. If the message requires any further details they are given as the message parameters. To request a bank account object to engage in a transaction to debit it by some monetary amount, some sending object, such as an automated teller machine (ATM), might send the account object the message: acc debit 50 Here, acc is the identifier of the receiver object which is some bank account object, debit is the operation it is being asked to execute, and 50 is the actual parameter informing the receiver account of the amount involved in the transaction. The UML collaboration diagram in figure 1.6 portrays this message passing between objects. In the diagram we have two objects: an Account object with identifier acc and an anonymous (no identifier) ATM object. The latter sends a message to the Account object to perform the operation debit with the actual parameter value of 50.
For high quality website hosting services please check cheap web hosting website.