Re:The Case Against OOP Is Wildly Overstated
by TimMurnaghan on Friday July 31, 2020 @02:51PM
(#24012350)
That's true - but where do you put the function? In a complex system I can end up with loads of these totalling functions scattered about. I might have gross and net versions of the total and, given human nature, they get created near the use of them. The variants then get duplicated.
The objects give you a modular structure which means you can see the interface.There is a disconnect when you have to shift to the object - but you can also see when to refactor.
Re:The Case Against OOP Is Wildly Overstated
by joshuamorton on Friday July 31, 2020 @03:08PM
(#24012596)
There are a few answers for this: you might include common ones in the same file as the struct (see rust for how this looks, usually).
Re:The Case Against OOP Is Wildly Overstated
by zozbot234 on Friday July 31, 2020 @03:09PM
(#24012607)
> This maintains the invariant without state.
Yes, but this is not possible in general. For instance, what if you want to endow your List with a "MaxTotalCost", set at creation. You can't ensure that your list respects that invariant, other than by encapsulating it behind some custom interface.
Re:The Case Against OOP Is Wildly Overstated
by joshuamorton on Friday July 31, 2020 @03:24PM
(#24012814)
That's true, although it raises a question: is the maximum you're willing to spend a trait of your bill of materials (I'd argue no), or of some other thing, for example your overall project. In that case you could have a method that validates your BOM against your project requirements.
There's a potential performance cost here, but that usually doesn't matter a whole lot.