Originally posted by Adam Schaible:
Extends is a dangerous keyword - once applications become more complex you will see how dangerous it can become.
The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
public class Processor { private final WordService wordService; public Processor(WordService wordService) { this.wordService = wordService; } public String returnWord() { return wordService.getWord(); }}
A good question is never answered. It is not a bolt to be tightened into place but a seed to be planted and to bear more seed toward the hope of greening the landscape of the idea. John Ciardi
Originally posted by Adam Schaible:
Actually, the template method doesn't depend on implementation inheritance.
Anything that can be achieved using implementation inheritance can be achieved with interfaces and composition
and you're left with a MUCH better design.
Problems with this: You've exposted your internal API - cannot have private and abstract. You really don't want people calling getWord, but you have no choice.
Also, you really can't change the AbstractProcessor much without having to change it's subclasses (or at least test them).
The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
Make getWord() protected. Problem solved.
Originally posted by Adam Schaible:
As far has having a full suite of unit tests, I 100% agree - but it's not reality for a large portion of my clients. They would all love to have it, but most of the business budget people don't see it has a value-adding effort (no matter how many times they are told otherwise).
If you're simply wiring code together, extends is fine - when others are using your software, it's dangerous -- and you never know when it will switch from the former to the later.
The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
Spot false dilemmas now, ask me how!
(If you're not on the edge, you're taking up too much room.)
A good question is never answered. It is not a bolt to be tightened into place but a seed to be planted and to bear more seed toward the hope of greening the landscape of the idea. John Ciardi
Originally posted by Stan James:
Interestingly, our practice is exactly the opposite: we have external companies develop against our APIs, and we encourage them to *not* implement our interfaces, but to extend from abstract classes we provide that implement those interfaces. The reason being that this way we often can add methods to an interface without breaking all client code - most often it's possible to provide a default implementation in the abstract class.
Fascinating. I've wished I had done that after the fact some times.
The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
A good question is never answered. It is not a bolt to be tightened into place but a seed to be planted and to bear more seed toward the hope of greening the landscape of the idea. John Ciardi
Originally posted by Adam Schaible:
As far as tests are concerned, I can only test my API code - so I do agree with the doctor analogy, but I can't wash your doctors hands for him.
I don't know if you provide source or not, but I would have concerns as a client extending your implementation - less of a problem if I had the source, but still a problem.
The point of an interface is to layout your contract.
In my opinion, once an interface is published, it really shouldn't change. Interfaces should be the "foundation" of your structure.
By extending your abstract classes, you're just choosing to make that your way of sharing your code instead of an interface.
The other (large) problem with extending an abstract class, is that it's usually fairly difficult to quickly and easily "parse" the functionality, and integration points between the child and it's parent.
Just opinions, but that's what a forum is for!
The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
We don't. What concerns?
Note that you don't *have* to extend our base classes. It will just be more work for you if you don't.
Yes. And in a system that evolves over a decade and more, contracts need to change. So, what should we do if we find that the most consistent, coherent way of adding a new feature would require us to add an operation to an existing interface? Serious question.
it's a teeny, tiny, wafer thin ad:
a bit of art, as a gift, the permaculture playing cards
https://gardener-gift.com
|