Programming methods summary
Julia Hofs
2IPC0 Programming methods
TU Eindhoven
April 20, 2017
,Contents
1 Test-driven development 3
1.1 How: TDD steps . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2 Why: motivation for TDD . . . . . . . . . . . . . . . . . . . . . . 3
2 From callbacks to design patterns 5
2.1 Callbacks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.2 Callbacks in Java . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.3 Defining an anonymous callback on the fly . . . . . . . . . . . . . 6
2.4 Wrapping a class to provide a callback . . . . . . . . . . . . . . . 7
2.5 Distributing a callback to other callbacks . . . . . . . . . . . . . 9
2.6 Modifying and filtering data as it is transferred . . . . . . . . . . 11
2.7 Data processing toolkit and trade-offs . . . . . . . . . . . . . . . 13
2.8 Listeners . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.9 Observers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.10 Push to observer; or pull from subject, or both . . . . . . . . . . 14
2.11 Update or query the observers, or both . . . . . . . . . . . . . . . 15
2.12 Concluding remarks . . . . . . . . . . . . . . . . . . . . . . . . . 15
3 Design patterns 16
3.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
3.2 Singleton . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
3.3 Iterator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
3.4 Adapter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
3.5 Decorator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
3.6 State . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
3.7 Strategy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
3.8 Factory method . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
3.9 Observer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
3.10 Facade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.11 Template method . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.12 Composite . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
3.13 Command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
3.14 Related patterns . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
2
, 1 Test-driven development
Test-driven development, abbreviated as TDD, is a technique that concerns
the development process, rather than the structure of the developed product.
1.1 How: TDD steps
These are the TDD development steps as performed in this course:
1. Gather and analyze the requirements to realize, e.g. use cases or user
stories (these will be given in this course).
2. Decide which requirement to develop next, and what module it concerns.
3. Specify the module informally in the source code, using natural lan-
guage.
4. Specify the module formally, by providing its interface and contract.
5. Design and implement a test case; document its motivation in the
source code. This test case will now fail, lacking a module implementation.
6. Design and implement module features, intended to make the test
case pass.
7. Test the new module implementation, and fix defects found (back to step
6).
8. Where relevant, improve the structure of the code (refactoring), pre-
serving correctness by running all test cases again (regression testing).
9. Repeat from step 5, until the entire module has been implemented and
tested.
10. If, after delivery, a defect is reported for the module in vivo, then, first,
add a test case to detect that defect in vitro, and only then repair the
defect.
1.2 Why: motivation for TDD
Why should one test software before delivery?
• Humans make mistakes and introduce defects.
• Defects reduce the product’s quality.
• The longer a defect remains undetected, the higher the cost of repairing
it.
3
Julia Hofs
2IPC0 Programming methods
TU Eindhoven
April 20, 2017
,Contents
1 Test-driven development 3
1.1 How: TDD steps . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2 Why: motivation for TDD . . . . . . . . . . . . . . . . . . . . . . 3
2 From callbacks to design patterns 5
2.1 Callbacks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.2 Callbacks in Java . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.3 Defining an anonymous callback on the fly . . . . . . . . . . . . . 6
2.4 Wrapping a class to provide a callback . . . . . . . . . . . . . . . 7
2.5 Distributing a callback to other callbacks . . . . . . . . . . . . . 9
2.6 Modifying and filtering data as it is transferred . . . . . . . . . . 11
2.7 Data processing toolkit and trade-offs . . . . . . . . . . . . . . . 13
2.8 Listeners . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.9 Observers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.10 Push to observer; or pull from subject, or both . . . . . . . . . . 14
2.11 Update or query the observers, or both . . . . . . . . . . . . . . . 15
2.12 Concluding remarks . . . . . . . . . . . . . . . . . . . . . . . . . 15
3 Design patterns 16
3.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
3.2 Singleton . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
3.3 Iterator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
3.4 Adapter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
3.5 Decorator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
3.6 State . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
3.7 Strategy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
3.8 Factory method . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
3.9 Observer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
3.10 Facade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.11 Template method . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.12 Composite . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
3.13 Command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
3.14 Related patterns . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
2
, 1 Test-driven development
Test-driven development, abbreviated as TDD, is a technique that concerns
the development process, rather than the structure of the developed product.
1.1 How: TDD steps
These are the TDD development steps as performed in this course:
1. Gather and analyze the requirements to realize, e.g. use cases or user
stories (these will be given in this course).
2. Decide which requirement to develop next, and what module it concerns.
3. Specify the module informally in the source code, using natural lan-
guage.
4. Specify the module formally, by providing its interface and contract.
5. Design and implement a test case; document its motivation in the
source code. This test case will now fail, lacking a module implementation.
6. Design and implement module features, intended to make the test
case pass.
7. Test the new module implementation, and fix defects found (back to step
6).
8. Where relevant, improve the structure of the code (refactoring), pre-
serving correctness by running all test cases again (regression testing).
9. Repeat from step 5, until the entire module has been implemented and
tested.
10. If, after delivery, a defect is reported for the module in vivo, then, first,
add a test case to detect that defect in vitro, and only then repair the
defect.
1.2 Why: motivation for TDD
Why should one test software before delivery?
• Humans make mistakes and introduce defects.
• Defects reduce the product’s quality.
• The longer a defect remains undetected, the higher the cost of repairing
it.
3
