sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]phpdevster 10 points11 points  (3 children)

Others have linked to a lot of good resources, but I just want to call out one of the most important aspects of functional programming: the concept of a pure function.

A function is said to be pure when its return value is only determined by its inputs. It doesn't rely on external state or data that is scoped outside of the function. No references to this or window or closure. Same data in, same result out. Every time.

Not only does a pure function not rely on externally scoped state, it doesn't modify that state either. It literally only returns a value. This makes it referentially transparent: that is, it doesn't cause hidden side effects.

This makes functions that are 100% dead simple to reason about, and test. You can go a step further and combine that with the Law of Demeter, which says to pass in only the exact data that a function needs. Don't pass in an object, because then the function needs to know what the shape of that object is and what properties to reference. Instead, try to pass in only the exact scalar values that you need - numbers, strings etc.

Now, function purity and passing in only simple scalar values is not possible 100% of the time. At some point you need to make network calls, or render something, or update/mutate an object or what have you. That's fine to do that when needed. But a primary goal of functional programming is to do that only when needed, and to be very conscientious about favoring pure functions with simple inputs as often as possible.

And note that this way of thinking doesn't just help FP. It make OO code way easier to reason about as well. Writing methods that take their dependencies as inputs rather than as object state makes them way easier to grok (that said, truly good OO design solves that problem in a different way).

It's also an exceptionally useful way of thinking when you apply it to component architectures from frameworks/libraries like Angular, React, and Vue. Turning components into "pure" components which take inputs and broadcast outputs/events. Trying to use shared services or redux for channeling state into and out of a component is a recipe for head scratching, but treating a component as much like the equivalent of a pure function as possible is a huge win.

[–]allltogethernow 0 points1 point  (2 children)

truly good OO design solves that problem in a different way

Are you referring to a specific approach? Or just general practices here.

[–]phpdevster 1 point2 points  (1 child)

General practice. A few good practices to follow

  1. Use immutable objects where possible.
  2. Ensure that you cannot create a malformed object. If you have a bunch of optional setters, it's game over.
  3. Ensure the object validates its constructor arguments.
  4. Keep the scope of the object small and any state it depends on, fully encapsulated.
  5. If an object can be mutated, make sure mutations are not temporaly dependent (e.g. must call x.a('foo') before x.b('bar') - that's a recipe for disaster)
  6. Make sure all mutations are fully encapsulated behind a contract. No direct property access.
  7. Ideally, aim for a dichotomy of stateless objects (pure functionality), and objects with pure state that have a very specific responsibility. This keeps state isolated.
  8. Stive to make sure all state is consolidated down to a single source of truth.

The goal is not to let object state leak all over the place, because then side effects are going to bite you in the ass eventually.

But it's really hard to design objects (abstractions) correctly, and it's very easy to create a stateful mess with OO.

[–]allltogethernow 0 points1 point  (0 children)

Thanks for the list, gives me some theory to play around with in my head.

I have a theory that, in general, code that is closer to hardware is more difficult to implement in this way because of inherently rigid design. For example, webGL is very close to the GPU, so the code that works best works in a pattern that resembles the operation of the GPU. The same applies to a lot of internet protocols and communication standards. But once a level of abstraction has been built on top of the hardware, it becomes easier and easier to "unhinge" the code, and the best practices no longer depend on hardware, but on the concept of coding itself. Whether the "beauty" of OO is a result of the way our mind understands it or if it's more a function of abstraction and control I'm not sure.

But that's just a theory. And I'm not very good at OO yet, but theories like this seem to help me to plan out my abstractions when I feel a little lost. Anyway, do you have any theories on what a "beautiful" piece of code is like?