5 ms·

Update: Removed the unnecessary and (as noted below) false remark about Joel not understanding Dependency Injection. The main (but not only) reason we have obj

by zby 12y ago

Update: Removed the unnecessary and (as noted below) false remark about Joel not understanding Dependency Injection. The main (but not only) reason we have object factories is to be able to extract code suitable to be unit-tested from the whole application. And unit testing is like testing the tire of a car in a laboratory instead of testing the whole car on a race track. Not that we don't test cars on race tracks - but it is a lot cheaper to test the tires in labs first. It is not that we sell Object Factories so that people can produce their objects - we use Object Factories in our code - so that the objects are better encapsulated. Once you understand that - the whole satire with hammer factories collapses. But OK frameworks are still yet another subject and I kind of agree that libraries are often better (http://perlalchemy.blogspot.com/2010/02/frameworks-are-framing-libraries-are.html http://perlalchemy.blogspot.com/2010/02/frameworks-are-frami...).

solutionyogi 12y ago
1. This was not written by Joel himself. This was written by a guy named Benji Smith on JoS forum. 2. I understand dependency injection completely but question if it's really required to write quality software OR is it a technique you use because programming languages are lacking. Let me give you an example. In .NET world, there is a product called, Isolator by a company called TypeMock. It can let you mock any type/method by exploiting CLR. In .NET, there is a type called System.DateTime with a static property DateTime.Now. I have seen code where people try to write interfaces to inject DateTime.Now. And I think it's an overkill. When I saw their example of how they can mock DateTime.Now without doing DI, I am personally convinced that DI is about addressing limitations of your statically typed language and is not an absolute must. http://www.typemock.com/TypemockIsolatorExamples http://www.typemock.com/TypemockIsolatorExamples
- robotkilla 12y ago
  > if it's really required to write quality software of course it isn't. if your program doesn't require dependency injection and you architect it for dependency injection, that isn't quality software.
  - solutionyogi 12y ago
    Here's the current status of .NET software development. I think there is a broad agreement that unit testing is a very useful tool in developing quality software. Because of the inherent limitation of C#, you can't unit test easily if you don't use DI. This often leads to a situation where you have tons of interfaces + each interface is implemented exactly by one class. This is because product like Isolator is not free. Hyptothetically, if Isolator was provided by Microsoft for free, I am sure that we will see reduced usage of DI. Don't get me wrong, I think there are other scenarios where DI is a great technique in designing components which are flexible. However, those scenarios are not that many. Using DI to make your software unit testable is an overkill IMHO.
- zby 12y ago
  Mocking is global - when you need two objects that need to have two different DateTime.Now - then you are out of lack if you mock it. DI is just a bit more universal than mocking. On they other hand mocking is simpler - agreed. Thanks for correcting me about who was the author.

by zby 12y ago

solutionyogi 12y ago

1. This was not written by Joel himself. This was written by a guy named Benji Smith on JoS forum. 2. I understand dependency injection completely but question if it's really required to write quality software OR is it a technique you use because programming languages are lacking. Let me give you an example. In .NET world, there is a product called, Isolator by a company called TypeMock. It can let you mock any type/method by exploiting CLR. In .NET, there is a type called System.DateTime with a static property DateTime.Now. I have seen code where people try to write interfaces to inject DateTime.Now. And I think it's an overkill. When I saw their example of how they can mock DateTime.Now without doing DI, I am personally convinced that DI is about addressing limitations of your statically typed language and is not an absolute must. http://www.typemock.com/TypemockIsolatorExamples http://www.typemock.com/TypemockIsolatorExamples

robotkilla 12y ago
> if it's really required to write quality software of course it isn't. if your program doesn't require dependency injection and you architect it for dependency injection, that isn't quality software.
- solutionyogi 12y ago
  Here's the current status of .NET software development. I think there is a broad agreement that unit testing is a very useful tool in developing quality software. Because of the inherent limitation of C#, you can't unit test easily if you don't use DI. This often leads to a situation where you have tons of interfaces + each interface is implemented exactly by one class. This is because product like Isolator is not free. Hyptothetically, if Isolator was provided by Microsoft for free, I am sure that we will see reduced usage of DI. Don't get me wrong, I think there are other scenarios where DI is a great technique in designing components which are flexible. However, those scenarios are not that many. Using DI to make your software unit testable is an overkill IMHO.
zby 12y ago
Mocking is global - when you need two objects that need to have two different DateTime.Now - then you are out of lack if you mock it. DI is just a bit more universal than mocking. On they other hand mocking is simpler - agreed. Thanks for correcting me about who was the author.