5 ms·

In school they taught classes and inheritance like it was the biggest thing since sliced bread. I feel like they're but one tool, and necessary in limited case

In school they taught classes and inheritance like it was the biggest thing since sliced bread. I feel like they're but one tool, and necessary in limited cases. For example I recently encountered an API that had to intake 100+ key/value pairs and manipulate these values, and send them to various places. I tried to do the mappings and data manipulations and everything in one long piece of code functionally but it led to some serious spaghetti. When I separated things out into classes, it was much cleaner code, with a more well defined domains. It was definitely not perfect but ended up being much cleaner. This is a simple example but classes can be useful. It's arguable that the API could have been better written and that's true but sometimes you have to work with what you're given. Otherwise I would venture to say most code doesn't require classes.

LessDmesg 7y ago
By "I separated things out into classes", do you mean that you used the whole triad of inheritance + polymorphism + encapsulation?
- simion314 7y ago
  Do you need all 3 of them to have a class? In my experience classes are data+ methods that manipulate that data. Like a Vector class would have a rotate,normalize etc methods that return a new Vector.
  - nickthemagicman 7y ago
    Exactly. Clusters of parameters and functions that manipulate those parameters all specific to a 'domian' is really what a class is for. Inheritance/ Polymorphism is just more machinery to do that with. Functionality like mapping the keys to new names or uppercasing certain specific values or sending the data to certain places. You could have the functions and parameters all in one long piece of code, or you could put them into domains which makes dealing with it, reading it, understanding it, and working with it easier, in my opinion.
  - jerf 7y ago
    That's a question of definition. There are many who will passionately insist that yes, you absolutely need all of them. I hypothesize but can't prove that these are people simply regurgitating what they were taught in a classroom and who have not yet left Java/C++ to see what else is out there and what else can work. It is perfectly feasible to be educated that way and then spend your entire career in Java or C++ and come to conceptualize everything else as "that crazy minority stuff that isn't like Real Programming", and, in their defense, they are at least correct about the "minority" part. It's easy to forget if you read HN a lot, but inheritance + polymorphism + encapsulation remain the massively dominant paradigm, especially if you assume most C# is still basically written that way despite supporting other paradigms. Personally I take the loosest possibly view, mostly just "associating data and methods to operate on that data fairly tightly together, where they all get passed around as a unit". Some ability to have "x.y()" result in multiple possible implementations of "y" is necessary, or you just have a weird way of spelling function calls. That's about all I'll require to call something "OO" nowadays.
    - simion314 7y ago
      I think the number of developers that when starting a project start creating some inheritance tree is large. Some concepts work fit inheritance very well like GUI widgets or game entities, you would make a disservice not to tell students about the concepts and have them re-invent them. Not sure how other languages do it, but in my daily work the only time I use inheritance is with an ORM , to get the magic to work you need to extend the base Model class , add a few lines of configuration code and you are done, for more advanced uses I think you have to override some methods. But except the ORM code I don't think I used inheritance in a long time, though I used interfaces in some other cases.
      - LessDmesg 7y ago
        I think we need to separate inheritance trees (arbitrary depth of inheritance) from mixin/trait inheritance which has height = 2. The latter is a lot more useful in eg. games where objects are assembled from mixins like Legos. The former leads to fragility, class bloat and other problems (remember MFC...). Basically, GUI frameworks are the only area I know where OOP - real, authentic long inheritance chains with encapsulation and extensibility - has worked well.
  - LessDmesg 7y ago
    Nope, that's not a class, that's a struct and a module with functions. Any method called as obj.foo(5) is really just a function foo with a hidden argument foo(obj, 5). Rust makes this architecture explicit with its structs and trait impls separated - and no OOP in sight. Classes, on the other hand, are not structs with functions. More like black boxes whose contents can be swapped out at any moment. OOP is about hiding implementation and infinite extensibility.
    - simion314 7y ago
      I do not know Rust but this seems an implementation detail, like if I would make the Vector.normalize function static and then pass the this as an argument. Sometimes this pattern with static function works well too. My classes also have private methods and sometimes even private static pure functions. Anyway you Rust people do whatever you want and call them whatever you want , I will call a struct with methods a class.
- nickthemagicman 7y ago
  Nope. This was just an extremely simple case of domain separated parameters with domain specific functionality pertaining to those parameters. When you have 100+ parameters to deal with it helps in multiple ways to separate those out into domains and classes are a useful tool for that.
  - LessDmesg 7y ago
    Ok, good to know. I was afraid that actual full-scale OOP was what saved the day, but it was unnecessary yet again.
    - nickthemagicman 7y ago
      haha very true. I probably could have used it if I got super hard core about separating my domains up but it just seems to over complicate things.
