Comments on: Intention Revealing Names http://aslamkhan.net/software-development/intention-revealing-names/ "There are no limits. There are only plateaus, and you must not stay there, you must go beyond them." - Bruce Lee Mon, 08 Mar 2010 12:46:25 -0800 http://wordpress.org/?v=2.8.6 hourly 1 By: Aslam http://aslamkhan.net/software-development/intention-revealing-names/comment-page-1/#comment-455 Aslam Wed, 23 Apr 2008 11:08:02 +0000 http://aslamkhan.net/software-development/intention-revealing-names/#comment-455 Hi Andrew, Absolutely true. That is what I intended by the example but was, perhaps, not explicit. Hmmm, I should have shown DirectedGraph as a private member of the SocialNetwork class. That would have made the example a lot clearer. But be guarded about how the layers of abstraction are structured. For example, extending SocialNetwork from DirectedGraph may not be good idea because all DirectedGraph operations may not be applicable to SocialNetwork. If that is the case, then encapsulate DirectedGraph in SocialNetwork and expose the relevant operations using intention revealing names and in the implementation delegate the operation to the DirectedGraph. Aslam Hi Andrew,

Absolutely true. That is what I intended by the example but was, perhaps, not explicit. Hmmm, I should have shown DirectedGraph as a private member of the SocialNetwork class. That would have made the example a lot clearer.

But be guarded about how the layers of abstraction are structured. For example, extending SocialNetwork from DirectedGraph may not be good idea because all DirectedGraph operations may not be applicable to SocialNetwork.

If that is the case, then encapsulate DirectedGraph in SocialNetwork and expose the relevant operations using intention revealing names and in the implementation delegate the operation to the DirectedGraph.

Aslam

]]> By: Andrew McVeigh http://aslamkhan.net/software-development/intention-revealing-names/comment-page-1/#comment-454 Andrew McVeigh Wed, 23 Apr 2008 08:43:16 +0000 http://aslamkhan.net/software-development/intention-revealing-names/#comment-454 There is a tension between implementation reuse and intention revelation. Case in point -- if you need a graph cycle detection algorithm, there are many around but phrased in terms of nodes and graphs etc. But you'll find very few called "SocialNetwork". Perhaps the situation is better solved using layered abstractions, which successively reveal intentions. E.g. build on the graph library (i.e. use it as the underlying implementation), but call your new layer SocialNetwork and hide the graph structure from clients. Andrew There is a tension between implementation reuse and intention revelation. Case in point — if you need a graph cycle detection algorithm, there are many around but phrased in terms of nodes and graphs etc. But you’ll find very few called “SocialNetwork”.

Perhaps the situation is better solved using layered abstractions, which successively reveal intentions. E.g. build on the graph library (i.e. use it as the underlying implementation), but call your new layer SocialNetwork and hide the graph structure from clients.

Andrew

]]> By: Stefan Mahs http://aslamkhan.net/software-development/intention-revealing-names/comment-page-1/#comment-428 Stefan Mahs Wed, 16 Apr 2008 07:48:36 +0000 http://aslamkhan.net/software-development/intention-revealing-names/#comment-428 This is one of my favourite topics. I was first exposed to the importance of "semantics in design" in the early 1990's. In addition to aiding in readability, naming classes and attributes accurately and consistently with business terminology helps to maintain a purer design and avoids inheritance hierarchies that support "technically" common functionality. If class names make their intent and purpose in life unambiguous then ancestors in the resulting inheritance hierarchy will embody behaviour and properties common to the corresponding business concepts they represent, and the design will be more robust. This robustness will become critical when it comes to implementing changes to keep the system in line with the changing business. Stefan This is one of my favourite topics. I was first exposed to the importance of “semantics in design” in the early 1990’s. In addition to aiding in readability, naming classes and attributes accurately and consistently with business terminology helps to maintain a purer design and avoids inheritance hierarchies that support “technically” common functionality. If class names make their intent and purpose in life unambiguous then ancestors in the resulting inheritance hierarchy will embody behaviour and properties common to the corresponding business concepts they represent, and the design will be more robust. This robustness will become critical when it comes to implementing changes to keep the system in line with the changing business.

Stefan

]]>