Comments on: When in Doubt, Create an Interface http://coliveira.net/software/when-in-doubt-create-an-interface/ by Carlos Oliveira Tue, 15 May 2012 01:46:36 +0000 hourly 1 http://wordpress.org/?v=3.3.2 By: Ondra "Satai" Nekola http://coliveira.net/software/when-in-doubt-create-an-interface/comment-page-1/#comment-135 Ondra "Satai" Nekola Fri, 29 May 2009 14:54:13 +0000 http://coliveira.net/?p=258#comment-135 @colivera: you don't need to be tight to the implementation, abstract class can provide just abstract methods. But anytime later, you would like to add a method, you can provide it (of course with a basic implementation) and clients can provide their own implementation later. Providing both interface and abstract class may be helpful in some scenarios (probably most notably, when you sometimes need some form of "multiple inheritance"), but it can not remove the main problem - you can not add methods into the interface, that can be implemented by your clients. And I definitely agree with you, that this theme has no right solution, that fits every situation. Such a rule would be great, but now we need to use our brains and experience to decide every time. (Btw: this problem affects source code level compatibility more than binary compatibility, at least at Java platform.) @colivera: you don’t need to be tight to the implementation, abstract class can provide just abstract methods. But anytime later, you would like to add a method, you can provide it (of course with a basic implementation) and clients can provide their own implementation later.
Providing both interface and abstract class may be helpful in some scenarios (probably most notably, when you sometimes need some form of “multiple inheritance”), but it can not remove the main problem – you can not add methods into the interface, that can be implemented by your clients.

And I definitely agree with you, that this theme has no right solution, that fits every situation. Such a rule would be great, but now we need to use our brains and experience to decide every time.

(Btw: this problem affects source code level compatibility more than binary compatibility, at least at Java platform.)

]]> By: coliveira http://coliveira.net/software/when-in-doubt-create-an-interface/comment-page-1/#comment-134 coliveira Fri, 29 May 2009 14:05:43 +0000 http://coliveira.net/?p=258#comment-134 @Satai: hi, your points are very relevant. Of course there are some disadvantages in publishing interfaces, but this has to do with maintaining binary compatibility across libraries. It is something that you cannot get completely rid of when using statically typed languages. Using abstract classes also has a lot of disadvantages, the biggest one being that you are tied to that implementation. Also everyone needs to inherit from that class, which limits usability. One common solution is to provide an interface AND an abstract class. You have to study each case to see what is more suitable. @Satai: hi, your points are very relevant. Of course there are some disadvantages in publishing interfaces, but this has to do with maintaining binary compatibility across libraries. It is something that you cannot get completely rid of when using statically typed languages.

Using abstract classes also has a lot of disadvantages, the biggest one being that you are tied to that implementation. Also everyone needs to inherit from that class, which limits usability. One common solution is to provide an interface AND an abstract class. You have to study each case to see what is more suitable.

]]> By: Satai http://coliveira.net/software/when-in-doubt-create-an-interface/comment-page-1/#comment-133 Satai Fri, 29 May 2009 13:51:56 +0000 http://coliveira.net/?p=258#comment-133 Please, don't use/publish interfaces in your APIs! ;) Interfaces are OK, when you use them after a very serious consideration. But publishing an interface is a common trouble, you are not allowed to change it anymore. You can not remove methods - your clients can call it. You can't add methods - your clients may implement the interface and this would broke their implementation. And (of course) you may not change signatures for the same reasons. Abstract classes are much more suitable solution in majority of situations. Please, don’t use/publish interfaces in your APIs! ;)
Interfaces are OK, when you use them after a very serious consideration. But publishing an interface is a common trouble, you are not allowed to change it anymore. You can not remove methods – your clients can call it. You can’t add methods – your clients may implement the interface and this would broke their implementation. And (of course) you may not change signatures for the same reasons.
Abstract classes are much more suitable solution in majority of situations.

]]> By: sud http://coliveira.net/software/when-in-doubt-create-an-interface/comment-page-1/#comment-106 sud Wed, 20 May 2009 03:28:02 +0000 http://coliveira.net/?p=258#comment-106 The Interface Segregation Principle from SOLID priciples provides a useful guideline on creating lean and clean interfaces that resist bloat. The Interface Segregation Principle from SOLID priciples provides a useful guideline on creating lean and clean interfaces that resist bloat.

]]>