braindump-oo

gistfile1.txt

***** Ideas from [[http://vimeo.com/91672848][this talk]]:
      In the small, its easy to apply solid and stuff.
      How should we be using this ?????

      => its terribly easy to write procedural code using object oriented languages.

      => OO is a method to:
      control the intellectual load of understand our systems.
      extensible, reusable, simpler

      => OO should be strutured so that the behavior emerges from COMPOSITION of
      objects.

      => Classes and inheritance: TAXONOMY SUCKS! works for animals but not on
      stuff. Fuck taxonomy, focus on behavior! (messages)

      => Methods are about flow control, and messages are about communication

      => Encapsulation and information hiding forces you to structure your system in a
      sense that hinders you to poke in the internals of something, allowing you to be
      uncoupled from the current logical state of the system. (Refactoring my friend.)

      => Roles! An object has roles, which may or may not be related to its taxonomy
      (fuck taxonomy!)

      => Focus on WHAT never HOW.

      => The calling object should described *what* it wants in terms (in the
      language) of the role that its collaborator plays, and let the called object
      decide how to make that happen. An object should *depend* on ROLES and not
      on classes.

      => First, identify the operations you need done (messages!) and THAN you decide
      which objects you want responding those messages, and THAN you
      classify/taxonomize them.

      => The big blob god object responding to all messages is one such way to
      organize the code. (ALSO, THIS IS EXACTLY WHAT HAPPENS IF YOU WORK IN A
      FUNCTIONAL STYLE!! Your methods become functions, and as long as you do not
      share state, you're fine.)

      (*
      from wikipedia: [http://en.wikipedia.org/wiki/Object-oriented_programming]
      Object Oriented Programming puts the Nouns first and foremost. Why would
      you go to such lengths to put one part of speech on a pedestal? Why should
      one kind of concept take precedence over another? It's not as if OOP has
      suddenly made verbs less important in the way we actually think. It's a
      strangely skewed perspective.
      *)

      (*
      See that extremely factored oo code tends to look just like functions! If
      they have exactly one nittypicky reason to change implementation, you're
      probably stripping PURPOSE in so many places. And that's EXACTLY the
      Achilles' heel of functional programming.
      *)

      (*
      Another way to think on SRP is 'single-purpose-principle' (!).
      Responsibility is a much more volatile term. When we get to high levels of
      factoring the objects tend to look much like 'action makers', 'doers of
      stuff', exactly what functions are. The whole idea of object orientation is
      to group operations that fulfill the same 'purpose' in close together, that
      is, group those operations in a *cohesive* manner. This thought agrees much
      with Diogo Lisboa's article on late binding and passing unnecessary
      dependencies in the constructor (he tends to think in a more functional
      landscape).
      *)

      (*
      !! EUREKA !!
      Engineering is the art of composing parts into a solution to a problem.
      The engineer is the guy that walks seamlessly between the large and the small,
      (the whole and the part, recursively). He is the guy that looks in the small
      without forgetting about the whole, and looks in the whole without
      forgetting the small.

      By factoring parts in /reusable/ ways, that is, by creating parts that are
      context-free, the engineer is able to think at higher levels of
      abstraction and re-executing his familiar compositional ballet, but now,
      ignoring more and more details.

      Remember the fact that I said 'no human being actually *knows* how a Macbook pro
      works in all the detail there is to it. But FUCK THAT. That DOES NOT stop me
      from building amazing things, because I have well factored components that
      insulate me from all the hassle of the overwhelming (and, by someone that
      is, well understood) detail'

      Also, associate this with the myth of the rockstar know-it-all programmer.
      No software developer will be able to hold all the nitty-gritty details of
      the code itself. The main point of abstraction is that it allows one to
      stand on top of what is *collectively* well understood. The engineer
      concerns itself on how to delegate knowledge to others so that he can
      stand on top of it and build things. This is a fundamental departure from
      the more scientific approach of understanding the fundamentals to the
      core. This is probably a good explanation on why engineers are not
      scientists and vice-versa.

      Software programming is the ultimate form of engineering, giving form to one's
      thought and freeing him/her of the boundaries of the physical world. Fuck
      all those materials, I can give form to my mind models.
      *) => Malleability, extensibility and re-usability!

      Context independence => reuse

      Decorator, dependency injection and ROLES, this combination enables
      the *open-closed-principle* (the /O/ in SOLID).

      LAW OF DEMETER => (often simplified to 'no train wrecks,
      =a.b.c.d.e.f.g.h.h.do_stuff()=) By going 'too-deep' in the object graph, we
      are now completely coupled to =a='s structure. (I can actually *say* that
      =b.c.d.e.f.g.h.h= is part of the specification, but that's stupid and does
      not help moving towards the results we aim to achieve by using OO
      (extensibility, risibility, high cohesion, loose coupling and so on and so
      forth))

      DEMETER => is more of a guideline, and focus on the fact that objects should
      know the least amount of information possible to fulfill its purpose, that
      is DON'T TALK TO STRANGERS! (cause they're only there, to do you harm.) be
      anti-social.

      First object oriented programming was SIMULA. Simula was made for simulating
      things. We, when doing business line applications SIMULATE the business into
      the systems in such a way that the business *becomes* the system. (talk
      about virtual reality motherfuckers). I have worked with simulating chemical
      processes, process controllers, bla bla bla. That is probably why I feel so
      inclined in designing object oriented systems.

      Example of well factored behavior; The traffic light coordinates sooo many
      things, and yet, it knows only about its lights and the passage of time.

      In order to make stuff simpler \/

      Distributed cooperation and communication must replace hierarchical
      centralized control as an organizational paradigm. (Think about the AI
      class, where there is an example where the godamn ghosts catch pacman
      without talking to each other, but by having a *model* of how the fuck the
      other ghost would behave given the current state of the world. GODAMNit this
      whole writing down thing is AMAZING). The whole ghost thing is an example of
      'blind trust'. Do not try to control more than you need. Give up procedural
      control.

      Beware with top-down approaches: they tend to be closely linked to the
      immediate context that led to their development! The roles end up being too
      specific.