I'm confused by this post by Mark Seeman.And his comment on IInitializable below:The problem with an Initialize method is the same as with Property  Injection (A.K.A. Setter Injection): it creates a temporal coupling  between the Initialize method and all other members of the class.  Unless you truly can invoke any other member of the class without  first invoking the Initialize method, such API design is deceitful and  will lead to run-time exceptions. It also becomes much harder to  ensure that the object is always in a consistent state.The same time he writes:This issue is similar to the issue of invoking virtual members from  the constructor. Conceptually, an injected dependency is equivalent to  a virtual member.I thinks this statement is true only if admit that constructed != initialized.What we get now:Dependencies are injected in constructor but it is not recommended to use them.Initialize phase brings complexity and should be avoided.Isn't it contradictory?Imagine class needs to set its state using the provided dependencies. Loading saved setting for example.Init is bad, constructor is bad, so where to perform this operation?And another point:Are not methods like Connection.Open() just another name for Initialize? Question:So can anyone describe a good initialization pattern in the context of Dependency Injection that addresses the concerns Mark Seeman brings up?
Separation of construction and initialization
architecture;object oriented design;constructors;initialization;construction