From c86b547c4aa3a342ad5832da960728e504850226 Mon Sep 17 00:00:00 2001 From: Mihai A Date: Mon, 26 Feb 2024 09:05:34 +0200 Subject: [PATCH] Update 2018-04-17-dolls-and-maquettes.markdown --- _posts/2018-04-17-dolls-and-maquettes.markdown | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/_posts/2018-04-17-dolls-and-maquettes.markdown b/_posts/2018-04-17-dolls-and-maquettes.markdown index 8f07340..3ae963d 100644 --- a/_posts/2018-04-17-dolls-and-maquettes.markdown +++ b/_posts/2018-04-17-dolls-and-maquettes.markdown @@ -31,7 +31,7 @@ One more way we can look at model objects is the following: they are either **do But why can't *they* work for us? Why can't we design them so they *move*, thus liberating us from the burden of having to cater for them, having to write all those procedures *for* them? With this mindset, we won't sit around trying to fix a 500 LoC method, or trying to figure out how to test that Service class. Instead, our work will be much more like the one of an engineer: we will have to design, implement, test and fix objects, not procedures, not spaghetti code. -Here is how I see it: a software developer and an engineer are given the same task, they each have to build a ``Car``. The engineer will build a real ``Car`` which will actually move, accelerate etc. On the other hand, the software developer will just look at the requirement, cast a model of a ``Car`` and then proceed to build all sorts of tools *around* that model, that should make it move and gain some speed... I personally imagine a room filled with beams and strings attached to the lifeless model. Also, there would probably be a lever that would have to be operated by someone in order for the "car" to do something -- all those beams, strings and the lever are the helper methods and service classes from an application's code. +Here is how I see it: a software developer and an engineer are given the same task: they each have to build a ``Car``. The engineer will build a real ``Car`` which will actually move, accelerate etc. On the other hand, the software developer will just look at the requirement, cast a model of a ``Car`` and then proceed to build all sorts of tools *around* that model, that should make it move and gain some speed... I personally imagine a room filled with beams and strings attached to the lifeless model. Also, there would probably be a lever that would have to be operated by someone in order for the "car" to do something -- all those beams, strings and the lever are the helper methods and service classes from an application's code. The comparison may sound crazy but that's what it is: mainstream OOP just gave people the tools necessary to put a label on their data while letting them maintain their procedural way of thinking. Instead, real object orientation is a complete switch of mindset: you go from the position of the manual worker to the position of the engineer who designs objects that actually solve issues, automate things.