0

I have two classes: ChildOne and ChildTwo extended from ParentClass. ChildTwo has a custom field over the inherited ones.
In some parts of the app, most of the time this ParentClass is used to display data to UI and some widgets need to know if the instance is ChildTwo to display the custom field.
However in another part of the app, I have to enhance the ParentClass, so I created another class EnhancedParentClass extends ParentClass.
This class use used in most of the widgets, but again there are some widgets that need to know the difference between the EnhancedParentClass and let's say an extended class ChildTwoEnhancedClass.
What’s the best way of solving this?

  1. class ChildTwoEnhancedClass extends EnhancedParentClass implements ChildTwo
  2. class ChildTwoEnhancedClass extends ChildTwo implements EnhancedParentClass

Is there a way to do this, without the need to extend the main classes “in paralel” with the “enhanced” one? Or is it something completely wrong with this implementation?
I looked over mixins, but I don’t think they fit this case, as far as I’ve seen mixins are used to share logic(mimic multiple inheritance), not necessarily share class members.
These classes are used as data immutable models.

stf
  • 41
  • 1
  • 7
  • 3
    Have you considered Dart's support for mixins? In OOP you should not (ab)use inheritance as a substitute for mixins. – Dai Oct 12 '21 at 00:11
  • If `ChildTwo` only adds data members (i.e., it declares an interface and provides no logic), choice #1 is clearly simpler than choice #2 since choice #2 would require that `ChildTwoEnhancedClass` re-implement/duplicate logic from `EnhancedParentClass`. – jamesdlin Oct 12 '21 at 07:55
  • Please edit the question to limit it to a specific problem with enough detail to identify an adequate answer. – Community Oct 12 '21 at 11:22
  • @Dai I know that in OOP inheritance should not be abused and used for everything, but I think this is a case where it fits. I don't extend many levels down and if I use composition, it seems to me that there's more duplicate logic. Regarding the use of mixins, as far I'm aware, they should be used to share behaviour, not fields, so I don't see how they fit here. @jamesdlin That was my thought also, but it still doesn't seem right imo. If for example `ChildTwo` would have let's say many more extra fields, then what? The option one would be better? the number of extra fields should dictate? – stf Oct 12 '21 at 18:37
  • @Stefi On the contrary, mixins are used **precisely** to import state, fields, _and/or_ behavior into a type _without_ using inheritance. Mixins exist so we don't need to copy+paste members _without_ expressing an "is" relationship, whereas inheritance is used to express an "is" relationship. – Dai Oct 12 '21 at 18:38
  • @Stefi Why do you say that using composition "means duplicate logic"? The whole point of composition is to prevent duplication of logic (well, behaviour) _without_ using inheritance either (consider mixins as a special-case of composition). – Dai Oct 12 '21 at 18:40
  • in this thread https://stackoverflow.com/questions/54166892/how-can-i-initialize-a-mixins-immutable-data-in-dart, the accepted answer is that "Mixins are not for declaring variables. But for reusable methods instead" – stf Oct 12 '21 at 20:40
  • @Stefi Mixins in Dart have changed a lot since 1.0 - the current Dart language tour demonstrates using mixins to add fields to a type: https://dart.dev/guides/language/language-tour#adding-features-to-a-class-mixins – Dai Oct 12 '21 at 21:44
  • @Stefi See this answer too: https://stackoverflow.com/a/45903671/159145 ( "Mixins is a way to abstract and reuse a family of operations **and state**" - emphasis mine ) – Dai Oct 12 '21 at 21:44

0 Answers0