Encapsulation and Data Abstraction Testing Applications in Smalltalk

Object-oriented Programming and Design 2 Encapsulation and Data Abstraction l An object should hide design decisions from its users l what is stored / what is computed l classes used l Can’t hide everything l Interface of object l Interface of parameters of object

Object-oriented Programming and Design 3 Encapsulation l Class contains variables and all the code that accesses the variables. Code should go with data. l Overuse of accessing methods is a sign of poor encapsulation l Code that uses a lot of accessing methods of an object should be moved to that object

Object-oriented Programming and Design 4 Encapsulation l (aPoint x squared + aPoint y squared) sqrt l aPoint r Some patterns (State, Strategy) break encapsulation. These are exceptions to the general rule that code should go with data.

Object-oriented Programming and Design 5 Inside/outside l Class describes the implementation of an object l Users care about specifications of object l Interface (Java, C++) l Pre and post-conditions (Eiffel) l Tests, examples, English description (all languages)

Types of arguments/results l Smalltalk does not check types at compile time l Programmer needs to know types l Method names tell: l Type of returned object l Role of arguments addEmployee: Object-oriented Programming and Design 6

Side effects l Names indicate whether method has side effect l Nouns, property – no side effect l Command – changes state of object add:, remove: Object-oriented Programming and Design 7

8 Tests l See if feature works l Make sure changes don’t break anything. l Document features. l Measure of completeness.

Object-oriented Programming and Design 9 Test-driven development l Write test for new feature first, then implement the feature. l Stop when tests work. l Use the simplest design that makes all the tests work l Refactor to eliminate duplication

Object-oriented Programming and Design 10 SUnit l The testing framework. l Each test is written in a subclass of TestCase. l Test is a method of the form “testXXX” l Each subclass is a group of related tests.

Object-oriented Programming and Design 11 TestRunner

Object-oriented Programming and Design 12 Important TestCase methods l assert: aBoolean l deny: aBoolean l should: aBlock l should: aBlock raise: anException l shouldnt: aBlock l shouldnt: aBlock raise: anException

Object-oriented Programming and Design 13 Test first design l How should feature work? l Give example l Write test case l Make test work l Write another test case l Make test work l...

Object-oriented Programming and Design 14 Problems with test first l What about testing GUIs? l What about testing real-time systems? l Tests show the presence of flaws, not their absence. l What about design?

Object-oriented Programming and Design 15 But you can’t test everything! l Testing increases your confidence. l Testing involves tradeoffs - better testing is more expensive. l Testing is never perfect; you can’t afford perfection. l Zero testing is always wrong; you must decide how much is enough.

Object-oriented Programming and Design 16 You can’t test everything l You can’t specify everything. l Automated tests with Sunit are easy and cheap most of the time. l Hard to test hardware. l Hard to test concurrent systems. l Most parts of a system are easy to test; write automated tests for them.

Object-oriented Programming and Design 17 Finding abstractions l Do one thing l Eliminate duplication l Keep rate of change similar l Decrease coupling, increase cohesion l Minimize interfaces l Minimize size of abstractions l Minimize number of abstractions

Object-oriented Programming and Design 18 Do one thing l Method should do what its name says l Class should be what its name says l Break complex classes/methods into simpler ones

Object-oriented Programming and Design 19 Eliminate duplication l (Ranks indexOf: rank) < (Ranks indexOf: argument rank) l self rankIndex < argument rankIndex

Object-oriented Programming and Design 20 Keep rate of change similar l Separate initial conditions from an algorithm’s temporary variables l Separate tax tables from employee data from time cards l Use “timer” to separate quickly changing information from slowly changing

Object-oriented Programming and Design 21 Decrease coupling, increase cohesion l Coupling is dependencc between components l Cohesion is dependence within a component

Object-oriented Programming and Design 22 Minimize interfaces l Use the smallest interface you can l Use Number instead of Float l Avoid embedding classes in names l add: instead of addNumber: l Don’t check the class of an object

Object-oriented Programming and Design 23 Mimize size of abstractions l Methods should be small l median size is 3 lines l 10 lines is starting to smell l Classes should be small l 7 variables is starting to smell l 40 methods is starting to smell

Object-oriented Programming and Design 24 Minimize number of abstractions l Can only learn 4-5 new things at a time. 3 is better l A class hierarchy 6-7 levels deep is hard to learn l Break large system into subsystems, so people only have to learn part of the system at a time

