5 ms·
Usually, I follow a general rule of thumb: * For domain language (entities, services, value objects) use OOP as it is better at communicating intent * For dat
by tasubotadas 8y ago
Usually, I follow a general rule of thumb:
* For domain language (entities, services, value objects) use OOP as it is better at communicating intent
* For data processing and low-level algorithms (usually happens inside OOP methods) use FP style as it is less error-prone.
- gardaani 8y agoI found an article which has similar rules: * Use FP when you need to build something purely computational. * Use OOP when you want/need to build something generic for other people to use. * But if you are application or game developer, ECS way of thinking brings a lot of benefit to the table. https://hackernoon.com/when-not-to-use-ecs-48362c71cf47 https://hackernoon.com/when-not-to-use-ecs-48362c71cf47
- yogthos 8y agoI have to disagree here. It's much easier to use data driven APIs than OO ones. With the former you get what you see and there are no additional rules. You call the API, it produces some result that you can use in any way you like. Meanwhile, objects have behaviors and internal state that you have to understand because each object is its own ad hoc DSL with its own rules and behaviors.
- danmaz74 8y agoI write mostly Ruby these days, and this is my approach too. I usually write the pure functions as class methods. It would be great if it was possible to declare a function "pure" and have checks that it only uses pure functions itself - although this would be impossible to guarantee with Ruby, given its extremely dynamic nature.
- UK-Al05 8y agoI would read Domain modeling made functional. I wouldn't go back to domain modelling in a oop language after that.