Tell me if I get this right, but the most important advantage of having only an abstract class is that you are guaranteed your user extends the abstract class instead of implementing the interface, which let you easily extend it later (i.e. add methods) without breaking existing user code?
On the other hand, it looks like, in a world of unchanging APIs, the interface might be the best way to go, facilitating things like reuse via a composition/delegation pattern. For example, MyPresenter could inherit from BasePresenter class and implement Activity, delegating all the calls to a composed AbstractActivity. Without an interface I would have to refactor BasePresenter to inherit from the Activity abstract class, making it impossible to have non-activity presenters. So it looks to me like it boils down to: 1) How likely is it that the Activity interface evolves in a way that would not be handled by adding subinterfaces or extra interfaces? 2) How frequently are users expected to compose/delegate with Activity? A concluding remark: GWTP went the abstract class way for its hierarchy of Presenter classes. It makes it quite easy to use, but the composition problem has reared its ugly head a couple of times. If I had to do it again I would use interfaces and favor composition of default implementations. Cheers, Philippe On Dec 6, 5:05 am, Jeff Larsen <[email protected]> wrote: > Personally, I'm a fan of having both. The default implementation can > be an abstract class but have that abstract class implement the > Activity interface. Developers will be making a conscious choice to > use the interface only knowing that they can introduce bugs. -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
