3 ms·
You don't really understand OOP until you recognize it as one style among many that you may use in different parts of each program. Some parts are naturally OO-
by moloch-hai 4y ago
You don't really understand OOP until you recognize it as one style among many that you may use in different parts of each program. Some parts are naturally OO-y, others DD-y, others declarative, often an unholy mix in each place. The problem dictates elements of the solution. Shoehorning a solution into a particular style makes a bad solution.
Never forget who is in charge. Deferring to a style dodges responsibility for your choices.
- ShredKazoo 4y agoDD?
- dopidopHN 4y agoMy guess would be domain driven design. I remember that being all the rage 10ish years ago? I think it works, but I don’t see it much anymore
- bitwize 4y agoDomain-driven or data-driven (not sure which).
- moloch-hai 4y agoData-driven. What weather prediction, finite-element analysis, and current AI do.
- hnick 4y agoPerl's approach to OOP has flaws but it being generally "data structures you already know but with some magic and functions attached" helped me understand it on a more fundamental level. It greatly supports the mix-and-match approach you mention here.