Nov 29, 2014 03:41 PM|robin.sedlaczek|LINK
I am really happy to get feedback from you! Thanks a lot for it! Please excuse that the post was a little bit long, but those things need time to explain. Further, I wrote my answer to your feedback as reply in my blog and past it here, too. Do not need
to link my blog post again because the link can be find above. Back to your feedback.
In your comment, you said:
"...it builds on two fundamentally flawed premises..."
Can you please explain the second one? I cannot see it, please excuse that. You are correct that DI is an application of the Dependency Inversion Principle (http://www.objectmentor.com/resources/articles/dip.pdf). But the Service Locator Pattern can be used
together with dependency injection (http://martinfowler.com/articles/injection.html#UsingAServiceLocator): dependencies are injected into a container called the service locator. Then, consuming code looks for a needed service in this container, in which dependencies
have been injected.
Maybe the Service Locator Pattern is the opposite (or at least something different) of DI (you should define 'opposite'), but they do not exclude each other. I have read all your posts, but I cannot find an example or argumentation that proves your statements
or gives some kind of evidence. So please provide, if possible. That would help me to understand.
To your first point:
"...his sentence represents a failure to understand the LSP. You should reread Robert C. Martins paper about the LSP..."
I agree to you and revert my statement. Programming against interfaces is not enough to prevent violations against the Liskov Substitution Principle. But that is half of that what I meant. Defining interfaces in such a framework is a way to make it "simple"
for developers to use it. Or say, that's the idea behind it. But it is correct, that violation of the LSP is not far away. And so the Open Close Principle is threatened what leads to more side-effects, bugs etc. in software designs.
Regarding the LSP (https://docs.google.com/file/d/0BwhCYaYDn8EgNzAzZjA5ZmItNjU3NS00MzQ5LTkwYjMtMDJhNDU5ZTM0MTlh/edit), we should talk more about behavior of software. When thinking about violations, you have to think about inheritance hierarchy - especially
about base classes. So there is a problem with the LSP in general, when looking at interfaces in isolation (those problems with relaxing preconditions and strengthen post-conditions). As stated above, using interface is some kind of make it easy for developers
to do things in the framework - from my point of view.
Now the questions is, what would you suggest when looking at the ASP.NET vNext framework? Using abstract base classes in the framework, from which clients derive? Maybe give them pre- und postconditions e.g. using code contracts (http://msdn.microsoft.com/en-us/library/dd264808(v=vs.110).aspx)
or at least using method comments? What is YOUR proposal for the ASP.NET vNext team?
Would be nice to know what you are thinking! Thanks a lot again for your feedback! I am looking forward to the next one!