Encapsulation and Data AbstractionEncapsulation and Data AbstractionEncapsulationSlide 4Inside/outsideTestsTest-driven developmentSUnitTestRunnerImportant TestCase methodsTest first designProblems with test firstBut you can’t test everything!You can’t test everythingFinding abstractionsDo one thingEliminate duplicationKeep rate of change similarDecrease coupling, increase cohesionMinimize interfacesMimize size of abstractionsMinimize number of abstractionsA Payroll SystemObject Model for PayrollEmployeeEmployee Comment(continued)Hiding classesUsing EmployeeTesting EmployeeInitializing an EmployeeComplete Creation MethodTimecardInitializing a TimecardSlide 35Using a TimecardInitialization PatternsProcessing a TransactionProcessing a TimecardSlide 40Employee Action ProtocolEncapsulation and Data AbstractionTestingApplications in SmalltalkObject-oriented Programming and Design2Encapsulation and Data AbstractionAn object should hide design decisions from its userswhat is stored / what is computedclasses usedCan’t hide everythingInterface of objectInterface of parameters of objectObject-oriented Programming and Design3EncapsulationClass contains variables and all the code that accesses the variables.Code should go with data.Overuse of accessing methods is a sign of poor encapsulationCode that uses a lot of accessing methods of an object should be moved to that objectObject-oriented Programming and Design4Encapsulation(aPoint x squared + aPoint y squared) sqrtaPoint rSome patterns (State, Strategy) break encapsulation. These are exceptions to the general rule that code should go with data.Object-oriented Programming and Design5Inside/outsideClass describes the implementation of an objectUsers care about specifications of objectInterface (Java, C++)Pre and post-conditions (Eiffel)Tests, examples, English description (all languages)Object-oriented Programming and Design6TestsSee if feature worksMake sure changes don’t break anything.Document features.Measure of completeness.Object-oriented Programming and Design7Test-driven developmentWrite test for new feature first, then implement the feature. Stop when tests work.Use the simplest design that makes all the tests workRefactor to eliminate duplicationObject-oriented Programming and Design8SUnitThe testing framework.Each test is written in a subclass of TestCase.Test is a method of the form “testXXX”Each subclass is a group of related tests.Object-oriented Programming and Design9TestRunnerObject-oriented Programming and Design10Important TestCase methodsassert: aBooleandeny: aBooleanshould: aBlockshould: aBlock raise: anExceptionshouldnt: aBlockshouldnt: aBlock raise: anExceptionObject-oriented Programming and Design11Test first designHow should feature work? Give exampleWrite test caseMake test workWrite another test caseMake test work...Object-oriented Programming and Design12Problems with test first What about testing GUIs?What about testing real-time systems?Tests show the presence of flaws, not their absence.What about design?Object-oriented Programming and Design13But you can’t test everything!Testing increases your confidence.Testing involves tradeoffs - better testing is more expensive.Testing is never perfect; you can’t afford perfection.Zero testing is always wrong; you must decide how much is enough.Object-oriented Programming and Design14You can’t test everythingYou can’t specify everything.Automated tests with Sunit are easy and cheap most of the time.Hard to test hardware.Hard to test concurrent systems.Most parts of a system are easy to test; write automated tests for them.Object-oriented Programming and Design15Finding abstractionsDo one thingEliminate duplicationKeep rate of change similarDecrease coupling, increase cohesionMinimize interfacesMinimize size of abstractionsMinimize number of abstractionsObject-oriented Programming and Design16Do one thingMethod should do what its name saysClass should be what its name saysBreak complex classes/methods into simpler onesObject-oriented Programming and Design17Eliminate duplication(Ranks indexOf: rank) < (Ranks indexOf: argument rank)self rankIndex < argument rankIndexObject-oriented Programming and Design18Keep rate of change similarSeparate initial conditions from an algorithm’s temporary variablesSeparate tax tables from employee data from time cardsUse “timer” to separate quickly changing information from slowly changingObject-oriented Programming and Design19Decrease coupling, increase cohesionCoupling is dependencc between componentsCohesion is dependence within a componentObject-oriented Programming and Design20Minimize interfacesUse the smallest interface you canUse Number instead of FloatAvoid embedding classes in namesadd: instead of addNumber:Don’t check the class of an objectObject-oriented Programming and Design21Mimize size of abstractionsMethods should be smallmedian size is 3 lines10 lines is starting to smellClasses should be small7 variables is starting to smell40 methods is starting to smellObject-oriented Programming and Design22Minimize number of abstractionsCan only learn 4-5 new things at a time. 3 is betterA class hierarchy 6-7 levels deep is hard to learnBreak large system into subsystems, so people only have to learn part of the system at a timeObject-oriented Programming and Design23A Payroll SystemPayrollSystem keeps track of employees.Employee knows salary, how much has been earned, how much has been payed, how much taxes have been withheld. Employee should be able to tell us about past transactions, not just current balances.Object-oriented Programming and Design24Object Model for PayrollEmployeeEmployeeTransactionPayrollSystempost:datePaycheckTimecardSalaryChangesalarypay, taxeshoursWorkedvacationA class with a method #post:A payroll systemhas a set ofemployees.An employee has aset of transactions(and a transactionis for an employee)Timecard, paycheckand salarychangeare kinds of employee transactionspostTo::abstract classabstract classabstract methodabstract method****Object-oriented Programming and Design25EmployeeObject subclass: #EmployeeinstanceVariableNames: 'name transactions salary earned paid withholding accruedVacation taxRule'classVariableNames: