5

I have read in some tutorials that one of the differences between procedural programming and OOP is that OOP allows you to make member variables private, while in procedural programming you can't make member variables private.

I have also read in other tutorials that allowing making member variables private is not considered a feature of OOP.

So what is the correct answer, is allowing making member variables private considered a feature of OOP or not?

14
  • 2
    wonder if you are aware of static modifier in procedural language C
    – gnat
    Oct 14, 2020 at 10:27
  • 3
    Can you define what you mean by private, please? It means different things in different languages, and there is no universally-agreed-upon definition, so without a clear and precise definition from you, the question is meaningless. Also, can you define what you mean by "member variable" in the context of procedural programming? In OO, we talk about members of an object, but in procedural programming, what would the variables be a member of? Oct 14, 2020 at 18:55
  • 3
    Otherwise, the answer is basically "You can define any of those words to produce any answer you want". Oct 14, 2020 at 18:57
  • 3
    @IMSoP: "The OP has seen conflicting definitions, and is asking us which is correct." – Since the OP is not providing those conflicting definitions, your proposed modified question which definition is correct can unfortunately not be answered. Oct 15, 2020 at 9:09
  • 2
    @IMSoP: As of the writing of this comment, this question has attracted 9 answers plus some comments on the question, plus some comments on those answers, and I see somewhere around 5-7 mutually incompatible definitions of those terms on this page, but none of those definitions are relevant to the question. What is relevant to the question are the definitions in the tutorials the OP read, which we don't know what they are. I have a personal opinion about what the correct answer is, and maybe I will write this down, but all that is going to achieve is add yet another incompatible definition Oct 15, 2020 at 13:56

9 Answers 9

5

There are three major features in object-oriented programming that makes them different than non-OOP languages: encapsulation, inheritance and polymorphism.
pcmag.com: object-oriented-programming

What you're hitting on is encapsulation. Access modifiers, like private, are one way to enable encapsulation. Here's another:

var add = (function () {
  var counter = 0;
  return function () {counter += 1; return counter}
})();

w3schools.com - function closures

This closure fully encapsulates the counter var without using any access modifiers. This is functional programming not OOP. So it's unfair to consider encapsulation strictly an OOP feature. Access modifiers simply happen to be the popular way to encapsulate in the OOP leaning languages.

As any decent Python programmer will tell you a simple underscore at the start of a var name can signal that you're poking around in private data. Oh it's not language enforced. It's a convention. But we're all adults here right?

So, "Is allowing making member variables private considered a feature of OOP?" Yes. But it's a feature of far more than just OOP.

2

Having private variables (regardless of language specific keyword) is not specific to OO. A lot of procedural languages allow access control at the level of a module.

Having member variables is not specific to OO. A lot of languages allow to define composite data structures.

But combining the two, having private member variables, makes sense only if you have operations related to the data structure with privileged access. So it’s not a feature of OOP, but a symptom.

In fact, treating members as objects, using only their defined interface, and applying consistently privacy not only to members, but also to members of members, members of members of members, is one of the core feature of OOP, called object composition.

1

No, private is not a feature of OOP, but a feature of the language you are using.

Python is the proof that this is true, which does not have private, but has conventions about naming member variables. Which is still perfectly fine for OOP.

0

Sounds like a "no true scotsman" argument.

private helps you enforce encapsulation of your data in objects.

encapsulation of data is part of OOP

1
0

Having something be “private” means some can access it and others can’t. Who can and can’t access it either depends on context, or must be written down explicitly.

In OOP, we have a context when “private” is used in a class: members of the class can access it, others can’t. A non-OOP language like C would have a problem. A struct can only have data members, and data members cannot access anything. But “private” with a friend declaration would work just fine in C, showing that “private” can be used without OOP.

Encapsulation is also useful without OOP.

1
  • 3
    "A non-OOP language like C would have a problem." Not really. private is OOP's crutch for needing to expose API data to a runtime system or compiler, while trying to keep the rest of the world from coupling to it. In C, you never had this problem to solve. If you wanted to keep an implementation detail private, you just kept it in .c file, but didn't add it to the .h header. It's stronger than just private: not only can people not call things not in the header, if your library is closed source, they don't even know it exists, at all.
    – Alexander
    Oct 14, 2020 at 15:42
