Programming Methods (2IPC0) Summary Q2 2020
Table of Contents
Handouts .............................................................................................................................. 2
Notation ............................................................................................................................. 2
Specification ...................................................................................................................... 2
Callback ............................................................................................................................ 2
Test-Driven development................................................................................................... 3
UML Diagram .................................................................................................................... 4
Design Patterns .................................................................................................................... 6
Singleton (Creational) ........................................................................................................ 6
Iterator (Behavioral) ........................................................................................................... 7
Adapter (Structural) ........................................................................................................... 8
Decorator (Structural) ........................................................................................................ 9
State (Behavioral) ............................................................................................................ 10
Strategy (Behavioral) ....................................................................................................... 11
Factory method (Creational) ............................................................................................ 12
Observer (Behavioral) ..................................................................................................... 13
Façade (Structural) .......................................................................................................... 13
Template Method (Behavioral) ........................................................................................ 14
Composite (Structural) ..................................................................................................... 15
Command (Behavioral) .................................................................................................... 15
Slides .................................................................................................................................. 16
Kick-off lecture................................................................................................................. 16
Lecture 1 ......................................................................................................................... 16
Lecture 2 ......................................................................................................................... 17
Lecture 3 ......................................................................................................................... 18
Lecture 4 ......................................................................................................................... 18
Lecture 5 ......................................................................................................................... 19
Lecture 6 ......................................................................................................................... 19
Lecture 7 ......................................................................................................................... 20
1
Programming Methods (2IPC0) summary Q2 2020 by Isabel Rutten
,Handouts
Notation
Quantified expression take the form (quantifier quantified-var-decls; predicate; spec-
expression) where quantifier is the operator; quantified-var-decls introduces the dummy or
dummies which are officially required to include a type but when clear from the context we
omit this; predicate expresses the range for the dummy where leaving out is the same as
writing true; spec-expression is the quantified term of appropriate type.
Precondition and postcondition are predicates. Modifies clauses provides list of all variables
that the method can modify. Return clause is an expression of method’s return type.
“Returns: F” and “Postcondition: \result == F” express the same.
Special JML symbols: \result in postconditions for return value of method that follows;
\old(expression) in postconditions/returns clauses for referring to value of expression at time
of entry into a method
e.g.: for all 𝑎, if 𝑎|6, then also a|2 & a|3: (\forall int a; a % 6 == 0; a % 2 == 0 && a % 3 == 0)
Specification
Formal definitions should first aim at understandability. The same thing can be written in
multiple ways but you want the most understandable one.
Split longer definitions by making separate predicates.
It is useful to define auxiliary predicates (Divide and Conquer).
It is helpful to parameterize the definition as it makes it easier to express properties. Do not
make everything a parameter as that can clutter the notation.
After giving formal definition, useful to rewrite it into alternative forms, depending on its role
in the reasoning (e.g. established/exploited). May improve understanding or problem solving.
Balance formality depending on purpose: in user interface, it’s hard to be formal. So weight
the effort and benefits for the level of formality.
Changing a single symbol can make a huge difference in meaning.
So, formal definitions must be written as clearly as possible + are advisably accompanied by
informal description to state and prove some elementary properties of the defined concept.
Callback
Want to incorporate code of functionality B into functionality A:
- merging code. Con: harder to test/reuse, may break functionality, hard coupling
- divide and conquer - function as parameter (callback)
Put function as a method inside a class and pass object of the class as parameter for even
more flexibility, we typically define an interface that contains signature of callback method.
=> Dependency Inversion Principle (DIP): depend on abstractions (interface), not on
concrete implementations.
Strategy pattern: each way of processing (B) is referred to as a strategy
In the end all about decoupling (reducing dependencies so easier to test/change code) and
avoiding code duplication.
2
Programming Methods (2IPC0) summary Q2 2020 by Isabel Rutten
, Test-Driven development
TDD is a technique that concerns the development process rather than the developed
product. The development is driven by tests. Steps:
1. Gather and analyze requirements.
2. Decide which requirements to develop next and what module it concerns.
3. Specify the module informally in source code, using natural language.
4. Specify the module formally, by providing its interface and contract.
5. Design and implement a test case and document its motivation in source code.
6. Design and implement module features, intended to make the test case pass.
7. Test the new module implementation and fix defects found (to step 6).
8. Where relevant improve structure (refactor) preserving correctness (regression testing).
9. Repeat from step 5 until the entire module has been implemented and tested.
10. If a defect is reported after delivery: first add test case, then fix defect.
Motivation for TDD: the longer a defect remains undetected, the higher the cost of fixing it.
Written down test cases are better verifiable and reproducible, serve as documentation and
are used to verify the requirements if test case state motivation, input, output, pass criteria.
Automated test cases are more convenient, faster and more reliable. It makes it easier to
find bugs, requirements are operationalized, interfaces and contracts are stabilized, it
encourages analysis before implementation, there’s no interruption between test and fixing.
TDD for a single function: single function:
/**
* informal specification, elaborated to remove ambiguities and imprecisions
* formal specifications/contract with @param, @return, @pre, @post
*/
public state Type nameFunction(TypeInput, inputName) {
implemented function using inputName
}
Test for a single function:
import static org.junit.Assert.*;
import org.junit.Test;
/* invokes nameFunction and checks result
* formal specifications/contract with @param, @pre
*/
private void checkNameFunction(TypeInput inputName, expResult) {
System.out.println(“…”.assertEquals(“result”, expres; result); }
/* Test of … *\
@Test
public void testCountDigits9() {
checkNameFunction(9L, 1);
}
One can add more such test cases to improve code based on these test cases.
Here are the steps for developing a class that will serve as an Abstract Data Type (ADT):
1. Gather and analyze the requirements to realize, e.g. use cases or user stories.
2. Decide which requirements to develop next, and what module it concerns.
3. Specify the class informally:
a) Provide a one-sentence summary of the class in a Javadoc comment;
b) Choose an appropriate class name;
c) When relevant, choose generic type parameters and their constraints;
d) Elaborate the informal description to obtain a more complete description of the class as a
whole, from the perspective of a client of the class
3
Programming Methods (2IPC0) summary Q2 2020 by Isabel Rutten
Table of Contents
Handouts .............................................................................................................................. 2
Notation ............................................................................................................................. 2
Specification ...................................................................................................................... 2
Callback ............................................................................................................................ 2
Test-Driven development................................................................................................... 3
UML Diagram .................................................................................................................... 4
Design Patterns .................................................................................................................... 6
Singleton (Creational) ........................................................................................................ 6
Iterator (Behavioral) ........................................................................................................... 7
Adapter (Structural) ........................................................................................................... 8
Decorator (Structural) ........................................................................................................ 9
State (Behavioral) ............................................................................................................ 10
Strategy (Behavioral) ....................................................................................................... 11
Factory method (Creational) ............................................................................................ 12
Observer (Behavioral) ..................................................................................................... 13
Façade (Structural) .......................................................................................................... 13
Template Method (Behavioral) ........................................................................................ 14
Composite (Structural) ..................................................................................................... 15
Command (Behavioral) .................................................................................................... 15
Slides .................................................................................................................................. 16
Kick-off lecture................................................................................................................. 16
Lecture 1 ......................................................................................................................... 16
Lecture 2 ......................................................................................................................... 17
Lecture 3 ......................................................................................................................... 18
Lecture 4 ......................................................................................................................... 18
Lecture 5 ......................................................................................................................... 19
Lecture 6 ......................................................................................................................... 19
Lecture 7 ......................................................................................................................... 20
1
Programming Methods (2IPC0) summary Q2 2020 by Isabel Rutten
,Handouts
Notation
Quantified expression take the form (quantifier quantified-var-decls; predicate; spec-
expression) where quantifier is the operator; quantified-var-decls introduces the dummy or
dummies which are officially required to include a type but when clear from the context we
omit this; predicate expresses the range for the dummy where leaving out is the same as
writing true; spec-expression is the quantified term of appropriate type.
Precondition and postcondition are predicates. Modifies clauses provides list of all variables
that the method can modify. Return clause is an expression of method’s return type.
“Returns: F” and “Postcondition: \result == F” express the same.
Special JML symbols: \result in postconditions for return value of method that follows;
\old(expression) in postconditions/returns clauses for referring to value of expression at time
of entry into a method
e.g.: for all 𝑎, if 𝑎|6, then also a|2 & a|3: (\forall int a; a % 6 == 0; a % 2 == 0 && a % 3 == 0)
Specification
Formal definitions should first aim at understandability. The same thing can be written in
multiple ways but you want the most understandable one.
Split longer definitions by making separate predicates.
It is useful to define auxiliary predicates (Divide and Conquer).
It is helpful to parameterize the definition as it makes it easier to express properties. Do not
make everything a parameter as that can clutter the notation.
After giving formal definition, useful to rewrite it into alternative forms, depending on its role
in the reasoning (e.g. established/exploited). May improve understanding or problem solving.
Balance formality depending on purpose: in user interface, it’s hard to be formal. So weight
the effort and benefits for the level of formality.
Changing a single symbol can make a huge difference in meaning.
So, formal definitions must be written as clearly as possible + are advisably accompanied by
informal description to state and prove some elementary properties of the defined concept.
Callback
Want to incorporate code of functionality B into functionality A:
- merging code. Con: harder to test/reuse, may break functionality, hard coupling
- divide and conquer - function as parameter (callback)
Put function as a method inside a class and pass object of the class as parameter for even
more flexibility, we typically define an interface that contains signature of callback method.
=> Dependency Inversion Principle (DIP): depend on abstractions (interface), not on
concrete implementations.
Strategy pattern: each way of processing (B) is referred to as a strategy
In the end all about decoupling (reducing dependencies so easier to test/change code) and
avoiding code duplication.
2
Programming Methods (2IPC0) summary Q2 2020 by Isabel Rutten
, Test-Driven development
TDD is a technique that concerns the development process rather than the developed
product. The development is driven by tests. Steps:
1. Gather and analyze requirements.
2. Decide which requirements to develop next and what module it concerns.
3. Specify the module informally in source code, using natural language.
4. Specify the module formally, by providing its interface and contract.
5. Design and implement a test case and document its motivation in source code.
6. Design and implement module features, intended to make the test case pass.
7. Test the new module implementation and fix defects found (to step 6).
8. Where relevant improve structure (refactor) preserving correctness (regression testing).
9. Repeat from step 5 until the entire module has been implemented and tested.
10. If a defect is reported after delivery: first add test case, then fix defect.
Motivation for TDD: the longer a defect remains undetected, the higher the cost of fixing it.
Written down test cases are better verifiable and reproducible, serve as documentation and
are used to verify the requirements if test case state motivation, input, output, pass criteria.
Automated test cases are more convenient, faster and more reliable. It makes it easier to
find bugs, requirements are operationalized, interfaces and contracts are stabilized, it
encourages analysis before implementation, there’s no interruption between test and fixing.
TDD for a single function: single function:
/**
* informal specification, elaborated to remove ambiguities and imprecisions
* formal specifications/contract with @param, @return, @pre, @post
*/
public state Type nameFunction(TypeInput, inputName) {
implemented function using inputName
}
Test for a single function:
import static org.junit.Assert.*;
import org.junit.Test;
/* invokes nameFunction and checks result
* formal specifications/contract with @param, @pre
*/
private void checkNameFunction(TypeInput inputName, expResult) {
System.out.println(“…”.assertEquals(“result”, expres; result); }
/* Test of … *\
@Test
public void testCountDigits9() {
checkNameFunction(9L, 1);
}
One can add more such test cases to improve code based on these test cases.
Here are the steps for developing a class that will serve as an Abstract Data Type (ADT):
1. Gather and analyze the requirements to realize, e.g. use cases or user stories.
2. Decide which requirements to develop next, and what module it concerns.
3. Specify the class informally:
a) Provide a one-sentence summary of the class in a Javadoc comment;
b) Choose an appropriate class name;
c) When relevant, choose generic type parameters and their constraints;
d) Elaborate the informal description to obtain a more complete description of the class as a
whole, from the perspective of a client of the class
3
Programming Methods (2IPC0) summary Q2 2020 by Isabel Rutten