agumonkey 7y ago
> In school they taught classes and inheritance like it was the biggest thing since sliced bread. they even had to dance around how to have a main entry point in class only languages like java the early 2k were really religion blinded around a class god, without teaching the real values and uses of classes in the context of problem solving
- tannhaeuser 7y ago
  Not even 2k, it was a thing in 1990s already. I remember a student coming in to the company I worked with around 1993/4. His thesis was about O/R binding frameworks and approaches for relational DBs. Generations of developers have drank the "impedance mismatch" and other OOP pseudo science koolaid since.

LessDmesg 7y ago

By "I separated things out into classes", do you mean that you used the whole triad of inheritance + polymorphism + encapsulation?

simion314 7y ago
Do you need all 3 of them to have a class? In my experience classes are data+ methods that manipulate that data. Like a Vector class would have a rotate,normalize etc methods that return a new Vector.
- nickthemagicman 7y ago
  Exactly. Clusters of parameters and functions that manipulate those parameters all specific to a 'domian' is really what a class is for. Inheritance/ Polymorphism is just more machinery to do that with. Functionality like mapping the keys to new names or uppercasing certain specific values or sending the data to certain places. You could have the functions and parameters all in one long piece of code, or you could put them into domains which makes dealing with it, reading it, understanding it, and working with it easier, in my opinion.
- jerf 7y ago
  That's a question of definition. There are many who will passionately insist that yes, you absolutely need all of them. I hypothesize but can't prove that these are people simply regurgitating what they were taught in a classroom and who have not yet left Java/C++ to see what else is out there and what else can work. It is perfectly feasible to be educated that way and then spend your entire career in Java or C++ and come to conceptualize everything else as "that crazy minority stuff that isn't like Real Programming", and, in their defense, they are at least correct about the "minority" part. It's easy to forget if you read HN a lot, but inheritance + polymorphism + encapsulation remain the massively dominant paradigm, especially if you assume most C# is still basically written that way despite supporting other paradigms. Personally I take the loosest possibly view, mostly just "associating data and methods to operate on that data fairly tightly together, where they all get passed around as a unit". Some ability to have "x.y()" result in multiple possible implementations of "y" is necessary, or you just have a weird way of spelling function calls. That's about all I'll require to call something "OO" nowadays.
  - simion314 7y ago
    I think the number of developers that when starting a project start creating some inheritance tree is large. Some concepts work fit inheritance very well like GUI widgets or game entities, you would make a disservice not to tell students about the concepts and have them re-invent them. Not sure how other languages do it, but in my daily work the only time I use inheritance is with an ORM , to get the magic to work you need to extend the base Model class , add a few lines of configuration code and you are done, for more advanced uses I think you have to override some methods. But except the ORM code I don't think I used inheritance in a long time, though I used interfaces in some other cases.
    - LessDmesg 7y ago
      I think we need to separate inheritance trees (arbitrary depth of inheritance) from mixin/trait inheritance which has height = 2. The latter is a lot more useful in eg. games where objects are assembled from mixins like Legos. The former leads to fragility, class bloat and other problems (remember MFC...). Basically, GUI frameworks are the only area I know where OOP - real, authentic long inheritance chains with encapsulation and extensibility - has worked well.
- LessDmesg 7y ago
  Nope, that's not a class, that's a struct and a module with functions. Any method called as obj.foo(5) is really just a function foo with a hidden argument foo(obj, 5). Rust makes this architecture explicit with its structs and trait impls separated - and no OOP in sight. Classes, on the other hand, are not structs with functions. More like black boxes whose contents can be swapped out at any moment. OOP is about hiding implementation and infinite extensibility.
  - simion314 7y ago
    I do not know Rust but this seems an implementation detail, like if I would make the Vector.normalize function static and then pass the this as an argument. Sometimes this pattern with static function works well too. My classes also have private methods and sometimes even private static pure functions. Anyway you Rust people do whatever you want and call them whatever you want , I will call a struct with methods a class.
nickthemagicman 7y ago
Nope. This was just an extremely simple case of domain separated parameters with domain specific functionality pertaining to those parameters. When you have 100+ parameters to deal with it helps in multiple ways to separate those out into domains and classes are a useful tool for that.
- LessDmesg 7y ago
  Ok, good to know. I was afraid that actual full-scale OOP was what saved the day, but it was unnecessary yet again.
  - nickthemagicman 7y ago
    haha very true. I probably could have used it if I got super hard core about separating my domains up but it just seems to over complicate things.

agumonkey 7y ago

> In school they taught classes and inheritance like it was the biggest thing since sliced bread. they even had to dance around how to have a main entry point in class only languages like java the early 2k were really religion blinded around a class god, without teaching the real values and uses of classes in the context of problem solving

tannhaeuser 7y ago
Not even 2k, it was a thing in 1990s already. I remember a student coming in to the company I worked with around 1993/4. His thesis was about O/R binding frameworks and approaches for relational DBs. Generations of developers have drank the "impedance mismatch" and other OOP pseudo science koolaid since.