0

Marking things as private is a common part of implementing OOP, or even more correctly facilitating it, rather than a feature of the paradigm.

What OOP says is that there should be something - an "object" - that responds to messages and keeps its internal state hidden (encapsulated) from the rest of the program. A common implementation of that is to have objects be instantiated from some class which has "public methods" (the way of handling "messages" from other parts of the program) and "private members" (the encapsulated state of the object).

So it's true to say that many current "OO languages" allow you to mark members as private; but this is just one way to help you write object-oriented code, which is actually a style of programming rather than a description of any set of language features.

You can achieve the same thing in any language by using naming conventions, module scopes, and whatever other facilities the language offers, to mark which state belongs to which object, and which code should respond to messages sent to that object. For instance, if you define a C struct, and a set of functions that take an instance of that struct and manipulate it in opaque ways, that can be considered "object-oriented", as long as you don't also write code that manipulates the struct directly. The language is not enforcing encapsulation, only your own coding conventions.

0

private is needed mainly in OO languages that want or need the user of a class to have some, but not full knowledge of the implementation.

In C++ it is possible to create objects on the stack. To do so, the calling context needs to know the size of the object, which is (related to) the sum of the size of its members, including private ones.

For optimization, it is also desirable to have inline methods that have access to private members, which also makes it necessary to expose all members inside the public-facing header file, even if they are meant to be inaccessible.

If you allow creation on the heap through a factory method and access through abstract interfaces only, then the user of the class has no need to know the internals, and you could work without access modifiers.

That is still object oriented programming, and in many cases a lot cleaner, but it also has a bit of extra overhead because you need to separate interface and implementation declarations, and any access to the object needs to go through the full dynamic dispatch (which can be costly if you are e.g. sorting an array of objects by the value of a base class data member).

COM is a good example of this: interfaces are defined in IDL files, and the actual implementation is completely hidden. When done correctly, access modifiers can be used but are inconsequential because the only code that ever sees a list of member variables will be member methods.

0

A procedural language has only access to a field / data member from the outside. But access from outside implies public.

struct X { int x; };

void f(struct X s) { s.x = 42; }

That might be the entire argument: OOP can utilize hidden fields. Valid, but a bit dubious.

2
  • 1
    You could have private + friend for non-public access.
    – gnasher729
    Oct 14, 2020 at 13:03
  • @gnasher729 that was my thought also, hence my mark that it is a bit dubious argument. On the other hand, "friend" might be considered a C++ specific code smell, or at least an added non-core feature. And a namespace/function friend (non-OOP) is rather special. I think that a professor might be concgratulating himself on finding such a distinction between OOP and procedural languages. Corner cases not considered.
    – Joop Eggen
    Oct 14, 2020 at 14:23
-1

OO, like every other paradigm, is a way of thinking about the structure of a program, and doesn't prescribe or mandate the use of any particular programming language features.

Rather than trying to think about OO in terms of programming language features, it could be more useful to consider OO as a set of guidelines/principles and advice on how to separate the behaviour of a program into logically-related groupings of functions and data, with the goal of making code easier to reason about, easier to reuse, easier to unit test, etc.

While it's understandably common (and easier) for a lot of textbooks and courses to explain OO in terms of language syntax, too much focus on language features can distract from the big-picture about program structure. Indeed, features such as private exist as a tool to encourage OO practice but aren't necessary to enable it; they're also no guarantee that the resulting design will necessarily adhere to OO principles.

For example, a program which excessively violates the Tell, Don't Ask principle or uses God Objects could end up lacking any kind of appropriate logical structure, and probably wouldn't be considered as 'Object Oriented' regardless of the use of classes and private variables.

1
  • @Downvoter - any feedback you could provide would be really useful to help improve the quality of the answer and this site for everyone Oct 15, 2020 at 11:56

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.