Chapter 8 - Boundaries

• Aim to keep the boundaries of our program clean when using 3rd party packages

• The 3rd party vs the Users

  • 3rd Party: wants their application to be broad and have many uses
  • Users: want 3rd party software to be small, constrained and for a specific use

• If you use a boundary interface keep it in a class (Encapsulated)

  • Do not pass this class liberally around your system
  • Have strict access control to the 3rd party code

• Learning Tests (Boundary Tests)

  • These are tests written using the 3rd party software before implementation in production code
  • Learning takes time and debugging takes time. If we write learning tests:
    • We can learn how the 3rd party code works
    • We can determine if a bug is from the 3rd party package or our code
    • If the 3rd party application updates to a new release we can run the learning test to see if anything in our code will change or work as intended

• Tips for using code that does not exist yet (3rd party code)

  • Assume 3rd party code is at the bounds of the system and work from the opposite end
  • Write a place holder for the boundary code and make sure the production code is working
  • When the boundary becomes known bridge the gap through encapsulation of a class using the 3rd party code
  • Change always happens at the boundary. Good code accommodates for those changes
  • Keep a clear seperation between the boundary code and your production code