4 ms·

I totally agree that class hierarchies are mostly a trap, especially when there's more than one developer on a project. What I don't understand is why many pro

I totally agree that class hierarchies are mostly a trap, especially when there's more than one developer on a project. What I don't understand is why many programmers still use classes even when they plan on avoiding inheritance. I've seen this sort of thing on the past few major projects I've been involved with; initial creators heavily relied on inheritance, future developers realize that was a mistake, then said future developers continue using the class construct of whatever given language. At that point, why not just use functions and regular objects? Without inheritance, classes tend to have these other rules and complications that don't seem to really add anything when there is no hierarchy.

bhouston 2y ago
> At that point, why not just use functions and regular objects? Without inheritance, classes tend to have these other rules and complications that don't seem to really add anything when there is no hierarchy. I have done this myself. In TypeScript I would write a class that supports an interface. There is no hierarchy, but writing as a class gives it structure, a clear name, you know how to instantiate it, what it supports, private methods, private state, static functions, etc. So I find that classes still do great encapsulation for mutable objects.
AnimalMuppet 2y ago
OO was created for a reason. Before OO, you had these data structures, and they got passed around between functions. Well-designed data structures were not just a random collection of items - they had a relationship between the elements. And you kept finding structures that were in an invalid state - the relationship among the elements had been broken. Well, who did that? You couldn't tell. It could have been any function anywhere in the code that took the structure. With OO, you could have a very small set of functions that could change the structure. If the constraints got broken, you had a very small footprint to look at to see how it could have happened. That was the OO advantage. And this advantage did not go away with multiple programmers. In fact, it increased. If you had a class that you "owned", some other new (or incompetent) programmer could not break your code without changing that class's code. You didn't have to rely on everyone else always doing the right thing with your structure. Note that this advantage is orthogonal to inheritance vs. non-inheritance.
- bhouston 2y ago
  > And you kept finding structures that were in an invalid state - the relationship among the elements had been broken. Which is why functions should have typed arguments and results. :)
- sirwhinesalot 2y ago
  Encapsulation is not solely an OOP idea, it's also a modular programming thing. That many languages lack proper module support is a whole other matter. But there are many advantages to doing encapsulation through modules over classes, if nothing else being able to have the internal functions organized in different files, and having "internal"/"external" functions have the exact same syntax without needing hacks like extension methods.
- DeathArrow 2y ago
  > OO was created for a reason. Likewise, null was created for a reason. Not a good reason.

bhouston 2y ago

> At that point, why not just use functions and regular objects? Without inheritance, classes tend to have these other rules and complications that don't seem to really add anything when there is no hierarchy. I have done this myself. In TypeScript I would write a class that supports an interface. There is no hierarchy, but writing as a class gives it structure, a clear name, you know how to instantiate it, what it supports, private methods, private state, static functions, etc. So I find that classes still do great encapsulation for mutable objects.

AnimalMuppet 2y ago

OO was created for a reason. Before OO, you had these data structures, and they got passed around between functions. Well-designed data structures were not just a random collection of items - they had a relationship between the elements. And you kept finding structures that were in an invalid state - the relationship among the elements had been broken. Well, who did that? You couldn't tell. It could have been any function anywhere in the code that took the structure. With OO, you could have a very small set of functions that could change the structure. If the constraints got broken, you had a very small footprint to look at to see how it could have happened. That was the OO advantage. And this advantage did not go away with multiple programmers. In fact, it increased. If you had a class that you "owned", some other new (or incompetent) programmer could not break your code without changing that class's code. You didn't have to rely on everyone else always doing the right thing with your structure. Note that this advantage is orthogonal to inheritance vs. non-inheritance.

bhouston 2y ago
> And you kept finding structures that were in an invalid state - the relationship among the elements had been broken. Which is why functions should have typed arguments and results. :)
sirwhinesalot 2y ago
Encapsulation is not solely an OOP idea, it's also a modular programming thing. That many languages lack proper module support is a whole other matter. But there are many advantages to doing encapsulation through modules over classes, if nothing else being able to have the internal functions organized in different files, and having "internal"/"external" functions have the exact same syntax without needing hacks like extension methods.
DeathArrow 2y ago
> OO was created for a reason. Likewise, null was created for a reason. Not a good reason.