In order to be considered Object Oriented, a language must have built-in support for three concepts:
Encapsulation - Modularization and the ability to hide implementation details.
Inheritance - Defining characteristics and implementation objects based on pre-existing classes so that code can be easily and successfully reused
Polymorphism - the same message, when sent to different objects provokes different responses, depending on the nature of the object that receives the message.
Objects are models we create to represent real world entities, in software design. In everyday life you are surrounded by object all the time. Look around and you will see: cars, refrigerators, chairs, cats and dogs. All of these are objects.
Software applications also have objects such as buttons in the interface, grids and their cells, menus, string lists, etc. These objects, just as their real world counterparts, have states and behaviors. You can represent these characteristics (and their change over time - ie. states) and behaviors with software structures which are generally called objects.
In its daily comes and goings a car can be modeled as a car. An object has characteristics, which change over time defining its states (speed, aim, fuel consumption, etc) and behaviors (engine off, engine on, accelerate, turn left, break, etc.).
You drive to the office where you work with clients. The way you interact with clients can, also, be modeled through an object. The client also has characteristics (Current Phone, Current Address, etc) and behaviors (Move, Close Deal, etc).
In programming, an object's characteristics and state are defined by its instance variables (sometimes called member variables, or fields). Instance variables should always be private so as to not be accessible from outside the of the object. Public instance variables are accessible by code which does not belong to the object's class. This should be avoided as we will see when looking into encapsulation.
The behaviors of an object are defined by its methods. Methods handle all interaction with and operate on the instance variables, altering the object's state and even creating new objects.
In figure 1 you can see a simple graphical representation of an object. This picture represents the conceptual structure of an object, which is very similar to that of a cell. As in a cell, an external structure (the membrane) is the only part to have contact with the outside world and protects the nucleus.
|
|
| Figure 1: Graphical representation of an Object. |
The object's instance variables are encapsulated within it, surrounded by the object's methods. Except on very specific cases the object's methods should be the only the only venue available for other objects to access or alter instance variables. In Morfik Basic it is possible to have instance variables declared as public or published, except where absolutely necessary (like for IDE interaction with a Form's controls) this should be avoided as these variables will be globally available to other objects. Access levels and member visibility will be seen in greater detail in this chapter.
The basic idea behind the concept of Encapsulation is that the less that a user of objects you create know about how they are implemented, the less he/she will be affected by changes to that implementation.
A person that knows nothing about cars does not conclude anything about certain noises that the engine makes. A person with a bit more experience could be tempted to guess at the cause of a problem based on such noise and be frustrated by a new type of engine.
Please, don't image that this will help in hiding problems with your code. The goal is to avoid problems by avoiding that developers create code that depends on how your objects are implemented. This allows you to change how the objects are implemented without adversely affecting code created by third parties.
To put it simply, inheritance is the capability of creating new types of objects (called Classes) from previously existing types. With inheritance we re-use a previously existing class' (ancestor) functionality, add new functionalities and, if necessary, alter some of the class' behavior, thus creating a new Class (descendant) with a huge part of its functionality already tried and tested.
Before the advent of object oriented programming and the widespread use of inheritance, code reuse was mostly done by the creation offunction libraries or by the old cut-and-paste method. The cut-and-paste approach to code reuse normally requires that the copied code suffer small modifications and is very prone to introduce bugs in an application.
Polymorphism is the ability to treat objects of different types as if they were all of the same type, provided that they have a common ancestor. An example of this capability is that I can write a function which takes a Form object as a parameter and then pass any of the forms in an XApp to that function. This is possible because all forms in an XApp are descendant classes of the Form class.