3 ms·

I recognize the object graph spaghetti the author is talking about and do find that distasteful. However, as everyone knows, even a functionally inclined guy l

I recognize the object graph spaghetti the author is talking about and do find that distasteful. However, as everyone knows, even a functionally inclined guy like me, there are great OOP codebases all around us. I wonder if the problem is how OOP modeling is taught. It's easy to project all sorts of everyday instincts onto an object graph that have nothing to do with software design. I certainly feel that there is something deeply and irredeemably wrong with every learning journey that begins with class Train overriding Vehicle::Move to print "choo choo".

bobmaxup 5y ago
> I certainly feel that there is something deeply and irredeemably wrong with every learning journey that begins with class Train overriding Vehicle::Move to print "choo choo". Why? How should it begin?
- HellDunkel 5y ago
  Good example of completely igoring the „data“ part. What are the inputs and outputs? In some cases it would make better sense to differentiate the train vehicle by a type enum, where as in other situations it might make sense to derive from a general „vehicle“. why, when and how are the important things to think about and this should be taught.
- vnorilo 5y ago
  I skimmed a lot of low quality C++ intro books to try and find some good ones for beginning students. Slim pickings. I recognized this pattern of solving some ridicilous non-problem to exhibit inheritance very early on. The message readers get from that is that inheritance is OOP, and the main thing is to first think what could inherit from what. This is not a fault in OOP itself, just a very bad approach to teaching it. In my teaching I always wanted to start from a problem that required single dispatch runtime polymorphism and introduced pure abstract classes (interface and implementations) as the means of accomplishing that. I felt that if there was just one C++ class programming pattern they ought to pick up, that was it.
  - Gibbon1 5y ago
    I feel like generics without type erasure actually solves the problem that inheritance was supposed to solve without creating a swamp of dependencies.
tored 5y ago
Yes, I think it would be better to start with composition with a few classes that you inject into your implementation. Next step is to replace those few classes with interfaces and test with multiple implementations of these interfaces. Class done. Edit: another important part is to separate your classes into two different types so you don’t end up as described in the article. One type of class is data only, like old style struct. The other type of class is a repository type, class for working with data classes. Thus you never ask a data class for more data, you ask a repository class for that. That eliminates the problem that the article describes as complex relations between data classes. Benefit of this is that you can create data classes from different sources, thus it becomes easier to gradually rewrite your storage as long as the data classes stays the same. Edit 2: the author of the article seem to describe something what I wrote, a datastore that exposes plain data objects.

bobmaxup 5y ago

> I certainly feel that there is something deeply and irredeemably wrong with every learning journey that begins with class Train overriding Vehicle::Move to print "choo choo". Why? How should it begin?

HellDunkel 5y ago
Good example of completely igoring the „data“ part. What are the inputs and outputs? In some cases it would make better sense to differentiate the train vehicle by a type enum, where as in other situations it might make sense to derive from a general „vehicle“. why, when and how are the important things to think about and this should be taught.
vnorilo 5y ago
I skimmed a lot of low quality C++ intro books to try and find some good ones for beginning students. Slim pickings. I recognized this pattern of solving some ridicilous non-problem to exhibit inheritance very early on. The message readers get from that is that inheritance is OOP, and the main thing is to first think what could inherit from what. This is not a fault in OOP itself, just a very bad approach to teaching it. In my teaching I always wanted to start from a problem that required single dispatch runtime polymorphism and introduced pure abstract classes (interface and implementations) as the means of accomplishing that. I felt that if there was just one C++ class programming pattern they ought to pick up, that was it.
- Gibbon1 5y ago
  I feel like generics without type erasure actually solves the problem that inheritance was supposed to solve without creating a swamp of dependencies.

tored 5y ago

Yes, I think it would be better to start with composition with a few classes that you inject into your implementation. Next step is to replace those few classes with interfaces and test with multiple implementations of these interfaces. Class done. Edit: another important part is to separate your classes into two different types so you don’t end up as described in the article. One type of class is data only, like old style struct. The other type of class is a repository type, class for working with data classes. Thus you never ask a data class for more data, you ask a repository class for that. That eliminates the problem that the article describes as complex relations between data classes. Benefit of this is that you can create data classes from different sources, thus it becomes easier to gradually rewrite your storage as long as the data classes stays the same. Edit 2: the author of the article seem to describe something what I wrote, a datastore that exposes plain data objects.