4 ms·
OOP abstracts pieces of functionality into objects, which is closer to how we view the real world. It is often much easier to think about code that has been abs
by theaustinseven 10y ago
OOP abstracts pieces of functionality into objects, which is closer to how we view the real world. It is often much easier to think about code that has been abstracted into objects, given that good abstractions have been made. This makes code re-usability more well organized. This all breaks down, however, when the task at hand is not well suited to OOP(think data science). If the number of abstractions per amount of code gets to be too great than OOP starts to become somewhat detrimental. In this case Functional would be easier to read and have more efficient abstractions.
- Chris2048 10y agoI think the first point is precisely why OOP is dangerous: https://en.wikipedia.org/wiki/Reification_(fallacy) https://en.wikipedia.org/wiki/Reification_(fallacy) It may be initially easier to model a problem with 'Nouns', but this won't necessarily reflect the structure of the implementation, which is what I think the code should reflect. http://homepage.ntlworld.com/christopher.mallagh/INCKy/OrgPrelIntro/Intro/PlatFal.html http://homepage.ntlworld.com/christopher.mallagh/INCKy/OrgPr... Sometime the abstractions aren't quite as perfect in their implementation as modelled in the mind. Then you realise you need to model implementation differently from domain, and the difference between the two can cause issues (leaky abstractions, shared-encapsulated state, etc). To put it another way, information should be communicated using concepts from the way people thing about the problem, and the code can communicate this, but the actual structure of the code should reflect the implementation. the same kind of thing that can happen in ORMs wrt the actual difference between object-hierarchy structures, and relational database structures...