Messing with encapsulation

I know what exactly the encapsulation means. But this question was asked to me in an interview.

I have a requirement where in i have to create a new class. if in a team somebody messes up with the encapsulation part of the class bu开发者_如何学JAVAt on a whole the functionality that is required is working fine.and lets suppose its is delivered to the client.

what are the possible problems that a client might face because of that?

i tried to tell that security norms will be violated and we can use the vulnerability to add something and mess up the product.But he said client doesnt know anything regarding enhancing the code. I had finally given up.

could anybody please help me with some examples?

Bad encapsulation (whatever it means) makes proper use of the class harder.

For instance, if you have two public methods and they should be called in proper order only and otherwise the object state becomes corrupt that's an example of bad encapsulation - the user can't know from the class definition that those methods should be only called in this order and the class doesn't do anything to protect against calling in wrong order and once the user hasn't guessed the right order he is screwed.

Encapsulation is not a property of the program. It is a property of how the source code of the program is written. As such, someone without access to the source code (such as the end user) will not be affected by proper or improper encapsulation. You could write a program with no encapsulation whatsoever, and if the functionality works fine, the end user would never notice.

Of course, those who do have access to the code are affected by the presence of encapsulation, as it usually makes debugging old code and writing new orthogonal code easier. So, in a sense, this does impact the ability to deliver working functionality on time, but those were assumed, in your interview, to be the case.

Given "client doesnt know anything regarding enhancing the code", I assume they're not writing any code themselves that uses the API. The consequences to them are then only through distributed code that directly modified what should have been private parts of the object... that means more libraries and applications may contain code that also need to be modified should the workings of that class change. So, updates to the software may be larger and possibly harder to deploy. (If properly encapsulating member functions are inline anyway, it may still work out the same as calling code still needs recompilation).

BTW, encapsulation via private and protected isn't a run-time security feature... even at compile time, it's intended as a firm reminder to client code that certain things weren't designed to be directly accessed/modified, but can easily be bypassed even then using reinterpret casts, template specialisations and other hackery.

IMO the biggest problem that you may face is that you will underestimate the cost of refactoring or of implementing new features. For example replacing that class with a new one that works as a proxy to a remote may look simple stuff, but then you may face problems because the application ended up using internals that are hard to change for remote use.

May be taking shortcuts saved a little time but you'll end up giving back this time (and more) for free to angry customers because of this underestimation.

Another serious problem is that a program with a clear interface that however has been poked through doing nasty things with internal stuff just stinks. This is a problem in se, but also a problem because whoever is going to see that code will feel that's ok to do similar things for future changes especially when under time pressure.

This in the long term will change the program in a bowl of rotten segfaulting spaghetti that anyone will fear to touch because of unexplainable ripple side effects. A description of this "broken window" effect is in the nice book The Pragmatic Programmer.