Internal and protected in a private api

I work in development team of about 12 and we build a reasonable set of API's that we use on a strictly in-house only basis. Typically all classes a开发者_StackOverflow中文版nd interfaces are public because that is just how they get done. I have often considered the value of making some of the constructors internal so that the consumers of the API (albeit internal) have to use the factory or some other reason that I can't think of now.

Is this something that you and your team practice?

How does this effect your unit tests? Do you find that it is okay to unit test a class through it's factory or do you access the constructor through something like PrivateObject?

The answer is yes; my current project has exactly one developer working on it - me - and yet I still use visibility and other access modifiers, along with more complex design patterns, as necessary. Here's why:

• The compiler, if you let it, can be one of your greatest tools to enforce good design patterns. Making everything public can cause a lot of headaches down the road, when you have to maintain an object whose normal state during program execution is the object-oriented equivalent of a human living his life on an operating table with his chest cracked open and everyone who knows him from his children to his electric company poking around in his vital organs to get him to do what they want. Adding another hand, or removing one, can cause the patient to go into cardiac arrest.

• Code should be self-documenting. A class or class member that is marked as internal means it probably should be; if everything's public, you don't know if there's anything you shouldn't touch when interfacing with the object. Again, you've got your patient sitting on the operating table, and all of a sudden a new guy comes in, grabs the liver and goes "hey, what does this do?". Objects should have their hands shaken, be told to do something and let go to do it, and the function of their liver is of no concern to anyone but them.

• Code should be maintainable by your posterity. This ties back to the first two rules, but basically, someone should be able to open up your codebase, find the entrance point and trace through basic execution flow, all the while looking at objects utilized along the way and determining their general form and function. Back to our patient on the operating table, let's say five years from now someone walks in on this scene; a guy split open on a table with 50 guys in his guts. It's not going to look like any polite social custom he's ever seen; it'll probably look most like a ritual human sacrifice, and most people's first instinct when encountering such a situation is to run.

However, the flip side of the coin is that a design pattern implemented for its own sake is generally a Very Bad Thing. Once you graduate college and get your first job, nobody really cares that you know how to implement a Strategy pattern, and you shouldn't do so at the first opportunity just to say you did. Every pattern has a set of circumstances in which it applies. If you were a doctor, would you perform an angioplasty on the next patient who walked in just to say you were able to do it?