{week 3}

W18A

What will we cover today?

  • Design By Contract
  • Domain Modelling
  • Debugging
  • Exceptions

Programming Approaches

Defensive Programming

- Proactively identify and handle problematic situations to prevent software failures.


- In practice, this means having a lot of checks before the actual logic is executed (Eg. input checks, null checks etc)


- Trust no one! 😤


Pros: higher safety

Cons: redundant checks, more complex, harder to spot errors due to unclear responsbilities

1.

2.

Design By Contract

- Establish clear responsibilities via a contract (eg. expected input, expected output) at design time. All parties abide by the contract to guarantee correct behaviour.

 

- In practice, this means clearly documenting preconditions, postconditions and class invariants.

 

- Trust me bro🗿

 

Pros: cleaner, reduces redundant checks, faster

Cons: code crashes if contract is broken

Design by Contract (DbC) 📑

Providing an interface for others to use with clear preconditions, postconditions and invariants which, when adhered to, guarantees correct and expected behaviour.

T&C : Terms and Conditions 📝

A contract generally consists of these 3 components:

  • Class Invariant: Something that is true for all instances of a class.
  • Precondition: Something that must be true before an operation is invoked (to guarantee that it will work correctly). Users need should meet such conditions before calling an operation
  • Postcondition: Something that must be true after an operation is invoked. Condition is to be met by the implementor.

Liskov Substitution Principle 🔄

  • LSP is a way to ensure DbC in terms of OOP.
  • I know I used way too many abbreviations here. Alas, I am lazy and the slide is small.

 

The main logic of LSP:

  • Every subclass should be a substitute for its parent class
  • This substitution should never result in unexpected errors

LSP Rules🗽

  • Preconditions cannot be strengthened in a subtype.
  • Postconditions cannot be weakened in a subtype.
  • Invariants of the supertype — conditions that must remain true — must be preserved in a subtype.

Breaking LSP 🐣

  • Give an example of a real-life subclass that would violate the given contract:

public class Bird {
/**
 * Make the bird fly to the given height
 * @precondition given height must be >= 0
 *(birds cannot burrow into the ground)
**/
   public void fly(float height) {}
}

Note: by real-life subclass, I mean some kind of creature that is a type of Bird.

A suggestion 🐧

interface Flying {
 /**
 * Make the creature fly to the given height
 * @precondition given height must be >= 0
*/
 public void fly(float height);
}

// Not all birds can fly
class Bird {}
// We implement it directly for the birds that can
class Hummingbird extends Bird implements Flying {}
// And don't implement it otherwise
class Penguin extends Bird {}
// And we can apply the interface to other creatures,
// even if they're not birds
class Pterosaur extends Reptile implements Flying {}

Exceptions 👀

Exceptions in Java fall under 2 categories:

  • Checked Exceptions: These exceptions are caught at compile time and need to be handled (using a try-catch block). Eg: IOException, ServletException
  • Unchecked Exceptions: These exceptions are caught at run-time and do not need to be handled. Eg: NullPointerException, IllegalArgumentException

Errors 🤯

There's a third category to represent serious and usually irrecoverable conditions like a library incompatibility, infinite recursion, or memory leaks. These are called Errors.

  • Even though they don’t extend RuntimeException, they are also unchecked.
  • In most cases, it’d be weird for us to handle, instantiate or extend Errors. Usually, we want these to propagate all the way up.
  • Eg: StackOverflowError, OutOfMemoryError

Exceptions and Errors

All exceptions and errors in Java extend Throwable.

{The End}

Thank you for attending!

Made with Slides.com