Hacker News new | past | comments | ask | show | jobs | submit login

This is just functional core, imperative shell. Which is to say, keep generic, immutable things generic and immutable. Build libraries to implement ideas and concepts in your domain. And then when it comes time to implement the high-level business logic, use an imperative shell to harness the power of all of those concepts you created. Keep it logical, straightforward, easy to follow, and well organized.

Like the author says, OOP is an organization tool more than anything and like "strategy," "adapter," "Command," "builder," etc signal specific things to your colleagues that IMPROVE understanding and time-to-grok.




Thanks for identifying the paradigm.

I've been working on refactoring some code, and I really like the functional style so originally wrote most of the logic in discrete functions. Multiple functions rely on some similar dependencies so there are some unique parameters for the function and then a handful of parameters that are the same for all functions (stuff like a database connection). It seems good that each of these functions can accept those dependencies in the signature, but it's likely that each of those functions is going to need that same dependency for the whole pipeline. At some point it looks to me like a small object that can handle the initial setup and management of those dependencies is helpful. Functional core imperative shell seems kind of like what I'm doing? Others mentioned there is some merit to being able to reduce the state from global to local in some form and OOP may be a useful for that case. Recommendations for other ways to handle these situations would be helpful as it's possible I'm only reaching for an OOP wrapper because that's what I know.


A classic worth watching if any of you haven't seen it! https://www.youtube.com/watch?v=yTkzNHF6rMs




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: