On 20 July 2013 21:31, Tudor Girba <[email protected]> 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.
