To Be Explicit Eric Avery

Software Design Classes, Objects, Instantiation – clear as mud???????? How easy can your design be changed? VERY IMPORTANT Durakon Purchase Requisition Approval Process Analogy

Classes: Explicit vs. Dictionary Design Explicit Design Less flexible class but easier to understand. Class is specific to what is stores Easier for the programmer to modify Dictionary Design Array like storage (or other methods) More flexible to use but difficult to understand. Class is not specific to what is stores Requires total system analysis to determine what the class does

Classes: Explicit vs. Dictionary Design CODE Calling Methods objEmployee.FirstName = “Eric” objEmployee.Title = “Ruler of the Universe” vs objEmployee(“PayRate”) = “UNDERPAID” objEmployee(“Migraines”) = 4000

Classes: Event Handlers vs. Explicit Methods Event Handlers Quick and easy to “extend” behavior to module (object) interaction Difficult to understand: Code is shorthand and not easily readable Programmer must search all the code for a handler to see what it does Debugging can be difficult Explicit Methods Clearly defines what happens for an event Must modify the class when a change in behavior is needed Primary practice at Durakon

More on Event Handlers Not evil, actually very powerful (if used wisely) Click a button, you might have 50 objects that created and used. You would have to search the code for any handling/ Basically, the framework of modern programming language will allow you to raise events based on an action of the object (an event) which calls another object’s behavior. VB Form Example: The Form_Load Event of the Form is fired automatically when a form loads. Events are inherent to Microsoft’s current developer tools

Classes: Event Handlers vs. Explicit Methods CODE

Classes: Data-Driven vs. Explicit Data-Driven Classes Make new behaviors without modify or creating new classes if the logic fits Explicit Classes Again, Easier to read and understand You must edit the class in order to change behavior

More on Data Driven Generic Classes Works well if there are several behaviors that follow the logic involved. Cuts down on the sheer volume of code. Trade off is again, difficulty to understand and thereby more difficult to change. Another Example:

Classes: Data-Driven vs. Explicit CODE

For me… I agree with the author 90% of the code I have written is heavily explicit. It costs a little more time but it is clearer for other programmers(and the programmer writing the code) to debug. From my perspective, I believe using non-explicit codes will eventually cost you in the end (instead of upfront) Most used non-explicit: Event handlers

Links Microsoft Overview