Comments on: When To Code To an Interface http://blog.stevienova.com/2008/08/28/when-to-code-to-an-interface/ Homepage of Steve Novoselac Fri, 12 Mar 2010 15:59:49 -0800 http://wordpress.org/?v=2.9.2 hourly 1 By: naturalight67 http://blog.stevienova.com/2008/08/28/when-to-code-to-an-interface/comment-page-1/#comment-125051 naturalight67 Tue, 25 Nov 2008 14:20:23 +0000 http://blog.stevienova.com/?p=940#comment-125051 Actually, semantically what a person "is" could be vague enough for some businesses, like healthcare, to warrant to use of interfaces. Actually, semantically what a person “is” could be vague enough for some businesses, like healthcare, to warrant to use of interfaces.

]]> By: Yarin Benado http://blog.stevienova.com/2008/08/28/when-to-code-to-an-interface/comment-page-1/#comment-118535 Yarin Benado Sat, 30 Aug 2008 20:49:47 +0000 http://blog.stevienova.com/?p=940#comment-118535 You are partly correct saying that there are times when a concrete class will suffice and you'll never need a different implementation of it, But your example is wrong. a Person is a an entity abstraction, where the importance of it being its properties rather than interacting methods. There's really no need to interface your model domain, as changing it will not require changing other layers of the system. The paradigm of coding to interfaces rather than to classes is more relevant to a service layer or persistency and not to models. When you're coding services, you're almost always predefining a "contract" which other components shall respect and interact upon. With this in mind, it's actually a must to code to interfaces in order to gain the benefits of loosely coupled components (and of course "extras" such as IoC, strategy and other patterns, etc.) It's actually pretty easy to see which components should be "interfaced" and which should not by drawing a UML component diagram (where interfaces components actually take a large part) You are partly correct saying that there are times when a concrete class will suffice and you’ll never need a different implementation of it, But your example is wrong. a Person is a an entity abstraction, where the importance of it being its properties rather than interacting methods. There’s really no need to interface your model domain, as changing it will not require changing other layers of the system.

The paradigm of coding to interfaces rather than to classes is more relevant to a service layer or persistency and not to models.

When you’re coding services, you’re almost always predefining a “contract” which other components shall respect and interact upon. With this in mind, it’s actually a must to code to interfaces in order to gain the benefits of loosely coupled components (and of course “extras” such as IoC, strategy and other patterns, etc.)

It’s actually pretty easy to see which components should be “interfaced” and which should not by drawing a UML component diagram (where interfaces components actually take a large part)

]]> By: Aaron Ballman http://blog.stevienova.com/2008/08/28/when-to-code-to-an-interface/comment-page-1/#comment-118434 Aaron Ballman Fri, 29 Aug 2008 06:13:45 +0000 http://blog.stevienova.com/?p=940#comment-118434 Too much of a good thing is bad. ;-) But I do agree that many concepts which could be abstracted eventually end up being so, and interfaces are the way to go. My general rule of thumb is: if I need to use it polymorphically, it's usually done via an interface. If I can see a case where I'll want to use it polymorphically in the future, I'll use an interface. Otherwise, just use a straight-up class. Honestly, the refactoring to turn something into an interface when following this rule is so trivial that it really doesn't hurt. Too much of a good thing is bad. ;-) But I do agree that many concepts which could be abstracted eventually end up being so, and interfaces are the way to go. My general rule of thumb is: if I need to use it polymorphically, it’s usually done via an interface. If I can see a case where I’ll want to use it polymorphically in the future, I’ll use an interface. Otherwise, just use a straight-up class. Honestly, the refactoring to turn something into an interface when following this rule is so trivial that it really doesn’t hurt.

]]> By: Steve Novoselac http://blog.stevienova.com/2008/08/28/when-to-code-to-an-interface/comment-page-1/#comment-118432 Steve Novoselac Fri, 29 Aug 2008 04:58:29 +0000 http://blog.stevienova.com/?p=940#comment-118432 right but how often to you need to mock your person class? right but how often to you need to mock your person class?

]]> By: Harish http://blog.stevienova.com/2008/08/28/when-to-code-to-an-interface/comment-page-1/#comment-118430 Harish Fri, 29 Aug 2008 04:19:39 +0000 http://blog.stevienova.com/?p=940#comment-118430 In my opinion coding against interfaces helps to enforce a key OOP's principle 'coding against abstractions rather than implementation' . This gives us the freedom to swap components at run time, also from a testability perspective , many frameworks like NMock ,RhinoMock ,etc which use DI to mock your calls require you to code against interfaces rather than implementations. In my opinion coding against interfaces helps to enforce a key OOP’s principle ‘coding against abstractions rather than implementation’ . This gives us the freedom to swap components at run time, also from a testability perspective , many frameworks like NMock ,RhinoMock ,etc which use DI to mock your calls require you to code against interfaces rather than implementations.

]]>