OOP - Control vs Implementation

Move decisions up to control and responsibilities down

Published on Apr 10, 2020

Reading time: 1 minutes.


See original post in my LinkedIn

One of my classes at GW this semester is Object Oriented Design, I’m studying today for the exam (even though is open book because we are having remote classes) and I came across the following sentence “move decisions up to control and responsibilities down as far as possible”.

I had seen this in some controller classes or SQL stored procedures in a legacy system I worked with, where everything was in the same file, sometimes extending to thousands of lines. But also in a smaller project.

I remembered a conversation I had with Sean McBride during our distributed systems chord project. At some point during the implementation of the algorithm we had some errors and we were debugging the program. Then I mentioned, “how can we fix this if I cannot even see the algorithm in all these lines”. All the code necessary to handle errors, gRPC calls, etc. hid the code that was implementing the algorithm of the paper and it was hard to follow.

Moving control decisions up and responsibilities down would help in both cases. Keep the control class as minimal as possible, extract code to other functions or classes, you just want control flow, not implementation. You would be able to have a readable class, that gives you a clear high-level idea of what’s going on.