Component oriented framework

[rpkamp]

@igor_g

You should to reuse existent code, because if you should to change something in this code (e.g. placeholder in login or i18n), you could make this changes only once

And being able to change a label only once is more important than software that is easier to maintain?

@igor_g

And if this changes in parent classes will be unsuitable for some child class, you will change this child class.

Ah, but then as a developer I need to know about the child class. With all the inheritance you lose the ability of local reasoning of a single class, everything you do requires global reasoning over multiple classes, which makes things so much harder.

@igor_g

Of course, inheritance is dependency. But often rather to get it, than not.

I don’t understand what you’re saying here.

@igor_g

There is a class, and some similar class required. I say, developer should to inherit existent class. My opponent says: no, I have a switch in existent class.

And propose a third option: extract common functionality into a single class, and then create two classes that both get the common functionality injected.

@igor_g

No, really… School example… If you have a base class Car and you need to do with Volvo, Toyota, Mersedes, Cadilac and hundreeds more… You inherit base class Car or make a huge switch directly in this class?

Of course there are examples of where inheritence does work, and this is one of them. That doesn’t mean it always works, and indeed in a lot of cases it’s being used where it doesn’t fit. Classic example being the Shape concept a lot of people go to to explain inheritance. It may seem reasonable to have methods setWidth and setHeight on there, but then what do you do with squares? Since squares have the requirement width = height, when I call setWidth on it, the height should be set as well. But looking from the interface Shape that’s totally unreasonable behaviour (and a violation of the Liskov Substitution Principle).

@igor_g

What is your alternative?

Depends on the kind of class If it’s a service like class than it would be private property, no getters, no setters. In that case it’s just a service class using another service class. Nobody needs to know it’s using it, nobody should care.

In case of Entity like objects I have private properties, maybe a getter if it’s needed, and some kind of setter, but mostly a bit more intelligent than just “change this property”. For example I may have properties for street name and house number, city, postal code, but the setter would require all of these, since most of the time they all change together.

As for the disadvantage of LoD, let me add some emphasis:

@igor_g

Disadvantages: Although the LoD increases the adaptiveness of a software system, it may result in having to write many wrapper methods to propagate calls to components; in some cases, this can add noticeable time and space overhead.

Again, it depends. Sometimes it can be worth your while not to adhere to LoD, but it’s important to recognise you’re doing that and you also know the reasons why you’re doing that.
As always, a fully dogmatic approach where everything must adhere to LoD will result in a horrible mess, as with any law / principle / pattern / etc.