In a paper that was to appear in the Encyclopedia of Microcomputers (Chenho Kung, 1991) defines object oriented programming as:

“The object-oriented (OO) paradigm is a new approach for software development. In this paradigm, the real world is viewed as consisting of autonomous, concurrent objects interacting with each other. Each object has its own states and behavior, resembling their counterparts in the real world.”

Quote 1, Chengo Kung, 1991

This twenty years old definition, which still very accurately defines the modern object oriented programming ideology, clearly emphasizes the technology’s unique perspective towards software units: as self contained objects, that have characteristics, state, and means to perform actions. One of the principle paradigms of the technology, encapsulation, explains how these elements fit together creating black box like items, which have very clearly defined interfaces to show to the public but which hide inside all the inner workings, that are not essential to see when the objects are used. By doing so, clutter is reduced, making the code easy to navigate, understand and used. Other paradigms like inheritance by ways of which objects can inherit capabilities and characteristics from more abstract objects greatly facilitates the reuse of code and its portability.

But the object oriented technology is not at all concerned with meaning. These objects that are supposed to mimic the real world objects, have in fact only marginal resemblance to their real counterparts. The paradigms of OO do not enforce at all any strictness with regards to reality but rather only the principles of modeling code in a certain type of way, which greatly increases coding efficiency.

  • Example 16, Encapsulation of state and behavior in object oriented programming
  • Book{
    	String title;
    	String author;
    	Date chekOutDate;
    	int durationDays;
    	String borrower;
    	// -----
    	void chekOut(String borrower, int durationDays);
    	void checkIn();
    	String getTitle();
    	…
    }
    
    Library{
    	Book[] books;
    	// -----
    	void checkOut(Book book, String borrower, int durationDays);
    }

 

The class Book in example: 16 encapsulates functionalities and attributes of a library book and it makes a lot of sense to endow it with the capability to check itself out from the library in the name of a borrower and even to store within, the details of the borrowing. Of course, in the real world, books don’t check themselves out of the library, such a thing is not within the capabilities of a real book and it would be severely counterproductive to store the details of the borrowing in the book itself, as they would be unavailable unless one actually had the book, which is not the case when one lends something. As such, it would make a lot more sense to endow the library with the capability to check out books but if we think about it for a second, this is not real either. Both approaches are just ways to abstract activities and group them so that they would be intuitive to use, portable and easy to reuse. It is really at the subjective opinion of a developer to decide which method is optimal for the given situation.

This is not to say that Object Oriented Programming and the object oriented model are not good, but just as well, it is a fallacy to consider that this efficient model of programming is suitable for every kind of information manipulation. Yet as pure object oriented programing languages are becoming more and more frequent, the boundary between objects that “do stuff” and objects that “describe stuff” has almost completely disappeared.

This blurring of the two aspects stems in the natural desire of developers to benefit from the various efficiencies object oriented programming offers for certain situation. Objects that “do stuff”, active object so to speak, perform their job by ways of methods, code encapsulated into their construction. This code, which can add up from thousands to millions of lines of code in an application has been the major focus of attention when it came to optimizing, for it represents the vast majority of the development effort. As such, any optimization in portability or re-usability brought considerable reductions in cost. By contrast, objects that “describe stuff”1 represent only a tiny fraction of the code. So small that we cannot even talk about optimizing this layer with regards to implementation time.

The problem with this approach is that lately portability of the types that “describe stuff” has become more and more important and the subjectivity of the developers and client needs, that are inherently embedded in these types by the OO model are in sharp contradiction with the need for their universal acceptance.

Another enormous impediment in information portability and freedom that is inherently built into the OO model is the way it models relations. The common practice in OO programing is to embed the relation, be that [1 – n], or [m – n] into the construction of the type itself. While this may bring some benefit in working with these objects from code portability it probably represents the apogee of inflexibility with regards to information portability:

  • Example 17, Relation representing books belonging to a library
  • Library{
    	...
    	List getBooks();
    	...
    }

If any new relation needs to be added to the type definition hierarchy, it requires changing the type itself, which in the best case requires modification of at least one type at source code level, recompilation, redeploy and restart of the application. As such, a type can never acquire universal acceptance because there will always be particular needs for particular relations, even if the type itself is universally standard. Such particularity keep types in the constant and total chaos of subjectivity.

  • 1, In OO, representing only the part of the type that defines the attributes of the object and none of the methods. The methods are part of what objects do.