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

_posts/2018-04-17-dolls-and-maquettes.markdown

@@ -31,9 +31,11 @@ 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: an engineer and a software developer 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.
+The software engineer did not actually build a ``Car``, because he didn't understand the principles applied by the engineer, which are: abstraction, encapsulation, decoupling, cohesion etc. Object orientation was supposed to take the principles used by the engineer and bring them in the coding/software development realm. However, thinking in a procedural manner, our developer merely managed to make the maquette of a ``Car`` somewhat behave like a real one - even if the developer managed to follow all the ``clean code`` recommandations, his/her final work would still not be a real car: it would still be a lifeless model "operated" by some beams and strings, just maybe with some good cable/beam management.
+
+The comparison may sound crazy but that's what it is: instead of teaching them real, practical engineering principles, 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.
 
 <figure class="badge-right"><img src="/illustrations/robots.png" style="width:64px;max-width:100%;" alt="Robots"></figure>