Should object-oriented principles be applied in procedural languages?
Asked Answered
D

2

6

I know that it's possible in principle to turn even procedural languages such as C or MATLAB into object-oriented ones. This question has been fairly well discussed here and here.

What I found missing from these discussions and the references therein was an exposition on whether one should apply such principles. Is there anything concrete to be gained from doing so? It's clearly possible, but is it advisable to do so? Are there any examples among open-source projects where this practice led to clear advantages?

CLARIFICATION

Perhaps an example is in order.

I've inherited some MATLAB code that implements some machine-learning algorithm. There's basically a single function building_model that, depending on a flag being passed, will either train a model or use it to predict a future value:

building_model('train', ...) % ... stands for the data with which the model is trained

and

value = building_model('predict')

The model itself is implemented with MATLAB persistent variables inside building_model.

I've torn apart building_model into two functions, one for training and one for predicting. The model that used to be implemented as persistent variables is now externalized, so to speak:

model = new_model()
model = model_train(model, ...)
prediction = model_predict(model)

This is, roughly speaking, as far as I could manage emulating some features of OOP in MATLAB. My building model module now acts pretty much like a class, with a constructor and two methods model_train and model_predict. I've achieved some degree of encapsulation (though nothing prevents the caller from fiddling with the internals of model), and polymorphism could in principle also be accommodated. As an extra bonus, I get Command/Query separation almost for free since model_predict doesn't return model, and thus may not alter model.

(Astute readers will point out that MATLAB already has an object-oriented system. For various reasons, including performance and compatibility with older versions, I cannot use it.)

I could imagine a similar mechanism in C where you would design some data structure and write functions whose first argument would be an instance of that data structure.

What I'd like to know is, how far can I push this way of programming? Is this a commonly accepted pattern (there, I've said the word)? Are there any performance issues I should watch out for?

Dilution answered 21/1, 2011 at 13:49 Comment(1)
That's something often missing from discussions about object-oriented practices in general. You still have to decide if OOP is the right design, whether it's built into the language or simply a design methodology you try to adopt without any help from the language. The same advantages (and disadvantages) apply either way.Covarrubias
C
2

I think this is a really important discussion. I think it is safe to say, that OOP isn't always the best solution in all languages. In e.g. C++ or Python, OOP is usually the natural way to e.g. encapsulate data. Those languages are designed to focus on classes. In other languages, it may be easier to create good quality code in other ways.

I think Common Lisp is a good example. It has a really good OOP system (CLOS) that I would say is really complete. But still, OOP is not used nearly as much in Common Lisp as in Python or C++, since it is a convenience feature rather than something that is needed to provide basic software engineering building blocks.

Whether you should use OOP or not really depends on the problem you are trying to solve. For one example, I think GUI stuff can be really useful to tackle with OOP.

Cyanogen answered 21/1, 2011 at 15:8 Comment(1)
+1 "I think GUI stuff can be really useful to tackle with OOP.". This is how Dr. Stroustrup introduces OOP to his students.Incessant
S
-1

Object orientation is the a means for achieving software engineering goals.

Goal: Ease of maintenance, Extensibility, Organized source code (searchability etc.)
OO Construct: Encapsulation (only methods owned by the 'data type/structure' can operate on its data)

Goal: Ability to develop new features without modifying existing ones, Code reuse
OO Construct: Implementation inheritance, Polymorphism

Goal: Abstractions (you don't have to commit to a particular type or operations, change of implementation without changing the clients)
OO Construct: Interface inheritance, interfaces, abstract classes

The goals don't need justification. Whether you want/need the support of an OO language or not is depend on your particular situation. If you need to use C you can still mimic some OO construct, and hopefully enjoy the benefits of it.

Mind you, there is absolutely possible to develop a bigg mess of code with adhering to all of the OO principles.

I'm sure others can list other goals and examples (and know how to edit tables in stackoverflow posts)

Selfwinding answered 21/1, 2011 at 14:30 Comment(1)
I really disagree to that OO is the means for achieving the goals above. All this was really possible before the invention of OO.Cyanogen

© 2022 - 2024 — McMap. All rights reserved.