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.aspxhttp://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?
When too much encapsulation was reached
design;object oriented;encapsulation
The fact that your code is not being written as a public API is not really the point--the maintainability you mention is.Yes, application development is a cost center, and the customer does not want to pay for unnecessary work.  However, a badly designed or implemented application is going to cost the customer a lot more money when they decide that it needs another feature, or (as will certainly happen) the business rules change.  Good OO principles are there because they help make it safer to modify and append the code base.So, the customer may not directly care what your code looks like, but the next guy who has to modify it certainly will.  If the encapsulation (as you're defining it) is not there, it's going to take him a lot longer and be much riskier for him to do what he needs to do to serve the customer's needs.