Recently, I read a lot of good articles about how to do good encapsulation. And when I say "good encapsulation", I am not talking about hiding private fields with public properties; I am talking about preventing users of your API from doing wrong things.
Here are two good articles about this subject:
http://blog.ploeh.dk/2011/05/24/PokayokeDesignFromSmellToFragrance.aspx
http://lostechies.com/derickbailey/2011/03/28/encapsulation-youre-doing-it-wrong/
At my job, the majority of our applications are not destined for other programmers but rather for the customers.
About 80% of the application code is at the top of the structure (Not used by other code). For this reason, there is probably no chance ever that this code will be used by other application.
An example of encapsulation that prevents users from doing wrong things with your API is returning an IEnumerable instead of IList when you don't want to give the ability to the user to add or remove items in the list.
My question is: When can encapsulation be considered simply OOP purism, keeping in mind that each hour of programming is charged to the customer?
I want to create code that is maintainable and easy to read and use, but when I am not building a public API (to be used by other programmers), where can we draw the line between perfect code and not so perfect code?