Experiencing dotNet with Sergey Osypchuk

Public Constructors are Evil [Articles]

Yes, I'm not joking.
I have only one, but very serious reason:

In most cases rejecting of public constructors will greatly increase reuse
of your code.

I'll try to explain my point of view in next few minutes.
In OO world we could have inheritance and this is widely used and lovely by many of us feature. we happy to override base methods and change behavior of class. However, for constructors in ANY language we do not have a possibility to make it virtual. If someone wrote something like this:

Button btn = new Button();

Later you could not change anything - you need to rewrite it in all places. The best is situation where you could change source code, but if it is used in many different projects, cost of performing changes increases greatly, because you need to check compatibility with other projects.

Even Microsoft in Windows Forms Generators shows for us a very bad example - it uses public constructors. Have you ever tried to change all buttons from one type to another?

Another good point of public constructor boycott: every team member start to think in terms of factories. When component has a factory and way to change it, you have a way to completely modify classes which are constructed by component.

Every component should have a factory with virtual methods for each class - constructor pair (In case if more than one constructor required). And it should be simple and clear way to change this factory - in simplest case it could be read/write singleton, but it is component dependent and could be solved in different ways with different benefits. Good to have a parameter in each of factory method which could be used to describe context - thus in future it makes possible for factory to make a decision which object to build. [If you interested, i can talk about in another article]

Real life workarounds

Life starts to make surprises in places where dotNet automatic uses of constructors. It requires from code to have accessible public constructors - for remoting and for Web Services.

I suggest to use ObsoleteAttribute to keep source code clean from public constructors. It shows mistaken usage of members, marked obsolete at compile time, and allows for dotnet use it.

Second parameter in ObsoleteAttribute constructor is 'error' which shows compile time error, if this constructor used. Do not use this for webservices! You code will compile fine. At runtime, dotnet generates code based on .asmx file and then compiles it using compiler and you receive very strange error only when trying to execute method which uses such class as parameter or result. [HTTP error 500 - Internal server error, but on server side all will be clear]

Also could be helpful to know that reflection allow to call a constructors with ObsoleteAttribute even with Error=true.

Exceptions

In every rule there are exceptions. And this rule also has it. At least, you need public constructors for Attributes. Mostly it is not a problem to use it for exceptions, etc.

Welcome to world without public constructors - I'm looking forward for your feedback.

posted by Sergey Osypchuk @ 8:11 AM