Object-oriented Programming and Design 25 A Payroll System PayrollSystem 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 Design 26 Object Model for Payroll Employee EmployeeTransaction PayrollSystem post: date Paycheck Timecard SalaryChange salary pay, taxes hoursWorked vacation A class with a method #post: A payroll system has a set of employees. An employee has a set of transactions (and a transaction is for an employee) Timecard, paycheck and salarychange are kinds of employee transactions : postTo: abstract class abstract method * *

Object-oriented Programming and Design 27 Employee Object subclass: #Employee instanceVariableNames: 'name transactions salary earned paid withholding accruedVacation taxRule' classVariableNames: 'HeadTaxRate MarriedSeparateTaxRate MarriedTaxRate SingleTaxRate' poolDictionaries: '' category: 'CS598rej-Payroll HW2'

Object-oriented Programming and Design 28 Employee Comment (View/Comment in RB) I represent an employee in a payroll system. Thus, I keep track of the number of hours worked, the wages paid, the vacation accrued, the taxes withheld, and so on. My values change only when transactions are posted to me. Transactions are subclasses of EmployeeTransaction.

Object-oriented Programming and Design 29 (continued) Variables name transactions salary... taxRule

Object-oriented Programming and Design 30 Hiding classes l Employee knows class Timecard l Users of Employee do not l Employee creates Timecards for users

Object-oriented Programming and Design 31 Using Employee | ralph | ralph := Employee new name: 'Ralph Johnson'. ralph changeSalaryFor: (Date newDay: 5 year: 1996) to: 20. ralph postTimeCardFor: (Date newDay: 10 year: 1996) hoursWorked: 40 vacation: 0.

Object-oriented Programming and Design 32 Testing Employee EmployeeTest is a subclass of TestCase testOvertime | ralph | ralph := Employee new named: 'Ralph Johnson'. ralph changeSalaryFor: day1 to: 20. payroll addEmployee: ralph. self postTimeCards: aLittleOvertime to: ralph.. self assert: ralph earned =

Object-oriented Programming and Design 33 Initializing an Employee named: aString name := aString. transactions := OrderedCollection new. salary := taxRule := SingleTaxRate

Object-oriented Programming and Design 34 Complete Creation Method Employee has the class method named: aString ^self new named: aString

Object-oriented Programming and Design 35 Timecard Timecard is a subclass of EmployeeTransaction with instance variables 'hoursWorked' and 'hoursVacation '

Object-oriented Programming and Design 36 Initializing a Timecard date: aDate employee: anEmployee worked: hoursW vacation: hoursV date := aDate. employee := anEmployee. hoursWorked := hoursW. hoursVacation := hoursV

Object-oriented Programming and Design 37 Complete Creation Method Timecard has class method date: aDate employee: anEmployee worked: hoursW vacation: hoursV ^self new date: aDate employee: anEmployee worked: hoursW vacation: hoursV

Object-oriented Programming and Design 38 Using a Timecard Employee has method: postTimeCardFor: aDate hoursWorked: hoursW vacation: hoursV self postTransaction: (Timecard date: aDate employee: self worked: hoursW vacation: hoursV)

Object-oriented Programming and Design 39 Initialization Patterns There should be one or more methods that initialize object. They should be in protocol "initialize-release". There should be one or more class methods that create initialized objects. They should be in protocol "instance creation".

Object-oriented Programming and Design 40 Processing a Transaction In Employee: postTransaction: aTransaction aTransaction postTo: self. transactions add: aTransaction

Object-oriented Programming and Design 41 Processing a Timecard postTo: anEmployee | money overtime nonovertime | overtime := (hoursWorked - 40) max: 0. nonovertime := hoursWorked min: 40. money := (overtime * nonovertime) * anEmployee salary. anEmployee incrementEarned: money.

Object-oriented Programming and Design 42 Processing a Timecard salary ^salary incrementEarned: anAmount earned := earned + anAmount

Object-oriented Programming and Design 43 Employee Action Protocol All changes to an Employee should be recorded as transactions. postTimeCardFor: aDate hoursWorked: hoursW vacation: hoursV self postTransaction:

Object-oriented Programming and Design 44 Assignment l Look up assignment on speedy.cs.uiuc.edu:2500 l Create a page for yourself on the “people in the class” page l Choose a time to meet with me to discuss the assignment