When is an object oriented program truly object oriented?

Question

Let me try to explain what I mean:

Say, I present a list of objects and I need to get back a selected object by a user. The following are the classes I can think of right now:

ListViewer

Item

App [Calling class]

In case of a GUI application, usually click on a particular item is selection of the item and in case of a command line, some input, say an integer representing that item. Let us go with command line application here.

A function lists all the items and waits for the choice of object, an integer. So here, I get the choice, is choice going to conceived as an object? And based on the choice, return back the object in the list.

Does writing this program like the way explained above make it truly object oriented? If yes, how? If not, why?

Or is the question itself wrong and I shouldn't be thinking along those lines?

Answer 1

I don't think one can give a definitive answer, because there is significant debate nowadays about what Object Oriented design actually is. I will try to outline somewhat of a consensus below, and point out where my own opinion dissents.

Established OOP has its roots in studies in the early 1970s discussing principles, methods & patterns for dealing with complex code - such as the principle of Separations of Concerns (Dijkstra) (while aware that Smalltalk was around before that, I believe that this particular leap in theoretical understanding stands at the foundation of today's OOP). In pure object-oriented design, each type of object (class) should represent a singular/atomic idiom qualifying a relevant aspect of your solution, because OOP is an orthodox practical implementation of SoC theory. Therefore, as a generic rule of thumb, if you are describing a solution, and can drill down the use-case to words which are specific enough such that they can't be broken down further (as per SoC) while still being directly relevant to your solution, they will usually correspond in some way to your classes.

It is difficult to give an example to this based on your question (it is too vague), but App isn't usually a type of object (because it can usually be broken down in features and aspects), while list item may be a type of object (a UI element representing one component of the model). The click event, going from your UI to your model, is in somewhat of a gray area: you may choose to represent it as an object (ex. an implementation of the Command pattern) if it is handled in a way specific to your application (i.e. lifecycle - triggering and consuming, not necessarily its implementation), but most of the times it is generic enough to be a language idiom.

Going further, there are several principles and stereotypes which people have identified as good practice when pursuing object-oriented design, which are actually the living definition of the concept. The theoretical basics are abstraction, encapsulation and polymorphism (another personal opinion: inheritance, is not a first-class citizen, for theoretical reasons - it is actually a kind of subtype polymorphism, and for practical reasons - I'm with the GoF here, favor composition). Consequently, when designing your objects, try to consider the application of these principles, because in an overwhelming majority of cases they will lead to what most people consider OOP.

A lot more can be derived starting from the above: unlike modules, objects are small and many (stricter observation of encapsulation and abstraction). Because they are so, the structural relationships between objects become more important, therefore one needs to consider design patterns more carefully than in modular design. Also, since objects have smaller, well defined areas of responsibility within the context of your solution, their life cycle will not usually coincide with the life cycle of your application, therefore, their creation and destruction becomes a design problem. Even more so, since you now have many objects covering the same responsibility as a large module, you really need to consider how they communicate while observing SoC, hence it is important to design with decoupled interface contracts, otherwise the objects will end up exposing too much of their state to their peers.

Programming languages supporting modern OOP will give you an even wider array of tools - which are themselves derived as implementations of the theoretical principles above: they will have features which support the basic "tenets" (ex. some form of interface, some form of enforcing encapsulation), features which separate vertical concerns (your solution's implementation, from abstract to specific) from horizontal concerns (aspects & policy applicable to all features - life cycle, object persistence), features reconciling the simplicity of linear control flow with the granularity of OOP design (exception handling, task parallelism, lambdas). Using correctly, and maybe even mastering a powerful language which was designed with OOP in mind (such as Java, C# or maybe even C++ - the latter with a lot of protest including from yours truly) is a great way to gain good insight into how to drive your designs.

Finally, OOP applied to the letter may indeed be too orthodox for practical purposes, therefore always consider the hows and whys (I think a good consensus between answers to this question will be to take everything with a grain of salt). OOP is a vehicle, not a purpose in itself, always put your solution's restrictions before theory - maybe even with a YAGNI approach.

Answer 2

Nobody can tell you what "truly object-orientated" is. That's like asking for the true religion.

And there is nothing wrong with your sample program. Do you need an Index type? Well, probably not. There's no reason to over-complicate things here.

Answer 3

Good question. I have personally considered this and have watched dogmatic colleagues struggle with a notion of strict adherence to methodology.

My answer is: It is a balance. This is true, especially in Front-End Systems and most UI. Here is why:

In C, C++, and Java Object-Oriented methodology is a best-practice because the three tenets of OO can be defined clearly in code. That is to say, Inheritance, Polymorphism, and Abstraction improve maintenance, reuse, and extensibility.

Enter JavaScript and we have opened a can of worms. This is because JavaScript can be more expressive without the three tenets. This is for a myriad of reasons but the prime one being JS is object-oriented with objects only; no classes. So there is a simplification in practice.

Attempting to force classical inheritance into that environment, in short, can result in added complexity, not reduced complexity. Designing constructs such as private members can be added maintenance.

That said, let me answer your questions in succession:

Is the choice an object?

-> It can be, but it depends. Should it be reusable? Can it contain behavior or other member variables? In JavaScript, it is an object... always. So this is potentially something of minimal concern.

Is it truly object-oriented?

My perspective is that this is boils down to a matter of opinion, how 'true' the methodology is implemented. There is, perhaps, always a way to refactor something to more closely match a paradigm. So again, to me, this can potentially be of minimal concern. I'll explain why in a moment.

Is the question wrong, and is there another approach?

Correct sir. There are other approaches. Object-Oriented Design is a good idea when it is a good fit with implementation. If you are writing your GUI interface in Qt C++, then by all means, yes it is a good fit. In Java, yes, inherit. However, if you are following a new Windows 8 Metro JavaScript approach, there are a number of topics for consideration.

Another approach.

My suggestion for consideration would be for Design Patterns. Why? Because they are a set of designed patterns to commonly solved problems. The notable achievement here is that this knowledge is highly transferable across language. Implementation is then follows suit of the pattern.

Design Pattern Example.

So, as an alternative to applying scrutiny on implementation, one can take a step back and review the overall design. For example, not-is it truly object oriented, but- do we desire a master-detail pattern, a double-list, or.. etc.

By defining the Design Pattern, implementation becomes self-evident. Sometimes it will be pure Object-Oriented Design, sometimes it will be a higher level Design Pattern.

Thus, it is a balance of implementation in practice and design methodology.

Here is a link, and link.

My humble advice is to understand the 3 tenets, the Design Patterns, and then to flexibly craft the best-fit (maintainable, reusable, extensible, etc.) into each given environment.

Answer 4

Looking at your example I think that you can be ok with the choice being non-object, but imagine your program become more complex, for example you could introduce undo/history or your layout can start support a tree instead of a linear list so at some point you can consider making the item of choice an object and probably the subject to future inheritance. This is because maitaining such complexity would become too difficult.

So your "oop rate" should not be the result of purism or theoretical requirements, but the consequence of your program becoming more complex.

Answer 5

To Answer this question...let us go step-by-step

Firstly, what is the program flow? Following is a proposed flow:

1. Map the possible user_inputs to the items-to-be-displayed
2. Display the list of items and the corresponding options for the user
3. Accept user_input
4. locate the item that matched the user_input and return that to the calling program.

If an object oriented approach is to be followed the fundamental rule is: Every User-Defined-Data-Type (Data structure) or Class (Type) should be manipulated or operated upon within the Class/Type scope. It shall not be operated upon from the outside!

Hence, You need to add two more classes to your existing Class/Type definitions - Option and OptionList. You program may look thus...(overview only)

App {
 ....
 ListViewer lv = new ListViewer();
 ....
 Item item = lv.getSelectedItem();

}

ListViewer {
private OptionsList optionsList;

public boolean addItem(Item item){ 
 ...
 optionsList.addOption(optionRef, item);
 ....
}
public int displayList(){ }

public Item getSelectedItem(){ }

}


OptionList {
 private Options[] options;
 public boolean addOption(ref, Item){ }
 public Option getSelectedOption(optionRef oRef){ }

}

Option {
 private int optionRef; /* Type based on what the user_input type is going to be*/
 private Item optionValue;

 public Item getValue(){ }

}

Now, why am I claiming that this Object Oriented? I could as well declare an array of Items in ListViewer and achieve the same thing. That is precisely the point, the items-Array in ListViewer would be a structure that is operated upon from the outside!

Further, the Type of "choice" in your question is determined by the kind of user_input.

I would like to put the above ideas in another way: A statement to add two numbers can be written in a number of ways, 1. sum = num1 + num2 2. sum = add(n1, n2) /* function oriented / 3. sum = num1.add(num2) / object oriented */

Finally, What different contributors have said about OO still stands. But, all that stems from the concept of the data structure (data) having the operations (programs) rather data and programs being viewed separately.

That simple paradigm shift... unifying data and programs into a new unit called "Class/Object" has given us so much agony and ecstasy:-)