30
What is the correct term for a fully object-based language (C#), and a language that uses objects but is not completely based on them.
Example: VB has (had) several functions that were not in objects, and a support (limited) to OOP. I think C++ is also like that. There are certain terms for it?
I remember seeing this difference in classification (between languages Object-enabled [VB] and object-based languages [C#]), but not where - nor what the specific terms were.
36
Alert: I’m going to make some simplifications and I’m not going to follow the strictly academic definition, let alone a universal definition - if there is a. I will talk about what every programmer should know whether or not to like the theory. And if I’m wrong (and not just simplified), correct me.
I don’t know what it is. Nobody knows. Everyone says they know and others are wrong. I’ll tell you what I think.
The closest thing to something canonical is the ISO/IEC 2382:2015, item 2122503, but it’s something very weak.
There is confusion about several terms. And you need to look at the context to know how to define. You cannot give a definition without knowing exactly what you are talking about. You run the risk of giving the right answer to the wrong question. So let’s go in pieces.
Obviously I won’t talk about object outside the context of software development.
The object is a data set somewhere. This data can be simple or complex. It has a more complete answer in In programming, what is an object?.
Within a code of a program the objects are represented by a memory position and most often associated with identifiers, which we call variables or constants. There are objects in other contexts with other characteristics.
I won’t go into detail on the various forms that these objects can be built but obviously they have byte(s) which indicate a basic information understood by the processor or may be a set of data on a more abstract level that have a direct relation and were grouped for some specific purpose, forming another data.
We can say that all programming languages work with objects. Some practically do not use this term in their users' culture, others use it in specific situations and others use it with a special meaning.
It is more common to refer to an object as a complex data structure, usually represented by a struct (each language has its syntax) or even a class. When we define this structure we are creating a plant for the object.
In general the idea of class arises when placing behaviors (functions) together with state (variables). It’s a simplification of what a class really is, but it’s understandable like this.
Note that, in fact, an object does not have behaviors (at least not in most languages we know). The owner of the behavior is the class. The object is an instance of the class and the instance accesses the predefined behaviors. Each language has its own way of accessing.
Remember that some languages do not work with classes in the definition that everyone knows. They use some other mechanism that offers similar result. One of them is the prototype, which is nothing more than an object being used as a template to create others. In general the behavior is associated in some way, but it is hardly part of the object directly (I have seen language that does this, but it must be the reason why it is not successful :)).
We know, it is true, that some languages treat behaviors (functions) as if they were objects. It is still another way to use the term.
And then we come to object-oriented languages. And we have a somewhat controversial terminology. The only sure thing is that these languages need to facilitate object-oriented modeling, no matter how this is defined.
First, it is good to understand that the fact that a language has classes or some construction that functions as if it were one, does not mean that the language is object oriented. It’s usually like this, but she just doesn’t define it.
Another point that is used to define whether the language is OO or not is where the object is used in the syntax. Prioritizing the object when calling behaviors sometimes helps to understand language as object-oriented. Then having the object, the expression that generates the object, or the variable that "stores" the object as the first element of a syntax that will then define what will be done with the object helps to say that a language is object oriented. But we have situations that we call behavior and pass the object as a secondary act of syntax.
obj.Comportamento(); // OOP
Comportamento(obj); // não OOP
It’s not enough to have a data structure that puts behaviors close to you to say that there is an object orientation. This is somewhat reminiscent of encapsulation (not only this), which is one of the characteristics of object-oriented programming. But almost every programming language allows some form of encapsulation nowadays.
Even this can be questioned. In some languages the behavior is declared next to the data structure, but its definition is done outside. So the behavior is still close? Some will say yes and others will say no, depending on how you define what behavior really is, your intention or the actual implementation.
Although this and other characteristics, which I’m still going to mention, help define when a language is object oriented or not, we have to look at other things.
Of course, if we talk about encapsulation we should probably talk about the possibility of defining levels of access and visibility of parts of the object or its associated behaviors. Have a private in the language is the most visible part of what is encapsulation, but it is not the encapsulation itself is information Hiding.
Some will say that encapsulation is more than saying something is private in the class. And I even understand that to be true, but it doesn’t define whether the language is object-oriented or not. This definition will be given by a concrete characteristic of language. After all, encapsulating philosophically, every language allows.
Then we will look at the inheritance and this yes seems to me to be more defining if a language is object oriented or not. I remind you again that there are some ways to do this, and that some languages do not have classes, but they can take advantage of models of other objects to assemble their structure. At least this is exclusive to OOP.
Inheritance is responsible for the advantage that is most cited as argument of sale of the paradigm: code reuse.
Of course reuse can be obtained in other paradigms, but the way it is done in inheritance simplifies and organizes in a specific way (help in some points, hinders in others). Today due value is given to inheritance, that is, little. It is recommended prefer the composition.
When we use a extends or something with the same functionality, we are seeing the surface of what is heritage.
It is also often said that having a specific mechanism of polymorphism is necessary for language to be considered object-oriented. This is a feature that allows one object to replace another expected.
In "more object-oriented" languages this mechanism is very powerful and flexible. In others, for pragmatism, there are limitations.
It is common to have a virtual or another syntax (sometimes implicit) to indicate what may be polymorphic. But this only defines a mechanism. It is possible to do it manually, but only automatic mechanism would be considered for the language to have OO characteristic.
Manually you can do anything, even in Assembly. Other mechanisms can be adopted, among them parametric polymorphism using genericity.
Not all definitions speak of abstraction but it is common to say that a language is O only when it has this. And this term is a little more controversial because it is often obtained independently of the language to offer something specific. It has to do with the model.
Abstraction is often obtained by the simple fact of how to assemble the program. Abstraction can be considered as the act of transforming real-world elements into code.
And there is a great danger, and so many people program wrong and abuse OOP. It is common to look at a real-world object and want to reproduce it in the code. In general it is not possible. You can only create an abstraction of what the real object is. You don’t build people in the code, just an object that represents a person. It seems obvious, but programmers are always trying to build people. That’s why it’s easier to use OOP in games and GUI. The domain already works with well-defined abstractions.
Some languages have specific mechanisms that reduce complexity and help to better express the object. But not all are OO. abstract or interface is just a tip and does not really define what abstraction is. Therefore the term applies more to modeling than to language.
Some say that the other features above and below already give the necessary abstraction.
There is also talk of operator overload. This is in some languages considered OO but not all. Even in these, the implementation is usually limited. So some people consider that this is not fundamental for the language to be considered OO.
There are some other definitions, or at least details of these presented definitions, that will determine whether a language is object oriented or not.
If you take everything to iron and fire, as defined by who created the term, only Smalltalk is really object-oriented. Of course it’s a bit of an exaggeration. What I mean is that the initial definition of the term does not take into account those things that were shown above. At least not in this way.
In fact I do not know (does not mean that there is not) another language that is purely object oriented. Ok, Common Lisp and Self also. The languages we know as OO are actually multi-paradigm. Not least because it’s something more pragmatic. Pure things usually have little space to solve "real problems", although this does not mean that the language is not good and can not solve any problem that other languages solve.
Alan Kay himself said that Lisp is more OO than Smalltalk. Well, Lisp is anything else, it’s an open language that can be anything, so "nobody" uses.
In fact even Smalltalk has something imperative, pure even doesn’t exist. It’s like water, there’s always some extra stuff in the water, it’s never just H2The.
Even the definition than is purely object-oriented seems to be controversial. Each ensures that its definition is the right one. It is almost religious.
People say they use OOP for easy maintenance. Great reason. But each has their own way of seeing how to do it.
There is a chain that preaches that everything related to the object must be close to it. Others say that everything must be more separate. Each understands it as he wants. And says that others misunderstand.
Those who carry the encapsulation by iron and fire do not improve the maintenance. Since the beginnings what facilitates the work is divide and conquer and not to group. Division facilitates the creation and change of the code. It should only be together what is indivisible, which is the same thing.
Obviously there are those who divide too much and there are those who gather too much. This is almost an art. It is similar to text interpretation. Everyone can interpret as they please, but what the text actually says is that it matters.
I see some people who think they own the truth in this subject that shape things coupled and non-cohesive "because OOP is like that".
Others preach the most separate form, and what they actually do is modularization, even if they call it OOP. I don’t trust anyone who can’t even adopt a correct definition, who invents a new term for what already exists.
Although I disagree with the way they do, modularization is fundamental to improve code maintenance.
If people understand well what is DRY probably doesn’t need anything else. This simplifies maintenance, joins what should be together and separates what should be separated. What matters is to have a canonical form of something. This makes maintenance easy. See also What are the concepts of cohesion and coupling?.
Of course there will always be disagreement between what is divisible and what is not. An example I use a lot:
There are those who think that a customer or a supplier should have everything that relates to this, that is to say they should have all the data of the entity that performs this role. To me these are papers that people can exercise, are very different things. When you do this you have two objects that represent the same person. It’s very wrong. This engages, removes cohesion and makes maintenance difficult.
When one understands how to divide things he realizes that the relational model is not so bad and that the classes may not have as much impedance with the database as they believe. And stop with the non-sense of use Nosql where it doesn’t fit.
To me, anyone who thinks that OOP is the opposite of modularization doesn’t really want easy maintenance. Anyone who thinks OOP is modularization should use the correct term. Who thinks that OOP is modularizing something else then should show it, I see no one doing. Who is only parrot does not deserve credibility.
Interestingly, most design patterns and SOLID itself preach things that go against what many say is OOP. I prefer these things to OOP. These things help maintenance if used where it should. But I think these things have to do with modularization.
Of course the term became known because other languages that were not so deep and began to have these characteristics additionally. Naming oxen, C++ was the language that made the term something "fashionable" (Simulates gave the idea of the OOP she uses).
By its original definition C++ is not an object-oriented language. Objects are not first class, not everything in language is an object, and there are mechanisms that subvert object orientation.
Note that C++ is an essentially imperative language with several other features, including OOP, functional, and meta-programming. The bulk of what is done in this language is imperative. Point.
It is not only in C++ that OOP is a secondary paradigm, is essentially in all languages.
In C++ functions or methods are not objects (today can even be). Classes are not objects. Several constructions are not objects.
Even when we only talk about types, not all kinds of data derive from one main type.
Here we come to another question. Every kind of language construction needs to be an object to be considered OO? Or every type of data must be derived from a major type called Object?
Then we start to get into the marketing. Some languages, not only C++, but also C#, Java, Ruby, and others, each in their own way, like to sell the idea that they are object oriented and each pulls the sardine to its side saying that it is OO because of this or that. And they try to disqualify the others. Of course, the small Smalltalk community does the same thing to everyone. This is because the "programmers" began to think that OO is the eighth wonder of the world, so all language "needs" to be OO. Only a minority understand that it is only plus a tool.
Of course all these languages are object-oriented. In part. None of them has all constructions as an object. "None" has messaging as originally set. I could find a lot of things that show that these languages are not object-oriented. But almost everyone says they are. People are adapting the definition so that they fit. Of course, most people repeat what they’ve heard without question.
C++ and Java even have all types derived from a single type. C# and Ruby have this (I’m only getting these examples but other languages could be cited). Hence the expression "everything is object". Some understand you’re talking about the type Object. Others, few, understand that it’s all the same, not just data types. There are controversies whether it is necessary for all types to derive from the same type to be object-oriented.
And many consider C++ and Java as the best examples of OO languages. You will say that they are wrong. Better not, just accept that there’s some truth to it, even if they have no idea what they’re talking about.
One can program OO in C but language doesn’t help. So C is not an OO language. But any language can be used to program on top of an object-oriented model, up to Assembly.
The fact that language allows other paradigms only indicates that it is not pure.
The fight to know which language is more object oriented is a big waste of time.
And languages are getting more and more Features that make the code escape from OO.
So you could say that every language has object support, even the most archaic. Some allow creating or simulating classes, so some languages find themselves more entitled to say that they are object-oriented when they are not.
Some have their own mechanisms that facilitate and encourage encapsulation, inheritance and polymorphism, and are roughly object-oriented.
And there are still little known languages that are purely object-oriented. They follow all the precepts of the paradigm and do not use other paradigms to facilitate what this paradigm does not work well (although even this can be questioned).
In fact the conclusion of the AP in his answer is correct and in this case should not be too attached to the terms, it is not worth wanting to impose a definition and see what is or is not. As long as it does not harm the use or communication of programmers, let’s accept the term that the community of each language uses within its context. Questioning is important, but it is not worth more effort to impose a definition.
Already in the question has some information that is not proven.
But make no mistake, most programmers go to most of the time working on imperative code with object-oriented features and that perhaps the general structure of the application has been modeled using this paradigm. Perhaps the design has been object oriented. And generally more modularize than do OO.
It is good to remember that the term was created at a time that many seriously believed existed silver bullet, that artificial intelligence would solve everything, and that the world of software development would be an automated day where users would program their own needs. The good part is that they fell into reality and from all that remained some useful things that apply to the actual process of software development.
And also make no mistake, all paradigms exhibit their problems. Choosing a paradigm is choosing what kind of problem in software development you want to deal with. There is no better paradigm. There are some better fit in every type of work, and that a person or team handles it better.
Of course people tend to choose one and try to solve everything with it. Or at least two, since most people think that programs are purely object-oriented but always use the imperative as well. And then it’s complicated because if people use one paradigm and they don’t even know, they probably use the other one the wrong way and they don’t know either. By the way, it has become commonplace to always say that the other does not know how to use OOP. I don’t even know, but at least I know it :P
The Wikipedia page linked in the AP response helps understand, but there are many simplifications that help perpetuate some myths. That’s why I started making an alert. In the English version that has more information is even worse, because it buys other myths, such as which languages are object-oriented. The article buys the marketing.
In the ideal world it should have more terms to accommodate every definition of what they say is object orientation.
Good terms are those that are universally accepted, that survive time and that are easily explained.
That’s why I get the fundamentals, the simplicity, what’s proven to work.
And I accept the idea that any tool used the right way works and all used wrong serves for nothing.
When people don’t even know what the tool is they can’t use right.
Additional reading:
Having feedback, I improve
3
Here we can see the terms for the two classifications, as well as an explanation: Object orientation
Languages object-oriented use objects internally to represent the elements that constitute the platform itself (variables, methods, environment).
In languages oriented to pure objects, everything in language is an object.
Languages object-supported allow the use of object, to a greater or lesser degree (with or without inheritance, for example), but exposes a part or all of its functionality without encapsulating it in objects.
For example VBA, which allows use of objects, but exposes several functions without encapsulating in objects (Instr(), Mid(), etc.). The basic types are also not objects.
I do not know if there is a precise line that delimits each concept, possibly it is more qualitative.
Browser other questions tagged oop terminology
You are not signed in. Login or sign up in order to post.