CSC323 2010S, Class 20: Design Principles Overview: * Exploring Logs. * Design Principles. * Open-Closed Principle (OCP) * Don't Repeat Yourself Principle (DRY) * Single Responsiblity Principle (SRP) * Liskov Substitution Principle (LSP) * Alternatives to Inheritance. * Delegation * Composition * Aggregation * Small-group Exercise. * Project Reflection. * Integration. Admin: * Reading for Tuesday: Chapter 9. * Goal for next Thursday: Nine hours of work per person. * I left out one of the types of problems for the final: There will also be a "write a test" problem. * As you requested, I've removed the unused parts of the course web. Let me know if that seems better. * Final will be on Tuesday. Activity One * Grab your logs Task types: * E: Explanations of Stuff (Design, Architecture, Python) * H: High-level design * P: Planning * Including drawing pictures of GUI * W: Writing Documentation * R: Finding and reading resources * T: Testing * C: Coding * D: Debugging * O: Overhead * How much time did you spend on each kind of task? --+----+----+----+----+ | <30| <60|<120|>120| --+----+----+----+----+ E | 2 | 5 | 0 | 4 | --+----+----+----+----+ H | 1 | 4 | 1 | 4 | --+----+----+----+----+ P | 0 | | | | --+----+----+----+----+ W | | | | | --+----+----+----+----+ R | | | | | --+----+----+----+----+ T | | | | | --+----+----+----+----+ C | | | | | --+----+----+----+----+ D | | | | | --+----+----+----+----+ O | | | | | --+----+----+----+----+ * What's the ideal? * Coding is "obvious", so it shouldn't take long * Overhead should be low (how?) * What was your pattern? EPCTDCDCDCDCDCDCDDDDDDDDDDDD PcPcPcPc, where c=C+T+W+... * How many lines of code did you write? * How do we count lines of code? * wc -l *.py (counts everything) * Doesn't distinguish between dense and sparse code * One group: 500 loc in 72 hours, so 7 loc/hour * Another group: NOT ANALYZED BECAUE OF ARGUMENTS * Third group: 240 loc in 24 hours, so 10 loc/hour (Would be worse if we counted the prior work, since it was thrown away) * How did you document your time spent working? * At a reasonable breaking time, put the info in a file * A few hours later, try to remember what you did * Let someone else document for me * Danger of fifteen minute intervals: Looking at the clock May be best to update the log when you switch tasks, rather than every fifteen minutes * Unless you're doing lots of rapid task switching * Start logging in advance, rather than retrospectively * Why do you document your time spent working? * Retrospect: How am I spending my time, and am I spending it on things that I should be doing? * Retrospect: Identify the hot spot: Where you should optimize * Prospect: Lets you estimate future activities * The boss said so! * Billing * How should you have documented your time spent working? * Use forms (or software), rather than writing things down Design Principles * Open-Closed Principle (OCP) * Once you have a class working, you change functionality by extension rather than by rewriting the code * Don't change the behavior of a class * Encapsulation suggests that you can still change the way you implement that behavior * Why? People will be unhappy if you change the behavior * The authors seem to imply that the implementation should not be changed, but we disagree * Don't Repeat Yourself Principle (DRY) * Don't have the same code/functionality in more than one place * Factor out the common code and make a separate object or function * Factor out the common functionality at the design level * "Refactor mercilessly" * What language attributes make this kind of refactoring easier or harder? * Some abstraction can be done with things like abstract classes and inheritance (the common code goes in the ancestor or the common code relies on the abstract class) * Higher-order procedures let you encapsulate control * Single Responsiblity Principle (SRP) * Each object should be responsible for one central thing (big or small) * Assessment technique: What things do you do to yourself? * Liskov Substitution Principle (LSP) * You should always be able to subsitute an element of a subclass for an element of a superclass * Essential to the typical notions of inheritance and polymorphism * Why is it called the Liskov Subsitution Principle? * After Barbara Liskov * Who stated it in applying type theory to object-oriented programming * Liskov is responsible for the Iterator LSP causes some problems when we want something like inheritance (e.g., we want to use characteristics of the superclass), but the subclass can't subsitute. * We have a reference to the object in the class that provides the relevant property and delegate to that class * Bad example from book: We might represent a 3D board as a collection of 2D boards. When asked to change the 3D board, we identify one of the 2D boards and tell it to modify itself. * We tell a "LocalWorld" to update a particular piece. It may delegate that change to a separate Board class. (Not in our design, but possibly.) Two kinds of delegation * Composition and Aggregation * In both cases, we include references to elements of other classes * In both cases, we use those elements of other classes to accomplish activities * What's the important difference between composition and aggregation? * In composition, the included object "exists only within" the object that uses it * In aggregation, it can be used in multiple places * In the implementation, composition allows us to lay out the enclosing class so that there's memory allocated to the included object * Faster! No reference chasing. Locality. * Question of responsibility of freeing referenced objects * In composition, when you are destroyed, you should destroy any composed objects * In a GC language, the latter is not an important issue Three Questions: * How do we deal with sharing of code? * What is Sam's model of the use of the network? * What should our protocol look like? Sharing of Code * Models * A: Work in parallel, share once per week (5) * B: Divide big project up into subprojects (7) * * GUI (View/Controller) [NC,DV,DG,JR] * Network (??) [RC,AT,AC,TK] * Model [JQ,JS,JT,NL] * Work in parallel, share regularly [No] *