4

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?

Improve this question
4
  • 1
    Have you read Holub on Java getters/setters, btw? A classic (and very insightful) rant!
    – mlvljr
    Jun 2, 2012 at 19:44
  • Thank you @Matthew Flynn for correcting so many language error in my text. English is not my native language. I appreciate it.
    – Samuel
    Jun 7, 2012 at 1:04
  • 1
    @Samuel--I gathered, and that's OK. Your English is better than my anything-other-than-English, n'est pas?
    – Matthew Flynn
    Jun 7, 2012 at 1:28
  • You may consider reading this paper by Alan Snyder Encapsulation and Inheritance in Object-oriented Programming Languages. There are copies in PDF around the web. Also you may consider this another answer about encapsulation.
    – edalorzo
    Apr 7, 2014 at 18:27

3 Answers 3

Reset to default
4

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.

Improve this answer
2
  • 2
    Thank you Matthew for your answer. I think the best way to define if your code is enough encapsulated is to imagine if the 'other' guy would be happy to maintain your code. Like Martin Golding said: "Always code as if the person who ends up maintaining your code is a violent psychopath who knows where you live." It takes time to do 'fail-safe' code and I like to imagine my code like the knowledge that it requires to a human to start a car; you just have to put the key in the socket, turning it and the car start. You don't have to know how the engine works. Thank you again for your time.
    – Samuel
    Jun 3, 2012 at 4:36
  • @Samuel - Fantastic quote--I hadn't heard that before.
    – Matthew Flynn
    Jun 3, 2012 at 18:04
6

Answer: When you have your interface complete, then automatically you are done with encapsulation. It does not matter if implemenation or consumption part is incomplete, you are done since interface is accepted as final.

Proper development tools should reduce cost more than tools cost themself.

You suggest that if encapsulation or whatever property is not relevant to market offer, if customer does not care then the property has no value. Correct. And customer cares nearly about no internal property of code.

So why this and other measurable properties of code exist ? Why deveoper should care ? I think the reason is money as well: any labor intensive and costly work in software development will call for a cure. Encapsulation is targeted not at the customer but at user of library. You saying you do not have external users, but for your own code you yourself are the user number 1.

  • If you introduce risk of errors into daily use, then you increase the cost of development.
  • If you spend on reducing the risk, you will increase the cost of development.

Market and evolution keep forcing this choice. Choose the least increase.

This is all understood well. But you are asking about this particular feature. It is not the hardest one to maintain. It is definitely cost effective. But be aware about laws of human nature and economy. Tools have their own market. The labeled cost for some can be $0, but there is always hidden cost in terms of time spent on adoption. And this market is flooded with methodologies and practices with negative value.

Improve this answer
7
  • +1, Yep, purism for-the-sake-of-itself (when you pay for it, but it does not pay you) is just wasteful. The purism to always be pursued is in cost/quality/etc outcome optimization. And the latter purism dicatates abandoning the former one. :|
    – mlvljr
    Jun 2, 2012 at 19:48
  • @RocketSurgeon First, thank you very much for answering to my question. Ok, I think I misspoke. I always 'encapsulate' private fields in public properties and I never want to see public field from my coworkers when I do code review. What I meant is that this type of encapsulation is just the tip of the iceberg in the vast world of encapsulation. When we dig deeper, I think it can take a lot of time to create code that is 'fail- safe'. The limit of the quality of code is endless and what I really meant is: When you can know that your code have enough encapsulation? Thank you again.
    – Samuel
    Jun 2, 2012 at 21:25
  • My look at encapsulation using interfaces is that its allows to share the workload across 3 persons. The owner of interface, the implmentor and the consumer. First minute, since the interface is released, the team can grow +2 persons with no blocking lock of waiting on each other. You know your interface, so you can start using or implementing it before counterpart is complete. It speeds up the process x2..3 fold. And also the incapsulation is inevitable with interfaces, as it hides implementation 100% perfectly. When you have your interface, then automatically you are done with encapsulation.
    – user7071
    Jun 3, 2012 at 1:26
  • As far as validating state and ensuring your API is used properly, that is mostly the job of your interface. You should make it easy to use your API correctly and difficult to use it wrong. [gah, I accidentally hit enter while typing this, please stand by]
    – Esme Povirk
    Jun 3, 2012 at 4:15
  • If a parameter or state validation is obvious to you during development, add it. If your validation is non-obvious, adding it is likely to cause problems (by making useful cases impossible) and unlikely to solve them (because it's hard to predict the ways your program will break), so IMO any thought put into this will consume time for no benefit.
    – Esme Povirk
    Jun 3, 2012 at 4:21
4

Encapsulation exists to protect your class invariants. This is the primary measure for 'how much is enough'. Any way to break invariants breaks class semantics and is bad (tm).

A secondary concern is limiting visibility and as such the number of places that can/will access data and thus increase coupling and/or number of dependencies. This needs to be done with care though. As requirements change, often times that decision to limit what the class exposes leads to awkward hacks to deal with the new requirement.

This though is one of those design concerns that comes with experience. In doubt, favor encapsulation. The concerns are regardless of 'public' API or not. Even for internal code, new or forgetful or sleepy programmers will write bad code. If your class needs to be resistant to bad code, then do so.

Improve this answer
2
  • I like it when you say that you must limiting visibility to reduce coupling. What is fun about that is that encapsulation for the first time seems to be the most easily thing to master in the object oriented concepts compares to Inheritance and Polymorphism but the more you program and think about designs, the more you find that encapsulation is the most difficult thing to control. The more I read about object oriented concepts and the more I not satisfied about the code I produced. It's always good to receive opinions from others like you.
    – Samuel
    Jun 3, 2012 at 4:46
  • I think it's interesting to note that having good encapsulation isn't really a tradeoff between time and quality. Writing good classes and good APIs doesn't take longer time than writing bad ones, it's mostly just a question of skill and experience. Too often I hear people excuse bad code with "well we don't have time to make better code" when the real problem is "we don't have the skill needed to write good code".
    – sara
    May 13, 2016 at 12:33

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.