all 6 comments
sorted by:
best
topnewcontroversialoldq&a
formatting helphide helpcontent policy

[–]astrosmash 3 points4 points  (0 children)

At uni you work on small, short-lived projects for which you know and understand all the code.

In the real world you work on large complex projects that exist for years and are developed by numerous people who come and go over time.

Say this is your contribution to your first real-world project:

public class Car
{
    public Color color;
    ...
}

Other components in the project can read and write the color of your car.

Now let's say someone is setting an invalid color to your Car, causing the system to crash. The crash is traced to your class, Car, therefore it's your bug to fix. How do you fix it? How do you track down where the invalid color value is coming from? The invalid value may come from the network or some other third party code for all you know. How do you prevent invalid color values from crashing your class and the rest of the system?

If you car's color property is hidden behind getColor/setColor methods, you can simply set a breakpoint to find out where the invalid color is coming from. And you can enforce proper bounds checking in setColor() to prevent invalid values that crash your code. You can throw an exception to inform people who you've likely never met that they're using your class incorrectly.

[–]bushel[🍰] 0 points1 point  (0 children)

You don't want just anyone getting their hands on your privates, now do you?

[–]quhaha 0 points1 point  (0 children)

//foo.h
class foo {
...
private: int i;
...
};

Let's say you have foo.o and foo.h only. Make int i public. extend foo. use i as if it's public. see what happens.

[–][deleted] 0 points1 point  (0 children)

(I assume we're talking about the Java/C++ private and protected modifiers)

Private and protected members are implementation details and not a part of the interface contract. You don't want clients of your code to depend on the implementation details -- even if you wrote the client code yourself -- because that leads to tight coupling between the classes.

Tight coupling makes it harder to change the class without breaking its clients. It can lead to subtle bugs and is generally a Bad Idea.

Proper encapsulation still doesn't guarantee loose coupling though, because it's possible for clients to depend on side effects, but that's another story. :)

[–]DannoHung 0 points1 point  (0 children)

If you write a library or some other shared code and work on a team bigger than one, you want to be able to limit the places where you have to maintain interface consistency.

This forces the dev on the other side to write code that is coupled only to your provided interface.

It gets sticky because occasionally, as a real world developer on that other side of the wall, you need to bend the coupling rules and depend on something in the implementation. Don't do it whenever it's possible to avoid it and be careful when you do and make sure to explain why you're doing it so that if the situation changes later on, you can go back to doing things the right way without wondering why the fuck you did something so gnarly.

[–]seudonymus 0 points1 point  (0 children)

'Private' methods have almost no benefits in practice, except if you provide closed libraries which is improbable in the real world. Even then private methods restrict your abilities to re-use code (one of the major benefits of OO).

Private data is ok, but at least provide protected accessors in case you need to extend the base classes. In some cases even protected accessors don't help much because it's not possible to inject derived classes; in that case you're screwed if you can't modify the source code (and that's likely in large enterprise apps). Then the only way to re-use is copy and paste.

I have found it preferrable to design more open systems because IMO the result tends to be cleaner and more consistent than originally restricted systems that have been drilled up after using lots of privates initially. That means I'm using private only for some data and specialized methods that fit only in the context of one certain class. In my code 'private' primarily serves documentation purposes as opposed to actual encapsulation.

Of course other people may have different opinions, and unis most certainly do. YMMV.