OOP

Posted by moodyharsh on 2016-06-06

“There’s a good part of Computer Science that’s like magic.
Unfortunately there’s a bad part of Computer Science that’s like religion.”
― Hal Abelson

OOP / OOAD is intrinsically tied to an object’s life cycle.

One can distinguish between two life cycles

  1. Flat

a creates b
a uses b
a closes b

This facilitates layered Architecture.

Model View Controller
Domain Application Service

This is OK till you need Workflow Processing (Checkout).
A typical Workflow spans more than 2 disjointed or concurrent steps.

Also, building a new layer is a long process.

  1. Nested

An object sent n-levels down may gives rise to

  • Circular References
  • Memory Leaks
  • Data Corruption
  • Inability to add new operations since it’s already entrenched.

It is a major pain to debug.

Another problem is two-way, or even one-way communication with previous levels.
Legacy code is sprinkled with using exceptions as one-way communication.

Design patterns hide the problems.

A company X and a priest Y will announce a Framework Z.
After 5 years the company will ditch Z and use W.
You did not use OOAD DDD DI MVC MVP MVVM ABC properly.

Engineering

Raw Material -> A Real Factory
-> Assembly Line
-> Construction
-> Split Raw Materials
-> Make Parts Concurrently
-> Assemble
-> Quality Check
-> Product
-> Package Product

An Engineering Product stands for itself.
Only Game Programmers come close to this.

The irony is, Assembly Programmers used these techniques.

Assembly Programmers dealt with primitive indestructible values
and Pointers.

  • Storage Management
  • Memory <-> Processes <-> Device

The Device part is where (Flat) OOP is a great fit.
(infact a file interface is all you need)

The Storage Management part is where OOP is OK.
The Memory <-> Process part is where OOP fails.

This can be solved by Data Process Patterns

  • Micro Kernel

Used in Real Factory Controllers.

  • Entity Systems

The Game Programming way.

  • Data Flow

Used in domains like Avionics, Electronics Softwares.

  • Stream Processing

XML / Unix

  • Actor Model

Used in Telecommunications, WhatsAPP.
golang.

  • Workflow Engine
  • Active Object Pattern

Inevitably, in “Enterprises”.

  • PAC

Drupal. Yes Drupal.

  • MVC + Smalltalk

It is pointless to talk of MVC-smalltalk without smalltalk.
smalltalk has a very elegant and actor-like object communication model.

  • Co-routines

Simula had it. Why on earth this was wasn’t included in C++ baffles me.

  • Hierarchical Control Systems / Agent Oriented Programming

and many many more !

see Data-Oriented Design

What is the bloody point of all this ?

If you want to be a Software Engineer

  1. Use OOP, if you have to, for low level layers

  2. Don’t fall into SP, OOP, OOAD, DDD, FP or any religion

  3. Engineering is about building complete Products with

    • Systems
    • Sub Systems
    • Inout / Output

    There is a huge creativity here, doing this efficiently.
    Don’t let the framework rob this from you.

  4. A Lot of programmers have built complex reliable Systems without
    without OOAD or FP in tiny teams.

    Consider the screenplay for Schindlers list. It has ~~ 6k lines, written
    by one guy probably.

    A 16kb total-scripts-size can be a good upper limit for a single programmer.

  5. Pick new Data Process pattern and make it your own.

The point is, you can do Engineering and it’s not that difficult.

$ cat log.txt | grep foo | wc -l

You already use engineered components that work together, everyday.