jwcolby
jwcolby at colbyconsulting.com
Tue Aug 7 11:02:09 CDT 2012
Thanks Ken, a good explanation. John W. Colby Colby Consulting Reality is what refuses to go away when you do not believe in it On 8/7/2012 11:46 AM, Kenneth Ismert wrote: >> >> Stuart McLachlan: >> ... >> Perhaps John and Kenneth can explain what they think the Tag property is >> for. >> ... >> Also, why they think that 62 lines of code in two different location is >> not *ugly* ... >> > > First, you have to have *some* code to run multiple form instances. This is > the 'bare bones' required for real, predictable multi-form functionality. > You might find some fat to trim on that code, but not much. > > But the main point is: why is the Tag property 'bad'? To paraphrase John's > response, Tag is a global form property, and as such it can be set by any > code anywhere at any time, even when the form is closed! It is the 'go to' > fix for any and all problems where 'some kind of information' is required > that doesn't fit in the normal form framework. > > So, the odds are good that if you rely on Tag (or any other kind of shared > global) in a project of any size, you or someone else will write code that > steps on functionality required in other parts of the program.. > > This is called 'incidental complexity' -- the unintended problems > introduced by a system of code or language. It is the time you spend fixing > or working around stuff that is improperly designed. It is a drag on your > productivity. > > There is a software development concept that covers this called Law of > Demeter, or Principle of Least Knowledge. Basically, it says 'code > shouldn't get into other code's business'. In this style of writing code, > using class properties like Tag assumes too much knowledge, or 'tight > coupling' of objects with code. > > My sample code was written with these guidelines in mind. It is loosely > coupled: all interaction between caller and form is done using public > functions. It passes TYPED VARIABLES to the form, with no need for parsing > or conversion. Plus, it is such a nice platform to expand on to implement > more complex form functionality. All code that interacts with the form > resides in one companion module. > > In short, using Tag is fine if your standard is 'it usually works', or 'its > OK if it fails unexpectedly'. But I want GUARANTEES that my code will work, > or fail immediately. > > -Ken >