tag:blogger.com,1999:blog-13967713.post2070094895947897718..comments2011-09-09T18:04:44.673+02:00Carlo.Pesciohttp://www.blogger.com/profile/12652284939993729858noreply@blogger.comBlogger2125tag:blogger.com,1999:blog-13967713.post-15088594350399875702011-09-09T18:04:44.673+02:002011-09-09T18:04:44.673+02:00Hey there Cyrille,<br />great comment, like always! I didn&#39;t know about Michael&#39;s work, very interesting...<br /><br />I&#39;m always keeping an eye on terminology. In most cases, whenever I&#39;m not reusing a familiar term from Computer Science, it&#39;s because I can&#39;t find an exact correspondence, and I&#39;m trying not to muddle existing terminology. I understand that taking inspiration from physics may alienate some, but in practice, I&#39;ve found this to be most consistent with my view of software as a material to be shaped. Another reason for me to shun the existing terminology is that it often comes with a good / evil attachment (coupling is bad, separation of concern is good, etc) which hinders the idea that design is about balancing forces. <br /><br />You&#39;re right however, using concepts from the physics of software to review existing principles (and patterns, I would add) is probably an excellent way to make it a bit more popular. For instance, I&#39;ll soon introduce the idea of R/R and U/U entanglement in the run-time space, and basically say that things that are read together and/or updated together are attracted. This is easily explained by effiency. <br />Interestingly, the dual statement in the artifacts space is that artifacts which are reused together, or updated together, are also attracted. This is the basis for the well-known &quot;reuse release equivalence principle&quot; (http://c2.com/cgi/wiki?ReuseReleaseEquivalencePrinciple). <br /><br />Along the same lines, my investigation of forces and materials has led me to formulate an alternative Open/Closed principle, that is not limited to classes, but extends to generics, functions, etc. I actually have a ton of notes, and now need some time to write everything down. I&#39;ll probably try other media as well: I was thinking of a short video to discuss the forcefield around some well-known pattern.<br /><br />I&#39;ll trade the beer for some gateaux (I used to speak French, but that was like 30 years ago; I barely remember a few words now :-)Carlo.Pesciohttp://www.blogger.com/profile/12652284939993729858noreply@blogger.comtag:blogger.com,1999:blog-13967713.post-46001392857499659332011-09-03T16:17:01.202+02:002011-09-03T16:17:01.202+02:00Carlo,<br /><br />Interesting read as usual! The redundancy part immediately reminds me of Degree Of Freedom analysis, which I used to blog on, with influence from posts by Michael L. Perry: http://cyrille.martraire.com/2009/12/degrees-of-freedom-analysis <br />Clearly we&#39;d like to minimize, or at least be aware of any extra degree of freedom, and of the potential inconsistencies that could result from them.<br /><br />On invariants, Domain-Driven Design strongly suggests that looking for invariants is a strong guide to find out the right concepts, as explained by Alberto Brandolini teaching the course. This often leads to derived values instead of redundant values, that would be &quot;extra&quot; (useless and potentially harmful) degrees of freedom.<br /><br />Going further, the DDD concept of aggregates as a bigger boundary of consistency is an alternate way to discuss &quot;entanglement&quot;, with all the consequences in transaction, foreigh keys, Delete-Delete rule etc.<br /><br /><br />I find the idea of degrees of freedom more intuitive (taught at school) than entanglement which is evocative of quantum weirdness, frightening!<br /><br />These ideas are taking shape, I&#39;m eager that all that gets consolidated soon into some consistent and affordable form. Ideally I&#39;d prefer that existing vocabulary and concepts be reused whenever possible, but I understand that you&#39;d like to borrow from the metaphor of physics to help reasoning. At the same time these metaphors exclude pure CS people with not enough exposure to physics, just like my beloved concept of DoF exclude people with no background in mechanical engineering...<br /><br />Anyhow such physics of software, whatever it&#39;s called, could become more popular if it could help modernize our set of principles (SOLID etc.) now that functional programming ideas and alternate architectural styles (CQRS, Event Sourcing...) are getting traction.<br /><br />Cheers, (whenever you come to Paris we could share a beer)Cyrille Martrairehttp://cyrille.martraire.com/noreply@blogger.com