tag:blogger.com,1999:blog-13967713.post4967524377527429317..comments2016-05-11T20:05:39.322+02:00Comments on Carlo Pescio: Your coding conventions are hurting youCarlo Pesciohttp://www.blogger.com/profile/12652284939993729858noreply@blogger.comBlogger56125tag:blogger.com,1999:blog-13967713.post-64892039149233486632016-03-11T18:35:43.069+01:002016-03-11T18:35:43.069+01:00This comment has been removed by a blog administrator.Hanhttp://www.apkmonk.com/app/com.luisrodriguezneches.stackbrowser/noreply@blogger.comtag:blogger.com,1999:blog-13967713.post-16919219544521069492015-02-20T16:43:33.147+01:002015-02-20T16:43:33.147+01:00This comment has been removed by a blog administrator.abhi@likecodinghttp://www.similarto.us/stackoverflow.com/noreply@blogger.comtag:blogger.com,1999:blog-13967713.post-78397306764833642732014-08-18T14:55:57.515+02:002014-08-18T14:55:57.515+02:00This quote popped into my mind:
"When a true...This quote popped into my mind:<br /><br />"When a true genius appears, you can know him by this sign: that all the dunces are in a confederacy against him."Jonahnoreply@blogger.comtag:blogger.com,1999:blog-13967713.post-88990283615932235182014-08-18T13:59:49.878+02:002014-08-18T13:59:49.878+02:00well Petar, this is what Seth Godin would say: htt...well Petar, this is what Seth Godin would say: http://sethgodin.typepad.com/seths_blog/2014/06/its-not-about-you.html<br />it's just not for you : )<br />Carlo Pesciohttps://www.blogger.com/profile/12652284939993729858noreply@blogger.comtag:blogger.com,1999:blog-13967713.post-48366044581012035732014-08-18T13:35:42.357+02:002014-08-18T13:35:42.357+02:00hardly have I seen so much bla bla bla and no esse...hardly have I seen so much bla bla bla and no essencepip010https://www.blogger.com/profile/01451646330176713157noreply@blogger.comtag:blogger.com,1999:blog-13967713.post-9127628177846849672014-07-21T22:58:54.107+02:002014-07-21T22:58:54.107+02:00This comment has been removed by a blog administrator.Dina@fat-cow-hostinghttp://bluepromocode.com/fatcowhosting/noreply@blogger.comtag:blogger.com,1999:blog-13967713.post-29679034869413650432012-12-24T16:29:20.078+01:002012-12-24T16:29:20.078+01:00Jonah:
but don't you still need a container t...Jonah:<br /><br /><i>but don't you still need a container to hold the list of those objects</i><br />--<br />Simple answer: the Constrained object may very well hold its own Constraints.<br /><br /><br /><i>and to iterate through them, sending a message to each like "validate()"?</i><br />--<br />Simple answer: the Constrained object can do this.<br />More interesting / challenging design: a Constraint is probably checking some Condition, based on some Variables. When a Variable changes, the Constraint must be re-evaluated. Do we need a manager / engine to do that? Why is not the Variable informing the Constraint?<br /><br />In practice, some languages get in the way when implementing smart variables. For instance, two languages I'm using a lot have both an int and Integer type, the first is the usual "fast" thing, the latter is "an object", but they wasted the opportunity to make that object a little smarter :-). <br />Understanding the physics of software, and the basic idea that very often we want to react when a value is changing, could bring some simple (yet very valuable) changes into programming languages. When we have to create a different class, set up an observer, etc just to get a notification, we might be tempted to go the "manager class" way. Things would be different with a more supportive language :-)<br /><br />By the way guys: Merry Christmas!Carlo Pesciohttps://www.blogger.com/profile/12652284939993729858noreply@blogger.comtag:blogger.com,1999:blog-13967713.post-27392895967945693872012-12-23T16:13:12.472+01:002012-12-23T16:13:12.472+01:00@Jonah, I never read that one. I saw a post some t...@Jonah, I never read that one. I saw a post some time ago with a list of recommended books at <br /><br />http://blog.mattwynne.net/2012/07/26/triangulating-from-goos-great-books-on-object-oriented-design/<br /><br />Matt's post on the mailing list:<br /><br />https://groups.google.com/d/msg/growing-object-oriented-software/rruIYEQvLBE/P4HKwdJWUmUJ<br /><br />and a related one<br /><br />https://groups.google.com/forum/?hl=en&fromgroups=#!msg/growing-object-oriented-software/eP_kQNEOkog/hJfLHCAGBvUJ<br /><br />Matt's post led me to Object Thinking by David West. I found it a bit strange, digressing, and profoundly enlightening. I need to read it again. YMMV. :)<br /><br />On a seasonal note Merry Christmas to all, and once more, thank you Carlo, for the effort you've been putting into your blog and into teaching these concepts. David Lealnoreply@blogger.comtag:blogger.com,1999:blog-13967713.post-73757004690826615462012-12-14T09:57:42.200+01:002012-12-14T09:57:42.200+01:00@carlo: I see the comment now. And yes, it makes ...@carlo: I see the comment now. And yes, it makes sense for the constraint logic to reside in the Constrained objects, but don't you still need a container to hold the list of those objects, and to iterate through them, sending a message to each like "validate()"?<br /><br />@david: Funny you mention that book. I purchased it about 2 weeks ago and just finished it. I think it is a fabulous book and gave me a number of new insights even after many years of OO programming and reading a decent number of other books.<br /><br />I think next up might be Chamond Liu's "Smalltalk, Objects, and Design" -- any thoughts on this? It seems most of the best OO books are the old onesJonahhttps://www.blogger.com/profile/11083890895972179187noreply@blogger.comtag:blogger.com,1999:blog-13967713.post-50517319160689528602012-12-11T12:03:18.275+01:002012-12-11T12:03:18.275+01:00Not sure if this helps, and I don't know what ...Not sure if this helps, and I don't know what Carlo's opinion is, but one of the books I really enjoyed reading lately is "Practical Object Oriented Design in Ruby". It's a very down to earth approach, it's an easy read and covers a lot of ground.David Lealnoreply@blogger.comtag:blogger.com,1999:blog-13967713.post-6147526345084752262012-12-10T19:02:44.859+01:002012-12-10T19:02:44.859+01:00Jonah: as I mentioned to Fulvio above, the Constra...Jonah: as I mentioned to Fulvio above, the Constraint / Constrained things was mostly meant as: <i>find a better design where a ConstraintChecker is not needed at all :-).</i><br /><br />About the reading list: David question was more about “analysis” than OO, but every so often, someone is asking me for a list of “must read” books on OOP as well. It’s a tough question, because the real “must read”, in my opinion, are books from the 80s or early 90s, but when I began making a list, I realized that, yeah, sure, a book is a “must read” but perhaps only chapter 2 because the rest is obsolete, etc. So a good list should be more detailed and reasoned than just a sequence of titles. At that point, to be honest, I gave up :-(. Guess I need to give myself a motivational kick :-))Carlo Pesciohttps://www.blogger.com/profile/12652284939993729858noreply@blogger.comtag:blogger.com,1999:blog-13967713.post-55802453349645368192012-12-08T07:29:37.234+01:002012-12-08T07:29:37.234+01:00How about "ConstraintGuard"... like a se...How about "ConstraintGuard"... like a security guard at a party, who goes around and throws out all the people who don't belong there anymore?<br /><br />Also have you ever gotten around to making that reading list? I'd love to see it. Especially: What do you consider the must-read books on OOP?Jonahhttps://www.blogger.com/profile/11083890895972179187noreply@blogger.comtag:blogger.com,1999:blog-13967713.post-73403101563026799932012-09-04T09:58:31.997+02:002012-09-04T09:58:31.997+02:00Re: Constraint/Constrained
Can we call it a Strai...Re: Constraint/Constrained<br /><br />Can we call it a Strainer?<br />I'd like to put my Constrained objects in a Strainer and see which ones are caught (valid) and which ones leak through (invalid).<br /><br />Jokes aside, I often find it more useful to "validate" when performing transformation from an input container to a model object. That way the model object can enforce its own constraints and avoid ever being invalid. The trick of course is providing enough specificity during failure to give the user or data source enough feedback to fix the problem, and then distinguishing between constraint violation and some other kind of transformation failure.Karlhttps://www.blogger.com/profile/08857379062217922195noreply@blogger.comtag:blogger.com,1999:blog-13967713.post-83583327971916934332012-08-14T12:31:20.038+02:002012-08-14T12:31:20.038+02:00Foudres, if you just scroll a bit up in the commen...Foudres, if you just scroll a bit up in the comments, you'll find my answer to David Leal. It should clarify my position on objects and multi-paradigm programming.<br /><br />I don't really agree with your classification of what is good for OO and what is not (see for instance my post "life without stupid objects" for an example of doing database-oriented stuff without behaviorless structures, while preserving strict layering), but this is sort of marginal to the discussion, and would lead to the usual, endless debate. <br /><br />I believe in multi-paradigm programming, with OO being one of the paradigms. The point of this post, as I said to David, is not to say "do it the OO way or die", but instead "<b>if</b> you do it OO, do it right".Carlo Pesciohttps://www.blogger.com/profile/12652284939993729858noreply@blogger.comtag:blogger.com,1999:blog-13967713.post-74736112252243540142012-08-14T11:38:03.992+02:002012-08-14T11:38:03.992+02:00The discussion on the name for objects and methods...The discussion on the name for objects and methods is interresting. And it apply to more than just objects.<br /><br />But the hypothesis used there - that object programming is somewhat better - might not be always true. <br /><br />Objects are well know to be good to model mainly behavioral things... Like UI elements. You want to hide the internal plumbing, the internal inherent state of theses elements and provide a simple interface to use them. And you really have a complex hierarchy of widgets.<br /><br />But many time we don't make new GUI API. IT is more focussed on data. You enter data on the system. It store the data and return it later on request. Scientific computing is also often very data centered. You have data in input, you process it, and have data in output.<br /><br />Traditionnally in IT, modelisation was done around data (database schema, input/ouput format). This is still true today with XML/JSON as exchange format, and if we hide database schema by using ORM, thoses domain object are typically behaviorless.<br /><br />In this type of architecture, we use services that tend to be more and more stateless (think all this REST thing for example), that take input, process it, and provide output. This is very procedural/functional design. But this no accident. The tasks to perform are naturally a good fit for procedural/functional programming.<br /><br />We don't have to use one way to modelize everything. Sometime you really want encapsulated state and single dispatch, then you use OOP. Sometime you prefer to promote a stateless architecture, explicit data formats and want to free you from the limitation of single dispatch. Then you'd be better with some functional thinking.<br /><br />In many schools, OOP and UML is seen as the only true way. People then try to do everything with it, even when this is obviously a less than perfect fit. One could thing that we need to improve our OOP modeling skills, that true. But a more interresting approach for me is to improve our modeling skill to not always think in term of OOP and avoid to design non OOP things with OOP.Foudreshttps://www.blogger.com/profile/05977228915328575616noreply@blogger.comtag:blogger.com,1999:blog-13967713.post-14123543740024458592012-08-14T07:52:08.622+02:002012-08-14T07:52:08.622+02:00Excellent article! I only wish you had also talked...Excellent article! I only wish you had also talked about the SomeService and SomeServiceImpl case.henrinoreply@blogger.comtag:blogger.com,1999:blog-13967713.post-42436544554487475532012-08-13T15:15:12.985+02:002012-08-13T15:15:12.985+02:00Nice post. I agree to most of it. The sequence ter...Nice post. I agree to most of it. The sequence terminology I think is not the best abstraction. In this case enumerable is more appropriated, or you should say Mathematics naming conventions is not good enough too. Anyway, is good to think about it.jalepihttps://www.blogger.com/profile/15015013773309124345noreply@blogger.comtag:blogger.com,1999:blog-13967713.post-18245373124391595922012-08-09T13:41:30.848+02:002012-08-09T13:41:30.848+02:00David: for an even more depressing post :-)), see ...David: for an even more depressing post :-)), see here: <br />http://www.carlopescio.com/2011/02/is-software-design-literature-dead.html<br /><br />More seriously, I have postponed creating a page with recommended readings for a long while now. I should spend some time on that.<br /><br />If you're impatient, I would start with the early works of Gerald Weinberg on systems thinking :-)Carlo Pesciohttps://www.blogger.com/profile/12652284939993729858noreply@blogger.comtag:blogger.com,1999:blog-13967713.post-70522465846556067932012-08-05T10:39:32.481+02:002012-08-05T10:39:32.481+02:00At the moment, for me, even a simple list of softw...At the moment, for me, even a simple list of software materials would be enough...<br /><br />Thanks <br />DanieleAnonymousnoreply@blogger.comtag:blogger.com,1999:blog-13967713.post-92015724692034794792012-08-05T10:16:28.370+02:002012-08-05T10:16:28.370+02:00Carlo,
it would be great if you could provide a c...Carlo,<br /><br />it would be great if you could provide a catalog of software materials with their properties (and maybe with some usage notes for the differents languages). <br /><br />I know that speaking of materials properties would require the definition of the physics of software, but maybe you could simply give us a simple empirical anticipation for our everyday work :-)<br /><br />Thanks<br />DanieleAnonymousnoreply@blogger.comtag:blogger.com,1999:blog-13967713.post-6144233103430030902012-08-01T15:22:16.950+02:002012-08-01T15:22:16.950+02:00[part 4 of 4 :-))]
The real issue, it seems, is m...[part 4 of 4 :-))]<br /><br />The real issue, it seems, is more like "if I have encapsulation I cannot use the underlying data structure at my will". On one side, I hope you'll see that this is very much like coming to steel with a wood mindset, and insisting on cutting steel along the fibers, and expressing surprise and scorn because you can't find fibers. If you come to OO with a LISP mindset that everything is a list and you express you logic through clever composition of abstract list operations, you'll never find yourself at home in OO land. It's not the way you shape that material. Of course, you get several interesting properties once you stop looking at things that way (like: I can later go in and change the damn data structure to something better, and you won't notice; I usually have a better match with domain concepts; etc), and you also lose some things (like: programs don't look like math anymore :-). It's hard to cover this kind of mindset in a comment, but I hope it's somewhat clear.<br /><br />In practice, one may find that some things are better made of wood, and others made of steel, embrace a multitude of paradigm, learn the inner power of each, and combine them to resolve forces in the best way. Or one may find he wants to belong to a tribe and celebrate the fearless leader and say that his language is pure and referentially transparent and spit on those poor slobs dealing with mutable state. It's a free world : ).Carlo Pesciohttps://www.blogger.com/profile/12652284939993729858noreply@blogger.comtag:blogger.com,1999:blog-13967713.post-27511874597021797922012-08-01T15:21:43.844+02:002012-08-01T15:21:43.844+02:00[part 3]
I have a class that represents a sequen...[part 3]<br /><br /><i> I have a class that represents a sequence of objects. In Ruby you can easily add a few useful methods to an object by extending the Enumerable (I know, I know) module. Then you can, say, use #map, #select, #reject, etc. However, a user of my sequence-like class will be unable to use random access, for example, because I didn't thought to include it. How do we deal with this?</i><br />--<br />Well, let's make an important distinction. It would be one thing to say that the language / library (because it's not a paradigm issue) won't even let you expose random access in a uniform way (for those containers where it makes sense). That would be easily dealt with. <br />It is a different thing to say that your class could expose random access, but you didn't <b>want</b> to, because you want to reserve yourself the freedom to change implementation (say, from an array to a tree). It is, finally, a different thing to say that you could expose random access, you don't plan to change the implementation at all, but you forgot to expose it. So you have a design error, and somehow we expect the paradigm to fix it :-). Very much like: I have a long function; I forgot a conditional in the middle of it, so you can't really use it for all input (but it's hard to know which input). Is it a paradigm problem that I can't fix it from the outside?<br /><br />Oversimplifying this kind of things by saying that when everything is public or everything is a list you don't get into troubles is, well, more of a marketing strategy than a calm and reasoned assessment of a problem. <br /><br />That said, the OO paradigm has necessarily to face the issue of unexpected usage / extension. Besides implementation inheritance and protected, most languages include now some form of "open class" technique, although there is usually a tendency to favor mechanisms that don't break encapsulation. Because if you didn't include random access, and I see by popping open your class that you <b>could</b> have included random access, does that mean that you'll always use that internal implementation, or that you reserved yourself the right to change it (and so you didn't expose it, intentionally?). Another interesting approach would be that of the selective violation of encapsulation (just because I want to add one method doesn't mean everyone has to be granted access to everything). There is a lot of pragmatic space here, that languages are filling over time.<br /><br />Yet another approach is to supplement OOP with AOP, and mix-in a random-access interface into your class. Of course, that aspect is exactly a local violation of encapsulation :-). In the spirit of multi-paradigm programming, OOP + AOP is again an interesting combination.Carlo Pesciohttps://www.blogger.com/profile/12652284939993729858noreply@blogger.comtag:blogger.com,1999:blog-13967713.post-42920899888881872392012-08-01T15:20:33.795+02:002012-08-01T15:20:33.795+02:00[part 2]
Still, in the real world, we build compl...[part 2]<br /><br />Still, in the real world, we build complex structures using many materials. One may criticize concrete for not being transparent, but I would not want to live in a house built entirely using glass. I'd like glass for my windows though, thank you. So even in multi-paradigm programming we need to adopt a paradigm for the overall structure, and adopt sub-paradigms where they're a better fit. For instance, in my "cut the red wire" post (http://www.carlopescio.com/2011/06/cut-red-wire.html) I basically used an OO shell around a FP core built using immutable objects, all in C#. And it was a piece of cake : ). Of course, it's not the only choice, though I've found it a pretty good combination in many cases.<br /><br />Now, coming to your specific questions, they seem to be more about encapsulation than OO (so any paradigm based on modules hiding implementation details will suffer from the same kind of issues), but ok.<br /><br /><i> Serialization: How do you serialize an object for transmission in an OO way, taking into account that the same object can be the source of multiple representations?</i><br />--<br />I hope you see that it's very much like the foil thing. I mean, given the set of programs one may want to write, given the subset where serialization is needed, given the subset where one may want multiple representations, objects are not a best fit and we usually have to expose data and not only services. Which is, by the way, the <b>default</b> condition in other paradigms : ). Hardly a failure, sorry; someone may even claim victory, saying: my worst case is your default case :-). Over time, the OO community has identified a few "standard" ways to do it (double dispatch / visitor; reflection w/ annotations; or a repository-like concept, possibly complemented by an IoC like I've shown in my "living w/out stupid objects" post (http://www.carlopescio.com/2012/07/life-without-stupid-objects-episode-1.html), with multiple repositories).<br /><br /><i> One criticism that I heard Rich Hickey make towards OO is that you cannot use an object beyond what the original designers thought it could do.</i><br />--<br />Tough I like Hickey quite a lot, he epitomizes the "dangerously good speaker" I was talking about before :-). Of course, having access to implementation details gives you more freedom. In exchange for a more rigid material, as now I can't change that thing anymore because you depend on it. That's a age-old debate, probably dating back to Brooks vs. Parnas (with Brooks saying, 20 years later: I was wrong, information hiding is the way to go). Note that OO usually comes with a set of concepts (like inheritance + protected, or open classes, or mixin, etc) that help you deal with this kind of issue, without exposing data / implementation as a default.Carlo Pesciohttps://www.blogger.com/profile/12652284939993729858noreply@blogger.comtag:blogger.com,1999:blog-13967713.post-883346854851186392012-08-01T15:18:10.812+02:002012-08-01T15:18:10.812+02:00David: I had to split a long response in parts :-)...David: I had to split a long response in parts :-)<br /><br />Before I get to your points, I'd like to add some perspective to this post, especially for those unfamiliar with my work and my general line of thinking.<br /><br />I'm not an OO zealot. Actually, I believe in multi-paradigm programming. I had my good share of LISP back in the 80s, I've immersed myself in Prolog longer than most sensible people do :-), etc. So the purpose of this post is not to say "do it the OO way or die", but instead "if you do it OO, do it right".<br /><br />I tend to liken paradigms, languages, and the structures we build with those languages to materials, with a set of expected properties (hence my work on the physics of software). If you build something using steel, you expect some properties. If you use wood, you expect different properties. It's not that steel "is wrong" or wood "is wrong". They're wrong if you expect a different set of properties. And of course, trying to shape wood the way you do with steel ain't gonna work, and you may end up with a burned piece of wood. Fake OO is like claiming, at that point, that burned wood is steel. Except it's not.<br /><br />In this sense, I see most criticism of programming paradigms as rather myopic. You frequently see a dangerously good :-) speaker / writer saying the equivalent of <i>"see, stainless steel cannot be shaped into foil thinner than 0.01mm, so we <b>never should use metals at all</b>"</i>, which is very much like finding a case that cannot be perfectly covered by one language, and then claiming that the entire paradigm is a failure, and of course they propose a different paradigm ("you should always use graphene instead!"). They argue so convincingly that you really want to believe them.<br /><br />This kind of rhetoric, in my opinion, is keeping the entire software design field stuck in dark ages, but ok, it's the de-facto technique to get market share. It's obviously skewed to the trained eye. For instance, functional programming and immutable objects are all rage now. Interestingly, there is a theoretical result which is suspiciously ignored by that community, which proves (see Pippenger, "pure vs impure lisp", http://www.cs.princeton.edu/courses/archive/fall03/cs528/handouts/Pure%20Versus%20Impure%20LISP.pdf) that for a category of problems, the best solution using immutable structures runs in O(n log on) while using mutable structures you can get O(n). Does that result in failure for Clojure or the entire functional paradigm? No, of course, because every material has its own properties, its own field of application, etc. For instance, LISP-like languages are pretty good when you want to write programming tools, and excel when you want to target LISP-like languages :-). They're also very good in a few more problem-frames, of course.Carlo Pesciohttps://www.blogger.com/profile/12652284939993729858noreply@blogger.comtag:blogger.com,1999:blog-13967713.post-54132815804416588182012-07-21T05:06:18.942+02:002012-07-21T05:06:18.942+02:00thanks for the reference Carlo!, I will read the p...thanks for the reference Carlo!, I will read the post you mention and the PDF for try to understand the idea. Very interesting blog! thanks for share your experiencemaxidrhttps://www.blogger.com/profile/02403838381437184964noreply@blogger.com