Update 2018-04-17-dolls-and-maquettes.markdown

_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.