3 ms·

The article is focusing on a few abstract concepts, but here's some actionable rules I've found that work. - When all you need is a function, don't make an obj

The article is focusing on a few abstract concepts, but here's some actionable rules I've found that work. - When all you need is a function, don't make an object abstraction. - Restrict your abstractions to at most 2 levels of depth (a base class and derived). It becomes more intimidating to figure how the flow goes if you have deep object hierarchies. This also helps to encourage forms of composition. - Again, don't make an abstractions that provide little to no value to suit some orthodoxy or perceived 'best practice'.

junon 5y ago
As Jon Skeet put it best, "be pragmatic, not dogmatic". I also love YAGNI - You Ain't Gonna Need It!
fighterpilot 5y ago
+1 for more compositions, just need to manage cyclomatic complexity. Have seen some mind bendingly overcomplicated code where A is in B and B is in A etc.
jolux 5y ago
I find myself making object abstractions more in languages that do not have solid support for functional programming. In OCaml, I can build dozens of useful abstractions off of a handful of small functions by using currying and partial application. Equaling that expressivity in languages that don't support those features requires making objects more often than I would like to, because the alternative is hundreds of overspecialized utility functions that do not compose well and push you towards imperative, stateful styles (I have seen this happen!). I still stick to two levels of inheritance max though, and most of the time I only use interface inheritance. Rarely do I want behavior inherited.
slver 5y ago
The problem with "when all you need is a function don't use an object" is that's it's a recursive definition. There are people who think they need a singleton all the time, imagine where similar definition would have brought them. How a function is defined varies from language to language, but if we're talking about a globally accessible named function, this is in effect a singleton. It means you can't configure this function (through construction parameters), or replace it, or mock it, etc. it's in effect a "singleton function". BTW, abstraction != inheritance.
watwut 5y ago
Purely functional style can be quite difficult to read. Especially when you end up composing functions be partially filling arguments, sending functions as arguments of other functions and so on. Once you get at that level, objects are life savers. Because then state is explicit on code rather then hidden in deep call stack and spread over various levels of it.
gonzo41 5y ago
I would controversially add, - don't use interfaces until you absolutely have to, and then try and find another way. YMMV, but in my corporate experience with OO code, I find a lot of interfaces that have one implementation. It's a waste to plan for a future that doesn't come. I feel we're lacking something like software mindfulness. Where you stay in the moment and just solve the problem.
- jolux 5y ago
  It depends what language you’re in. As long as you can use fakes, it doesn’t matter if you use interfaces or not. In C#, implementations are sealed by default so faking them is not feasible unless you make the function virtual.

junon 5y ago

As Jon Skeet put it best, "be pragmatic, not dogmatic". I also love YAGNI - You Ain't Gonna Need It!

fighterpilot 5y ago

+1 for more compositions, just need to manage cyclomatic complexity. Have seen some mind bendingly overcomplicated code where A is in B and B is in A etc.

jolux 5y ago

I find myself making object abstractions more in languages that do not have solid support for functional programming. In OCaml, I can build dozens of useful abstractions off of a handful of small functions by using currying and partial application. Equaling that expressivity in languages that don't support those features requires making objects more often than I would like to, because the alternative is hundreds of overspecialized utility functions that do not compose well and push you towards imperative, stateful styles (I have seen this happen!). I still stick to two levels of inheritance max though, and most of the time I only use interface inheritance. Rarely do I want behavior inherited.

slver 5y ago

The problem with "when all you need is a function don't use an object" is that's it's a recursive definition. There are people who think they need a singleton all the time, imagine where similar definition would have brought them. How a function is defined varies from language to language, but if we're talking about a globally accessible named function, this is in effect a singleton. It means you can't configure this function (through construction parameters), or replace it, or mock it, etc. it's in effect a "singleton function". BTW, abstraction != inheritance.

watwut 5y ago

Purely functional style can be quite difficult to read. Especially when you end up composing functions be partially filling arguments, sending functions as arguments of other functions and so on. Once you get at that level, objects are life savers. Because then state is explicit on code rather then hidden in deep call stack and spread over various levels of it.

gonzo41 5y ago

I would controversially add, - don't use interfaces until you absolutely have to, and then try and find another way. YMMV, but in my corporate experience with OO code, I find a lot of interfaces that have one implementation. It's a waste to plan for a future that doesn't come. I feel we're lacking something like software mindfulness. Where you stay in the moment and just solve the problem.

jolux 5y ago
It depends what language you’re in. As long as you can use fakes, it doesn’t matter if you use interfaces or not. In C#, implementations are sealed by default so faking them is not feasible unless you make the function virtual.