User:TutorJDD/object-oriented programming

object-oriented programming

 * Topic:Object-oriented programming

Background
[...] software [...] purpose must be defined [...] usually captured in some kind of document [...] particularly when there is more than one participant involved in the creation of the software.

[•] Two major classes of design documentation have been placed into widespread practice:
 * 1) Requirements – The requirements define the intended functionality of the software for users and external systems. For example, one requirement of an automated teller machine is that the users that meet certain criteria must be able to withdraw cash.
 * 2) Specifications – The specifications state the constraints that must be met by users and external systems before the software will function properly (as defined by the requirements). For example, part of the specification of some automated teller machines is that the user must bring a bank card and swipe it in the machine. Users that do not comply with this part of the specification will be unable to use it.

[...] most software will never reach a point where all of the desired requirements are met because the requirements will change and grow as soon as the software goes into use. So, software design is principally concerned with designing software that is expected to continuously evolve to meet an ever-changing list of requirements. [...] good design is about creating software that can evolve and adapt over a long period of time and an indefinite number of versions, it is not chiefly concerned with creating a pristine finished product that is intended to remain untouched upon completion.

[...] Supporting the object oriented paradigm is the process of object oriented design, or OOD. OOD aims to design software such that it is broken up into manageable chunks called classes. A class is a unit of code that contains information and defines behaviors that manage that information. In this way, the information managed by the class can only be changed by the outside world in the ways defined by the class. The world outside that class need not understand the details of how such information must be manipulated; ensuring that the information is complete and consistent is managed within the class itself, greatly simplifying the task of working with that information for the outside world.

Principles
The fundamental unit of an object oriented system is the class. A class is a set of data and the behaviors that operate upon that data. Each behavior is captured in a method, which is a function associated with a class. A class defines a type of object that can exist within the system.

[...] an example. An object is related to its class much in the same way a specific dog ( [...] Rover) is related to the class of all dogs. In the object oriented approach we say that Rover is an instance of a dog. Similarly, we would refer to an object as an instance of a particular class. Just as Rover and Fido are two distinct instances of dogs, at any given time there may be many instances of a particular class existing in an object oriented system.

If we are designing an object oriented system designed to represent dogs, then, we would use this analogy to create a class called Dog. On this class we can define variables like hairColor, hairLength, eyeColor, weight, height, etc. We can also define behaviors that all dogs share such as eat, sleep, bark, and run. The behaviors we define may use the state stored in the variables to determine how to correctly carry out the behavior (for instance, a large dog will eat more and bark louder than a small dog). When we instantiate, or create, a new dog we would initialize it with all the properties of the specific dog we wish to represent. So, even though we'd have two instances of the Dog class in our system, fido and rover, they would exhibit the same behaviors in different ways based on their individual state.

There are three principles fundamental to the definition of all object oriented software: encapsulation, inheritance, and polymorphism. We will discuss each in turn, but [...] realize that all three principles work in combination to define a particular class.

The principle of encapsulation refers to the scope and visibility of state within a class. It is important for each class to define behaviors usable by the outside world in such a way that the internal state is not known outside the object, nor would it be necessary for that state to be known for objects of the class to serve a purpose within the system. Encapsulation goes hand-in-hand with

the principle of information hiding, [...] any information that need not be known by outside agents should be hidden from view. In this way, the outside world sees only what it needs to see in order to use the object, simplifying its usage.

To use the example above, the eat method of our Dog class might use a very complex algorithm based on the weight, height, and any other characteristics of that particular dog to calculate how much food it should eat when invoked. The outside world ought to regard the particular process used by the class with disinterest—it simply calls the eat method and, from that outside perspective, the dog eats.

Inheritance refers to a particular relationship that two or more classes can share. After we define our Dog class, we may wish to design some classes that represent particular breeds: German Shepherd, Pointer, and Retriever, for example. All of these are different kinds of dogs. As such, any behavior or characteristic our more generic Dog class contains ought to also be contained by each of these classes. [...] the different breeds of dog extend or inherit from the Dog class, and instances of those classes automatically get all of the characteristics and behaviors defined on Dog.

Polymorphism refers to a particular feature of classes that define an inheritance relationship. Above, we said that a Pointer is a specific kind of Dog, and therefore the Pointer class can extend the Dog class. Once this inheritance-type relationship is defined between these two classes, the outside world can treat any pointer specifically as a pointer, or it may also treat it more generally as simply a dog. When dealing with a particular instance, in fact, the outside world need not even know its dealing with a pointer. For example, if the Pointer class defines an additional behavior unique to pointers, such as point, when dealing with an instance of the Pointer class—let's call this particular dog pointy—we may invoke the point method and observe Pointy point. However, if we are only interested in requesting that Pointy do things that all dogs can do, such as eat and sleep, we may forget altogether that Pointy is in fact a Pointer and simply treat him just as though he were directly an instance of the Dog class. Polymorphism is the ability of objects to behave as though they are instances of a superclass. [...]