On 20 July 2013 21:31, Tudor Girba <tudor@tudorgirba.com> wrote:
Hi Igor,
Thanks for taking the time to write such a long answer.
I think you misunderstood my point :). I simply said that the two examples are not the same (and I can add now that "Butter subclass: #Fridge" is as bad as "Shampoo subclass: #Shower", but they are both different from "Announcer subclass: #MyDomainConcept").
It is only in your mind. If someone else will look at your code, he won't make any difference (and you can tell me why ;). And that is what matters. You know, i can also (ab)use things in my code and make very strange things, which can be understood only by me.. depending on intent, like having highly optimized code or as a way to code less (making many subclasses can be tiresome sometimes ;) But if there's any chance that anyone else will use this code or will need to change/understand/improve it, i would not do that. Because when i do, i putting them into misery.
As I understand, you conceded the point that inheriting from Object has reuse reasons, but that it is so because Object provides generic mechanisms that everyone wants. I can imagine scenarios where I want a different reflection support. All of a sudden the generic mechanism is not so generic anymore, and you get in the same situation as the one of wanting a different Announcer kind. Does it mean that inheriting from Object is a bad thing? No. It is a great good enough compromise for 99.9% of the cases.
Then you say that Announcer is not in the Object protocol as if this would be necessarily a good thing. I can argue that every Object should have announcer capabilities just like it has exception handling capabilities, but then we would go even further away from the main point :).
Not at all, i also think that having a generic way for any object to act as event source is quite valuable. That's why, there is already existing protocols for that (see events-blah categories). And dependents mechanism. And that's why we want to eventually unify them.. because there's too many.
Inheritance as reuse is definitely to be avoided, and indeed the principle of Least Authority (or more known as Principle of Least Privilege) is a relevant point (I concede that :)). However, I guess you agree that having #class defined in Object is not a horrible (it can be better, but it is not horrible) thing even if most objects do not need this information.
Another principle that might be more useful when thinking about inheritance is the Liskov Substitution Principle. From this point of view, as long as MyDomainConcept does not redefine the meaning of Announcer, it is not unreasonable to have it inherit from Announcer.
Yes, but where are the guarantees that you don't? Just think from outsider's point of view: when he sees Announcer subclass: #Foo what he will think first: - aha, this guy implements own kind of announcer or - aha this guy reusing announcer or - aha, this guy doing both things at the same time (a worst possible alternative) and how many abuses like that, he should see before making a logical conclusion: - aha.. this is the way how i should do as well.
I stop now. You can continue to shoot :).
-- Best regards, Igor Stasenko.