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

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

@@ -27,7 +27,7 @@ and some imagination. Yes, I believe that, in order to be good OOP programmers,
 
 <figure class="badge-right"><img src="/illustrations/puppet.png" style="width:64px;max-width:100%;" alt="Dolls and Maquettes"></figure>
 
-One more way we can look at model objects is the following: they are either **dolls** (``User``, ``Student``, ``Partner`` etc) or **maquettes** (``Car``, ``Phone``, ``Book`` etc). Question is, how can we work with them, how do they help us solve any problem? The answer is simple: we can do nothing with them and they don't help us in any way other than offering some readability! They just sit around, waiting for some helper method or WhateverService class to do something with them, our job being to design that method and that service, procedural code that hopefully will work (because we all know, in enterprise, a decent test coverage is max 40%). We are the ones working to accommodate the models.
+One more way we can look at model objects is the following: they are either **dolls** (``User``, ``Student``, ``Partner`` etc) or **maquettes** (``Car``, ``Phone``, ``Book`` etc). Question is, how can we work with them, how do they help us solve any problem? The answer is simple: we can do nothing with them and they don't help us in any way other than offering some readability. They just sit around, waiting for some helper method or WhateverService class to do something with them, our job being to design that method and that service, procedural code that *hopefully* will work. We are the ones working to accommodate the models.
 
 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.