Design By Contract uses preconditions and postconditions of the public
methods in a class together to form a contract between the class and
its clients.
a) In code we implement preconditions and postconditions either as assertions or as exceptions?
b) We implement preconditions and postconditions in code as exceptions if not fulfilling preconditions or postconditions doesn’t indicate logically impossible situations or programming errors?
c) we implement them in code as assertions when not fulfilling preconditions or postconditions does indicate logically impossible situations or programming errors?
d) Should preconditions and postconditions only be defined on public methods?
EDIT:
Aren’t the following checks considered to be part of a normal operation ( and as I already mentioned, I’ve seen plenty of articles on DbC using similar examples for preconditions, where checks were made against arguments supplied by the user ), since if the user enters bad data, then without checks operation won’t be rejected and as such system will stop working according to specs:
Link:
public User GetUserWithIdOf(int id,
UserRepository userRepository) {
// Pre-conditions
if (userRepository == null)
throw new ArgumentNullException(
"userRepository");
if (id <= 0)
throw new ArgumentOutOfRangeException(
"id must be > 0");
User foundUser = userRepository.GetById(id);
// Post-conditions
if (foundUser == null)
throw new KeyNotFoundException("No user with " +
"an ID of " + id.ToString() +
" could be located.");
return foundUser;
}
2
a) In code we implement preconditions and postconditions either as assertions or as exceptions?
Strictly, no. The pre/postcondition is actually the test that raises the exception. The exception is merely the way of saying that pre/postcontion has been violated.
b) We implement preconditions and postconditions in code as exceptions if not fulfilling preconditions or postconditions doesn’t indicate logically impossible situations or programming errors?
No. People often use explicit test / raise exception code to indicate a bug, etc.
c) we implement them in code as assertions when not fulfilling preconditions or postconditions does indicate logically impossible situations or programming errors?
You can do. But see above.
d) Should preconditions and postconditions only be defined on public methods?
No. If you are using them (formally) there is no reason to restrict them to public methods.
Actually, the key difference between the two approaches is that you can (typically) turn off checking of the “assertion” style of pre/postconditions (e.g. Java’s assert statements) when you move your code into production. In the case of Java, this is typically done using a JVM command line option.
This means that you shouldn’t use assertion style pre/postconditions for checks that are part of “normal operation” … like validating user input. In fact, you probably shouldn’t treat them as pre/postconditions at all. They are part of the program’s active functionality (for the lack of a better way of describing it …)
3
You should define them as assumptions, (in debugging as assertions) so if the pre or post condition isn’t true then you have an logical error in in your program.
The key point here is avoiding the test in production code to speed it up,
for example a binary search can go in O(log n) time only if the array is already sorted (precondition) but testing this (for the exception) takes O(n) so if you test for that you might as well go for the linear search and get an early return out of it.
They can be defined on any piece of code (i.e. anything that can be extracted into a method).