Abstract classes and interfaces both have their downsides: - Abstract classes don't allow multiple inheritance, resulting in an explosion of tiny classes. - Interfaces tend to result in a hard to maintain framework because it is a lot harder to introduce new functionality (can't add a new method with a default implementation for old apps). Plus not being able to have convenience functions can make the interface version less useful.
Also the inability to have default implementation in interfaces makes it more annoying in places to control what appears in the SDK, since we can't use our @hide tricks or else third party apps can't implement it because they can't implement the needed hidden methods. I go back and forth between the two. I think I have settled on interfaces for small little things with one or two methods (callbacks like all the things on ListView) and abstract classes for larger protocols. One thing I am sure of, however: protected sucks. On Sun, Jul 24, 2011 at 9:42 PM, Zsolt Vasvari <zvasv...@gmail.com> wrote: > An interface is exactly just that (plus constant declerations). With > abstract classes, you can have static methods and everything else that > comes with a proper class. The drawback is, of course, that you can > only inherit from at most one abstract class. > > I cannot think of even a single example, off the top of my head, where > an abstract class in Android could have also been defined as an > interface without losing any functionality. > > > > On Jul 25, 12:05 pm, Indicator Veritatis <mej1...@yahoo.com> wrote: > > Those "many cases for this there is no particularly good reason one > > was picked over the other" are most likely, I hope, the cases where I > > gave up on trying to figure out why the Android team chose to make the > > one 'abstract class' and the other 'public interface';) > > > > On Jul 21, 10:28 pm, Dianne Hackborn <hack...@android.com> wrote: > > > > > > > > > On Thu, Jul 21, 2011 at 8:16 PM, Indicator Veritatis < > mej1...@yahoo.com>wrote: > > > > > > They do not pause to explain, for example ... why some classes are > defined > > > > a public abstract classes, while very similar other classes are > > > > defined as interfaces. > > > > > Well hopefully you generally don't care. And to be honest, in many > cases > > > for this there is no particularly good reason one was picked over the > other. > > > ;) > > > > > -- > > > Dianne Hackborn > > > Android framework engineer > > > hack...@android.com > > > > > Note: please don't send private questions to me, as I don't have time > to > > > provide private support, and so won't reply to such e-mails. All such > > > questions should be posted on public forums, where I and others can see > and > > > answer them.- Hide quoted text - > > > > - Show quoted text - > > -- > You received this message because you are subscribed to the Google > Groups "Android Developers" group. > To post to this group, send email to android-developers@googlegroups.com > To unsubscribe from this group, send email to > android-developers+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/android-developers?hl=en > -- Dianne Hackborn Android framework engineer hack...@android.com Note: please don't send private questions to me, as I don't have time to provide private support, and so won't reply to such e-mails. All such questions should be posted on public forums, where I and others can see and answer them. -- You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
