Unit-2: Object Basics:
1 The Object-Oriented Philosophy
As we have noted, OO programming languages had their roots in simulation.
The first proponents of OO looked back to simulation, one of the early success stories in programming and design. Many early simulation programmers were able to construct programs that were organized in a way that made them easy to modify and maintain.
In part this was because Simula and other simulation programming languages offered features that supported ADTs as modular building blocks – but so did many other programming languages. Beyond the question of what the language supported, there was the issue of how those simulation programmers organized their programs in the first place. They were, in a very literal sense, keeping it real.
This, it was thought, was because the focus on modeling the real world, in a language that created a module for each kind of real-world object, led to programs that felt “natural” and easily understood by anyone who understood the part of the real world that was being simulated.
1.1 Program = Simulation
The Object-Oriented Philosophy
Every program is really a simulation.
The quality of a program’s design is proportional to the faithfulness with which the structures and interactions in the program mirror those in the real world.
According to this philosophy, a program to manage book handling in a library is really a simulation of what the librarians would have done prior to automation. A program to compute a company payroll is a simulation of what the accounting clerks would have done. A program to compute student grades at the end of a semester is a simulation of what a teacher would have done manually.
Now, sometimes the worlds being simulated may be artificial or imaginary (e.g., chess and other games, fractal mathematics) but, as long as they are well understood, that really doesn’t matter. You may be able to come up with exceptions to the “every program is a simulation” rule,1 but the very fact that you have to think for a while to do so is a significant sign that this claim is plausible,
If you buy the first part of this philosophy, then the second part becomes really interesting. Ever listen to another programmer explain a design and wonder how the heck that was going to solve the problem at hand? Ever notice how programmers love to make up new terms for things in their code, often in defiance of the normal English-language meaning of the word? Or, even worse, ever read code where the variables had names like info or data or value or the functions had names like processData? Does anyone think names like those {\em really} have any informational content?
The OO philosophy suggests that the things manipulated by the program should correspond to things in the real world. They should carry the same names as those things carry in the real world. And they should interact in ways like those objects n the real world.
Design from the World
Walk into a library and what do you see?
Books, Librarians, Patrons (customers), Shelves, …
In an older library you might actually see a card catalog!
Of course, on the way in the door you saw the building/Branch Library.
These things2 form a set of candidate ADTs.
Next we would explore the various properties and relationships that these things exhibit in real life:
In our [earlier example]{doc:functionalDesign), we considered a function-based approach to design, coming up with subsystems like RecordStorage, CheckInOut, AccountMgmt, and InventoryMgmt.
In the OO approach to our earlier library design, we might never arrive at those. Instead, we would draw upon our knowledge of the world of libraries and say that this world is populated by Books, CardCatalogs, Librarys, LibraryBranches, Patrons, etc., and these would become our initial set of ADTs, our modules for the system design. If our personal knowledge of the world of libraries is not quite up to snuff, we can ask the domain experts, the librarians and staff and patrons of the library.
Real-World Relationships
Books have titles, authors, ISBN, …
Librarians and Patrons have names. Patrons have library cards with unique identifiers. Most librarians are also patrons.
Patrons return books. Librarians check in the returned books.
Librarians check books out for patrons. (At some libraries, patrons can also do their own check-out.) Librarians handle the processing of newly acquired books.
Although books can be returned to any branch, each book belongs to a specific branch and will, if necessary, be delivered there by library staff.
Organizing the World
OO designers would start by organizing these things into ADTs, e.g.:
Objects, Object Behavior
Behavior binds the structure of objects to their attributes and relationships so that objects can meet their responsibilities. Ultimately, an object's operations implement its behavior. In this chapter Bruce Powel Douglass tells us how we can define and refine operations and behaviors. There are a number of means for specifying overall object behavior, the most important of these being modeling the object as a finite state machine.
An object is a single unit having both data and the processes that operate on that data. For example, in object oriented programming language like C++, the data and functions are bundled together as a self contained unit called an object. An object is an entity which has some properties and behavior associated with it. Objects are the basic run time entities in an object oriented system. programming problems are analyzed in terms of objects. The main purpose of using objects are following.
They correspond to the real life entities.
They provide interactions with the real world.
They provide practical approach for the implementation of the solution.
All the objects have a state, behavior and identity.
State of an object - The state or attributes are the built in characteristics or properties of an object. For example, a T.V has the size, colour, model etc.
Behaviour of the object - The behavior or operations of an object are its predefined functions. For example, a T.V. can show picture , change channels, tune for a channel etc. in object oriented programming terminology the behavior is implemented through methods.
Object identity - Each object is uniquely identifiable. For example, the fridge can not become the T.V.
Object Oriented Properties
Encapsulation
Encapsulation is accomplished when each object maintains a private state, inside a class. Other objects can not access this state directly, instead, they can only invoke a list of public functions. The object manages its own state via these functions and no other class can alter it unless explicitly allowed. In order to communicate with the object, you will need to utilize the methods provided. One way I like to think of encapsulation is by using the example of people and their dogs. If we want to apply encapsulation, we do so by encapsulating all “dog” logic into a Dog class. The “state” of the dog is in the private variables playful, hungry and energy and each of these variables has their respective fields.
There is also a private method: bark(). The dog class can call this whenever it wants, and the other classes can not tell the dog when to bark. There are also public methods such as sleep(), play() and eat() that are available to other classes. Each of these functions modifies the internal state of the Dog class and may invoke bark(), when this happens the private state and public methods are bonded.
Abstraction
Abstraction is an extension of encapsulation. It is the process of selecting data from a larger pool to show only the relevant details to the object. Suppose you want to create a dating application and you are asked to collect all the information about your users. You might receive the following data from your user: Full name, address, phone number, favorite food, favorite movie, hobbies, tax information, social security number, credit score. This amount of data is great however not all of it is required to create a dating profile. You only need to select the information that is pertinent to your dating application from that pool. Data like Full name, favorite food, favorite movie, and hobbies make sense for a dating application. The process of fetching/removing/selecting the user information from a larger pool is referred to as Abstraction. One of the advantages of Abstraction is being able to apply the same information you used for the dating application to other applications with little or no modification.
Inheritance
Inheritance is the ability of one object to acquire some/all properties of another object. For example, a child inherits the traits of his/her parents. With inheritance, reusability is a major advantage. You can reuse the fields and methods of the existing class. In Java, there are various types of inheritances: single, multiple, multilevel, hierarchical, and hybrid. For example, Apple is a fruit so assume that we have a class Fruit and a subclass of it named Apple. Our Apple acquires the properties of the Fruit class. Other classifications could be grape, pear, and mango, etc. Fruit defines a class of foods that are mature ovaries of a plant, fleshy, contains a large seed within or numerous tiny seeds. Apple the sub-class acquires these properties from Fruit and has some unique properties, which are different from other sub-classes of Fruit such as red, round, depression at the top.
Polymorphism
Polymorphism gives us a way to use a class exactly like its parent so there is no confusion with mixing types. This being said, each child sub-class keeps its own functions/methods as they are. If we had a superclass called Mammal that has a method called mammalSound(). The sub-classes of Mammals could be Dogs, whales, elephants, and horses. Each of these would have their own iteration of a mammal sound (dog-barks, whale-clicks).
Association and Aggregation.
Association:
An association is defined as an organization of people with a common purpose and having a formal structure. It represents a binary relationship between two objects that describes an activity. It is a relationship between objects. For example, A doctor can be associated with multiple patients.
Aggregation:
An aggregation is a collection, or the gathering of things together. This relationship is represented by a “has a” relationship. In other words, aggregation is a group, body, or mass composed of many distinct parts or individuals For example, phone number list is an example of aggregation.
Difference between Aggregation and Association:
No comments:
Post a Comment