1. Well-behaved objects Improving your coding skills 1.0

2. 18/11/2004Lecture 6: Wel-behaved Objects2 Main concepts to be covered Testing Debugging Test automation Writing for maintainability

3. 18/11/2004Lecture 6: Wel-behaved Objects3 We have to deal with errors Early errors are usually syntax errors. The compiler will spot these. Later errors are usually logic errors. The compiler cannot help with these. Also known as bugs. Some logical errors have no immediately obvious manifestation. Commercial software is rarely error free.

4. 18/11/2004Lecture 6: Wel-behaved Objects4 Prevention vs Detection (Developer vs Maintainer) We can lessen the likelihood of errors. Use software engineering techniques, like encapsulation. We can improve the chances of detection. Use software engineering practices, like modularization and documentation. We can develop detection skills.

5. 18/11/2004Lecture 6: Wel-behaved Objects5 Testing and debugging These are crucial skills. Testing searches for the presence of errors. Debugging searches for the source of errors. The manifestation of an error may well occur some ‘distance’ from its source.

6. 18/11/2004Lecture 6: Wel-behaved Objects6 Testing and debugging techniques Unit testing (within BlueJ) Test automation Manual walkthroughs Print statements Debuggers

7. 18/11/2004Lecture 6: Wel-behaved Objects7 Unit testing Each unit of an application may be tested. Method, class, module (package in Java). Can (should) be done during development. Finding and fixing early lowers development costs (e.g. programmer time). A test suite is built up.

8. 18/11/2004Lecture 6: Wel-behaved Objects8 Testing fundamentals Understand what the unit should do – its contract. You will be looking for violations. Use positive tests and negative tests. Test boundaries. Zero, One, Full. Search an empty collection. Add to a full collection.

9. 18/11/2004Lecture 6: Wel-behaved Objects9 Unit testing within BlueJ Objects of individual classes can be created. Individual methods can be invoked. Inspectors provide an up-to-date view of an object’s state. Explore through the diary-prototype project.

10. 18/11/2004Lecture 6: Wel-behaved Objects10 Test automation Good testing is a creative process, but...... thorough testing is time consuming and repetitive. Regression testing involves re-running tests. Use of a test rig or test harness can relieve some of the burden. Classes are written to perform the testing. Creativity focused in creating these.

11. 18/11/2004Lecture 6: Wel-behaved Objects11 Test automation Explore through the diary-testing project. Human analysis of the results still required. Explore fuller automation through the diary-test-automation project. Intervention only required if a failure is reported.

12. 18/11/2004Lecture 6: Wel-behaved Objects12 Modularization and interfaces Applications often consist of different modules. E.g. so that different teams can work on them. The interface between modules must be clearly specified. Supports independent concurrent development. Increases the likelihood of successful integration.

13. 18/11/2004Lecture 6: Wel-behaved Objects13 Modularization in a calculator Each module does not need to know implementation details of the other. User controls could be a GUI or a hardware device. Logic could be hardware or software.

14. 18/11/2004Lecture 6: Wel-behaved Objects14 Method signatures as an interface // Return the value to be displayed. public int getDisplayValue(); // Call when a digit button is pressed. public void numberPressed(int number); // Call when a plus operator is pressed. public void plus(); // Call when a minus operator is pressed. public void minus(); // Call to complete a calculation. public void equals(); // Call to reset the calculator. public void clear();

15. 18/11/2004Lecture 6: Wel-behaved Objects15 Debugging It is important to develop code-reading skills. Debugging will often be performed on others’ code. Techniques and tools exist to support the debugging process. Explore through the calculator-engine project.

16. 18/11/2004Lecture 6: Wel-behaved Objects16 Manual walkthroughs Relatively underused. A low-tech approach. More powerful than appreciated. Get away from the computer! ‘Run’ a program by hand. High-level (Step) or low-level (Step into) views.

17. 18/11/2004Lecture 6: Wel-behaved Objects17 Tabulating object state An object’s behavior is usually determined by its state. Incorrect behavior is often the result of incorrect state. Tabulate the values of all fields. Document state changes after each method call.

18. 18/11/2004Lecture 6: Wel-behaved Objects18 Verbal walkthroughs Explain to someone else what the code is doing. They might spot the error. The process of explaining might help you to spot it for yourself. Group-based processes exist for conducting formal walkthroughs or inspections.

19. 18/11/2004Lecture 6: Wel-behaved Objects19 Print statements The most popular technique. No special tools required. All programming languages support them. Only effective if the right methods are documented. Output may be voluminous! Turning off and on requires forethought.

20. 18/11/2004Lecture 6: Wel-behaved Objects20 Debuggers Debuggers are both language- and environment-specific. BlueJ has an integrated debugger. Support breakpoints. Step and Step-into controlled execution. Call sequence (stack). Object state.

21. 18/11/2004Lecture 6: Wel-behaved Objects21 Review Errors are a fact of life in programs. Good software engineering techniques can reduce their occurrence. Testing and debugging skills are essential. Make testing a habit. Automate testing where possible. Practise a range of debugging skills.

22. Designing classes How to write classes in a way that they are easily understandable, maintainable and reusable

