<- Previous Page Next Page ->

Advantages of OOP

After this elaborate introduction, we now describe the major advantages of OOP.

Generally, the advantages are-

• simplicity: software objects model real world objects, so the complexity is reduced and the program structure is very clear;
• modularity: each object forms a separate entity whose internal workings are decoupled from other parts of the system;
• modifiability: it is easy to make minor changes in the data representation or the procedures in an OO program. Changes inside a class do not affect any other part of a program, since the only public interface that the external world has to a class is through the use of methods;
• extensibility: adding new features or responding to changing operating environments can be solved by introducing a few new objects and modifying some existing ones;
• maintainability: objects can be maintained separately, making locating and fixing problems easier;
• re-usability: objects can be reused in different programs.
• Provides a clear modular structure for programs. This makes it good for defining abstract datatypes, where implementation details are hidden and the unit has a clearly defined interface.
• Provides a good framework for code libraries, where supplied software components can be easily adapted and modified by the programmer. This is particularly useful for developing graphical user interfaces.
• Makes it easy to maintain and modify existing code, as new objects can be created with small differences to existing ones.
• The typical programmer’s advantages are-
  • Multiple-inheritance, where classes can inherit from multiple super classes.
  • Multi-method dispatch, where operations can be specialized not just on a single object, but on any of the arguments for the operation, or any combination of those arguments.
  • Method combination, in which the means by which several applicable operations to a particular set of arguments can be combined, is itself an object-oriented specification, definable by the programmer.
  • Operations that can specialize on particular instances of classes, rather than on just the broad class of the arguments.
  • shared class variables (slots, attributes) that are shared by all instances of a class, in addition to instance variables which are unique to each instance.
  • Specification of the creation operation for instances of a class as an object-oriented program, definable by the programmer.
  • The behaviour of operations on objects (methods) are themselves defined as first-class objects, which can be specialized by the programmer.
  • Access to classes themselves as first-class objects. The objects which define the behaviour of classes are themselves classes, usable directly by the programmer.

Technically the advantages are-

Object oriented programming (OOP) is well suited to describe autonomous agents, so it should have appeal to scientists and modelers on that basis alone. However, that is not the end of the subject. OOP it has virtues that are equally important to computer programmers. OOP, as it is found in Objective-C, is not exactly the same as OOP in C++ or Java, but these languages have some significant features in common. The features we emphasize here are encapsulation and inheritance.

● Focusing on Encapsulation This has both substantive and practical implications. The substantive importance is that the representation of an individual actor now presumes that the actor is a self-contained entity and that other actors do not automatically have access to all information inside that actor. Like humans, objects have to take effort to convey information to each other about their internal states. The practical advantages of encapsulation, however, are just as important. Computer projects can be broken down into separable components (code for the classes) and when the code is finished, the details of what goes on inside each object may not be important to the programmer. For example, if an object ‘groceryStore’ can respond to an message ‘takeMoney’, and it gets the job done, we might not care how it does it. This is commonly referred to as the separation of "interface" from "implementation." While the interface declares what methods the object can execute, the implementation may remain hidden; the user only has to be familiar with the interface of an object, not its implementation.

● Focusing on Inheritance: Inheritance works because code for each class designates that class as a subclass of a super class. For example, in the GNU Objective-C compiler used in the Swarm project, there is a most basic class, "object". From the object class, the Swarm libraries create subclasses, and subclasses are created from them, and so forth until the programmer in a swarm project wants to create a new class of actors that is sub classed from Swarm Object. If the programmer needs to create several varieties of that class, there is no need to totally rewrite each one. Subclasses can be created that have as a base all variables and methods of the class but then new methods and variables can be added as well.

When a method, say takeMoney, exists in a class Store, and then a subclass is created, say GroceryStore, then all objects instantiated from the subclass will respond to takeMoney. If the programmer wants to rewrite the takeMoney method for GroceryStores, however, then the method can be revised inside the code for the subclass and then all instances of the GroceryStore class will respond to takeMoney in that specialized way. The method inside the GroceryStore subclass will override the super-class's definition of the method.

Drawbacks!

Ok, now the criticism are-

● Much of it is a philosophy. But, the OOP philosophy is not always the best philosophy for many types of applications (See "OOP's Niche" above). Also a language philosophy dictates the built-in functions and operations provided. If neither the syntax nor the built-in functions are optimized for what you are working on, then you are wasting a lot of time.

● There are some studies that show that OOP only pays off if a programming project is "well-managed". There are also a few studies that show that even non-OOP COBOL projects can achieve the same famous "code reuse" and "flexibility" goals that OOP lays claim to if managed properly. Thus, OOP's goals may be achievable simply through commitment to certain goals, and OO languages are not a prerequisite. However, let's continue assuming OOP is unique.

Studies show that most OOP projects do not really achieve the goals (improvements) of the OOP promise because all parties have to buy into the proper methodologies. These parties include programmers, project managers, and top level managers. Since code reuse and added flexibility often come only after a few years, many are unwilling to follow the process correctly. Using OOP and OOD (Object Oriented Design) often slows down progress in the first few years. If done right, OOP works as a long-term investment; it is not an instant results tool even according to OOP experts and proponents.

● Instance (or shared class) variables of an object can be accessed by class-specialized functions, and called the same way as any other function.

● Look through the graph below. For simple or easy (even for semi hard) programs, procedural approach can be a good solution. But for the hard ones it is not. On the other hand for simple problems, approaching OOP concept is rather lengthy, time consuming and not useful. It is however, useful for tough problems. 

Figure: A (2)

● Some argue that OOP is still important even if not dealing directly with GUI's. In my opinion, much of the hype about OOP is faddish OOP in itself does NOT allow programs to do things that they could not do before. OOP is more of a program organizational philosophy rather than a set of new external solutions or operations.

The OOP organizational philosophy allegedly makes software more change friendly It is also often claimed that OOP makes software more reusable, bringing less re-invention of the same software wheels. However reuse claims have lost steam of late, putting change-friendly at the top claim spot. (Individuals' brag-lists may vary.)

● However, there is a slight cost in terms of efficiency. As objects are normally referenced by pointers, with memory allocated dynamically, there is a small space overhead to store the pointers, and a small speed overhead to find space on the heap (at run-time) to store the objects. For dynamic methods there is an additional small time penalty, as the method to choose is found at run time, by searching through the object hierarchy (using the class precedence list for the object). These days, these efficiency penalties seem to be of relatively little importance compared with the software engineering benefits.

● OOP is not a new solution for unsolved problems, but only a theory (active theory ofcourse) acting to have better solution for tough programs.

Page-8

<- Previous Page Next Page ->