3 ms·
Eh. Most processes in the physical world are reciprocal and most relationships bidirectional. OOP wants you to add a method to one class. So you're either figur
by humanrebar 8y ago
Eh. Most processes in the physical world are reciprocal and most relationships bidirectional. OOP wants you to add a method to one class. So you're either figuring out which billiard ball gets the 'collide' method call or you end up modelling very abstract concepts like CollisionPolicy and the "real world modelling" starts looking more and more like functional abstractions OnlyWithMoreNouns.
- dtougas 8y agoIf you are giving your ball a collide method, or creating a CollisionPolicy, then you are probably doing it wrong. Therein lies a huge part of the problem of OO design: modelling is difficult, and lots of us get it wrong. Just because you use FP or some other paradigm does not automatically mean you will get it right. I have seen poorly modelled solutions written in many different languages. I have also seen elegant solutions implemented in a variety of forms as well. I think that having some depth of experience in a language, as well as a solid grasp of the problem, and perhaps some anal retentive tendencies (i.e. an innate desire to keep things very structured and consistent), can go a long way to solving problems elegantly :-)
- exergy 8y agoYeah, as with everything, I guess languages need balance. In the case of Modelica (and others inspired by it), we can have functions that are not part of any class at all. So, you could just have a function called evalCollision that accepts two instances of the class BilliardBall and calculate the net result. My main point, though, was that these new languages are way better than Simulink etc. that went before them.