1 / 12

To Be Explicit

To Be Explicit. Eric Avery 1.23.2003. Software Design. Classes, Objects, Instantiation – clear as mud???????? How easy can your design be changed? VERY IMPORTANT Durakon Purchase Requisition Approval Process Analogy. Explicit Design Less flexible class but easier to understand.

cian
Télécharger la présentation

To Be Explicit

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. To Be Explicit Eric Avery 1.23.2003

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

  3. 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

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

  5. 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 Classes: Event Handlers vs. Explicit Methods

  6. 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

  7. Classes: Event Handlers vs. Explicit MethodsCODE

  8. 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 Classes: Data-Driven vs. Explicit

  9. 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:

  10. Classes: Data-Driven vs. Explicit CODE

  11. 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

  12. Links • Microsoft Overview

More Related