Difference: DesignRules (2 vs. 3)

Revision 32005-05-05 - KrisDeVolder

  META TOPICPARENT 
 name="WebHome" 

 Design Rules
- META TOPICPARENT
+ name="WebHome"
-<
<
+This page is the start of a hopefully growing collection of design rules. By building this collection
of examples we will hopefully be able to form an idea of the kind/range of things that would be useful to
enforce as design rules as well as how we would like to express them in our domain specific language.

 What are Design Rules 

Note: This is an attempt to provide a definition / vision on what we mean by "design rule". This is not
the be all and end all.
->
>
+ Note 


 This is only an attempt to provide a definition / vision on what we mean by "design rule". This is not intended to be the final word on it, but rather a working definition open for dicussion.
  Note
  This is only an attempt to provide a definition / vision on what we mean by "design rule". This is not intended to be the final word on it, but rather a working definition open for dicussion.
 A Design Rule is a (relatively) easily verifiable rule that constrains how code is to be structured.
By adhering to a design rule developers trade away some flexibility on how they write and structure code
  The fact that the desing-rule property holds boosts the developer's confidence in that the interesting property holds.
  It makes the code easier to read and understand (because it makes the interesting property more obvious and easier to verify).
-<
<
+For example, let's us considering the opening and closing of files. An interesting property we may wish to ensure ourselves of as developers is that
->
>
+For example, let's consider the opening and closing of files. An interesting property we may wish to ensure ourselves of as developers is that:
-<
<
+ All files are opened before they are always closed eventually.
->
>
+ All files that are opened are always eventually closed.
-<
<
+This property is potentially very hard to verify. However, it becomes much easier to verify it
if adopt the following design rule:
->
>
+This property is potentially very hard to verify. However, it becomes easier to verify
if the following design rule is followed:
-<
<
+ Files that are opened by a method should closed within the same method.
->
>
+ Files that are opened by a method should be closed before exiting the method.
 By adopting this desing rule the developer agrees to always open and close file in manner similar
to the following idiom:
 Note that this design rule may be overly restrictive for some situations. In such cases, the desing
-<
<
+rule may need to be extended to allow for certain exceptions. For these more complex cases may then chose to adopt a different design rule as an alternative.

 Design Rule Catalog 
 

 ExecuteAfterPut
  LazyInitialization
 

-- Main.kdvolder - 05 May 2005
->
>
+rule may need to be extended to allow for exceptions. For example, we could ammend the rule to allow
open files to be stored in instance variables of certain objects. For these more complex cases we may then chose to adopt other, perhaps more application specific design rules to gain confidence that those files are also not left accidentally open.

View topic | History: r5 < r4 < r3 < r2 | More topic actions...