Subscribe to andrewsw's Blog        RSS Feed

OOP Concepts

Icon Leave Comment
Before Object-Oriented Programming, structured programming emphasized separating a program's data from its functionality. Separating data from functionality typically leads to software that is difficult to maintain and understand, especially in large programs.

Object-oriented programming (OOP) creates software that more realistically models real-world entities -- such as cars, bank accounts, and dogs -- in source and executable code. Structured programming emphasizes making an entity's representation fit the constraints of the programming language; OOP emphasizes making the programming language fit the constraints of the representation. For example, in a structured programming language, a car is represented by a set of functions (named bodies of code) for starting, braking, parking, accelerating, and so on. A separate set of variables defines the car's colour, number of doors, make, model, and so on. You initialize the car's variables and call some functions that operate on those variables -- and you have a car!

An OOP language sees a car as an integration of its behaviours -- the functions -- and the variables that hold the car's state -- the data values. The integration of state variables and behaviours results in an object. You create that object (new object, referred to as instantiating - creating an instance of a Class), usually at the same time initializing some of its variables. At any time, the object-oriented program identifies the object it wants to work with and calls the object's functions (its methods). Essentially, the object-oriented program thinks in terms of objects (e.g. cars) - not in terms of separate functions (e.g. parking) and variables (e.g. number of doors).

The integration of state variables and behaviours into objects is called encapsulation. Encapsulation promotes information hiding -- a concept that facilitates program maintenance by hiding state variables and behaviours that don't need to be externally accessed -- and is one of the three fundamental principles of OOP (the other two being inheritance and polymorphism).

Just as a contractor needs access to an architect's blueprint before creating a building based on that blueprint, a running program needs access to a Class before creating objects based on that Class. A Class is a source code blueprint for objects. That blueprint specifies each object's behaviours (known as methods) and state variables (known as fields).


Abstraction The ability of a language to create "black box" code, to take a concept and create an abstract representation of that concept within a program. A Customer object, for instance, is an abstract representation of a real-world customer.

Encapsulation The concept of separation between interface and implementation. The idea is that you can create an interface (public methods, properties, fields and events in a Class) and, as long as that interface remains consistent, an application can interact with objects of your Class. This remains true even when you rewrite the code within a given method; thus, the interface is independent of the implementation. The publicly exposed interface becomes what is known as a contract. It is this contract that you will look to, to limit changes for those who consume your objects.

Polymorphism Polymorphism is reflected in the ability to write one routine that can operate on objects from more than one Class treating different objects, from different Classes, in exactly the same way. For instance, if both Customer and Vendor objects have a Name property and you can write a routine that prints the Name property regardless of whether you are using a Customer or Vendor object, then you have polymorphism.

Visual Basic supports polymorphism in two ways through late binding and through the implementation of multiple interfaces. Late binding is where you declare a generic Object variable, and its object type is only determined at runtime.

Inheritance Inheritance is the concept that a new Class can be based on an existing Class, gaining the interface and behaviours of that base Class. The child or sub-class of that base or parent Class is said to inherit the existing behaviours and properties. The new Class can also customize or override existing methods and properties, as well as extending the Class with new methods and properties. Inheriting from an existing Class is known as subclassing.

There are two types of inheritance. Classical (implementation) inheritance where one Class is based on another, as described above. When people talk about inheritance this is usually what they mean. interface inheritance is where an interface is defined that only contains signatures for the methods and properties, etc., that another Class (that implements the interface) will supply. This type of inheritance is far more common (in .NET and elsewhere) than classical inheritance. Many would argue that this approach is far better than the classical approach. DIC discussion. Unfortunately, the term contract is also often used when discussing interface inheritance. (It is unfortunate that in OOP the same terms are re-used, and mean different things in different contexts.)

In Summary

These are all important concepts. However, at an early stage it is better that you first become familiar with how you create and use Classes. Once you are familiar with your editor, and the coding that is necessary to define and use a Class, then you can revisit these concepts to discover why.

In simple terms:

Any coding that we do is an abstraction. We are trying to describe something that is real to us, in terms that the computer can understand; or, at least, can do something useful with.

If several programmers are involved in a project, then we want to be able to complete our own task, and present the other programmers with something that they can use. They don't need to know - and probably don't want to know - how our feature works: they just want to know what it can do, and what information they should provide it with. This is encapsulation. Even if you were the sole programmer, you would want to be able to complete a section of your work, and then to re-use the code, safe in the knowledge that it will always behave as expected.

If you are creating code to represent two different, but similar, objects then it might be sensible to create something that contains the common features of both objects, and just tweak it a little for the two (more specific) objects. If a third similar object comes along, then this too could borrow from your main object (the parent Class). This is inheritance: it reduces the amount of coding that is needed, and allows you to re-use code that you already know works.

Polymorphism is harder to describe in broad terms (without code) and is somewhat similar to inheritance. If you have a driving licence you might Drive a car, but occasionally you might Drive a van. To you, there is no difference between the two as long as you reach your destination, you're happy. Polymorphism is not really a guiding, or essential, principle of object-oriented programming: it describes an important feature of OOP.

0 Comments On This Entry


Trackbacks for this entry [ Trackback URL ]

There are no Trackbacks for this entry