23. 18/11/2004Lecture 6: Wel-behaved Objects23 Main concepts to be covered Responsibility-driven design Coupling Cohesion Refactoring Static methods

24. 18/11/2004Lecture 6: Wel-behaved Objects24 Software changes Software is not like a novel that is written once and then remains unchanged. Software is extended, corrected, maintained, ported, adapted… The work is done by different people over time (often decades).

25. 18/11/2004Lecture 6: Wel-behaved Objects25 Change or die There are only two options for software: Either it is continuously maintained or it dies. Software that cannot be maintained will be thrown away.

26. 18/11/2004Lecture 6: Wel-behaved Objects26 World of Zuul

27. 18/11/2004Lecture 6: Wel-behaved Objects27 Code quality Two important concepts for quality of code: Coupling Cohesion

28. 18/11/2004Lecture 6: Wel-behaved Objects28 Coupling Coupling refers to links between separate units of a program. If two classes depend closely on many details of each other, we say they are tightly coupled. We aim for loose coupling.

29. 18/11/2004Lecture 6: Wel-behaved Objects29 Loose coupling Loose coupling makes it possible to: understand one class without reading others; change one class without affecting others. Thus: improves maintainability.

30. 18/11/2004Lecture 6: Wel-behaved Objects30 Cohesion Cohesion refers to the the number and diversity of tasks that a single unit is responsible for. If each unit is responsible for one single logical task, we say it has high cohesion. Cohesion applies to classes and methods. We aim for high cohesion.

31. 18/11/2004Lecture 6: Wel-behaved Objects31 High cohesion High cohesion makes it easier to: understand what a class or method does; use descriptive names; reuse classes or methods.

32. 18/11/2004Lecture 6: Wel-behaved Objects32 Cohesion of methods A method should be responsible for one and only one well defined task.

33. 18/11/2004Lecture 6: Wel-behaved Objects33 Cohesion of classes Classes should represent one single, well defined entity.

34. 18/11/2004Lecture 6: Wel-behaved Objects34 Code duplication is an indicator of bad design, makes maintenance harder, can lead to introduction of errors during maintenance.

35. 18/11/2004Lecture 6: Wel-behaved Objects35 Responsibility-driven design Question: where should we add a new method (which class)? Each class should be responsible for manipulating its own data. The class that owns the data should be responsible for processing it. RDD leads to low coupling.

36. 18/11/2004Lecture 6: Wel-behaved Objects36 Localizing change One aim of reducing coupling and responsibility-driven design is to localize change. When a change is needed, as few classes as possible should be affected.

37. 18/11/2004Lecture 6: Wel-behaved Objects37 Thinking ahead When designing a class, we try to think what changes are likely to be made in the future. We aim to make those changes easy.

38. 18/11/2004Lecture 6: Wel-behaved Objects38 Refactoring When classes are maintained, often code is added. Classes and methods tend to become longer. Every now and then, classes and methods should be refactored to maintain cohesion and low coupling.

39. 18/11/2004Lecture 6: Wel-behaved Objects39 Refactoring and testing When refactoring code, separate the refactoring from making other changes. First do the refactoring only, without changing the functionality. Test before and after refactoring to ensure that nothing was broken.

40. 18/11/2004Lecture 6: Wel-behaved Objects40 Design questions Common questions: How long should a class be? How long should a method be? Can now be answered in terms of cohesion and coupling.

41. 18/11/2004Lecture 6: Wel-behaved Objects41 Design guidelines A method is too long if it does more then one logical task. A class is too complex if it represents more than one logical entity. Note: these are guidelines - they still leave much open to the designer.

42. 18/11/2004Lecture 6: Wel-behaved Objects42 Review Programs are continuously changed. It is important to make this change possible. Quality of code requires much more than just performing correct at one time. Code must be understandable and maintainable.

43. 18/11/2004Lecture 6: Wel-behaved Objects43 Review Good quality code avoids duplication, displays high cohesion, low coupling. Coding style (commenting, naming, layout, etc.) is also important. There is a big difference in the amount of work required to change poorly structured and well structured code.

44. 18/11/2004Lecture 6: Wel-behaved Objects44 Static Methods Previous we discussed class and object level. We introduced class variables static keyword A similar thing can be done for methods providing services for the class instead an object

45. 18/11/2004Lecture 6: Wel-behaved Objects45 Static Methods (2) public class StaticTest { static count = 0; public StaticTest { count++; } public static int giveCount() { return count; } … }

46. 18/11/2004Lecture 6: Wel-behaved Objects46 Executing without BlueJ If we want to start a Java application without BlueJ, we need to use a class method. Java uses a class method with a specific signature: public static void main(String args[]) args contains the command line options for your application

47. 18/11/2004Lecture 6: Wel-behaved Objects47 Executing without BlueJ (2) Compiling javac className.java Running java className java className command line options but className should contain a main method BlueJ write its own main whenever you ask it to execute something.

48. 18/11/2004Lecture 6: Wel-behaved Objects48 Concepts testing positive and negative testing debugging unit testing regression testing walkthroughs responsibility-driven design coupling cohesion refactoring static class methods main method