Lecture - Imperative Programming TT23, I

Notes

• Key conceptual tools
  • Decomposition/modulatrity
    • The identification and clarification of the boundaries between the major conceptual components of a system or of its implementation.
    • Each components should play a single well understood role.
    • Components should have well-defined interfaces
  • Abstraction
    • Extract the essential conceptual core of a problem or solution from the mass of detail which is not relevant in a particular context.
    • Components should be viewed as black boxes.
    • Can interchange black boxes with identical specifications.
    • Don’t rely on a component’s implementation details.
  • Reusability
• Objects
  • Each ovject has a specification that describes what its operations do, and an implementation that provides code to do it.
  • To use an object we only need to know the specification or public interface; different implementations can be used interchangeably.
• Classes
  • Objects are instances of classes that define the data and operations for a family of similar objects
  • The power of OOP comes from being able to use many different predefined classes and to make our own classes.
• Object identity
  • Multiple instances of a class should have seperate “identities”, changing one should not change another.
  • Object identities can be copied without copying the whole object. This is known as aliasing.
  • Scala has a eq b to test object identity.
  • Could be defined using pointers to memory location, but this has issues where clever pointer arithmetic can bypass encapsulation, like in C.
  • Scala abstracts over this to prevent issues.
• Encapsulation
  • The seperation between the external interface of a component and its internal implementation.
  • Good for debugging because you can ask “who broke their promise” – were pre- or post-conditions not satisfied?
  • “Design by contract”; writing specifications using pre- and post-conditions.

Flashcards (GPT-4)