3 ms·
I'm in some programming class in france. The teacher argued that OOP and encapsulation makes programs more secure. It really felt like a political statement. T
by jokoon 12y ago
I'm in some programming class in france. The teacher argued that OOP and encapsulation makes programs more secure. It really felt like a political statement.
The day I understood that class and struct are merely the same thing, I questionned the purpose of private: and public:.
To be honest, I think the sole purpose of those construct is just to hide proprietary code when you sell libraries and deliver a set of binaries and headers, to force the compiler to forbid you from writing to, or using protected member. It's really moot. It's just a coding practice, it's not some grand way to think and construct applications.
OOP is nice if you want to create some non standard simple type, like Vec3, or when you want to use an interface for something quite complex. Templates are a good extension of OOP, but it's not used that much, even while the STL justifies the existence of templates. But other than that, when you want to make an end-user application which is not a library, I think OOP is not that much useful. Too few programmers write libraries, most just write applications, and applications don't need OOP.
If you use OOP to pretend that your code is reusable, please, first check if what you're making really is worth reusing, chances are it's not.
TL;DR: OOP is good to design bricks. Most coders are not brick designers, thus most programmers should not touch OOP that much.
- aosmith 12y agoIf you're using public and private for security you've missed the point. The idea is to help other developers use your code correctly by only exposing the methods they should use, instead of everything.
- alkonaut 12y agoPublic and private has nothing at all to do with hiding proprietary code. Encapsulation is important regardless of whether you use OOP or not. Even if you program something alone that will never be derived/re-used, you should strive to have clean boundaries between subsystems. You also want to make things read-only unless they should change (most things should not) If you make everything public and writable you have to spend a lot of thought on things that a compiler could help you with so you can focus on solving the problem. Much like using a type system.
- aikah 12y ago> I'm in some programming class in france. The teacher argued that OOP and encapsulation makes programs more secure. It really felt like a political statement. Really depends on what he meant by secure.I'm french too.Encapsulation isnt about shipping proprietary binaries.You dont need OOP for that,furthermore,almost anything can be decompiled so your point is moot. You'll understand when you work with a team,you'll understand the value of encapsulation, and forcing every developper to work with well defined interfaces that cannot be violated.Encapsulation makes communication easier,testing easer,it makes everything easier. > Templates are a good extension of OOP, but it's not used that much, even while the STL justifies the existence of templates. I would argue templates have little to do with OOP.It's a tool that allows genericity.You could have generics in a non OO language. > It's just a coding practice, it's not some grand way to think and construct applications. No it's a feature not a practice.The alternative is ugly stuff like in javascript where you put _ before prototype methods to express an intent. So much that ES6 comes with symbols because it shouldnt be just an intent.A developper should be able to express what he means,no just an intent(still possible in ES5,with priviledge methods but noT compatible with prototypal inheritance). OOP is a tool,encapsulation is one of the most important things in OOP.Wether a language implement explicit encapsulation or not is of course an implementation detail.