3 - Scientific OOP

Summary

“Software abstractions should resemble blackboard abstractions.”

Kevin Long

Abstract Data Type Calculus

A desire for code reuse motivated most of Chapter 2. Using encapsulation and information hiding, we wrapped legacy, structured programs in an object-oriented superstructure without exposing the legacy interfaces. We used aggregation and composition to incorporate the resulting classes into components inside new classes. We also employed inheritance to erect class hierarchies. Finally, we employed dynamic polymorphism to enable child instances to respond to the type-bound procedure invocations written for their parents.

Much of the code in Chapters 1–2 proved amenable to reuse in modeling heat conduction, but few of the object-oriented abstractions presented would find any use for nonthermal calculations. Even to the extent the heat equation models other phenomena, such as Fickian diffusion, calling a procedure named heat_for() to solve the diffusion equation would obfuscate its purpose. This problem could be addressed with window dressing – creating a diffusion-oriented interface that delegates all procedure invocations to the conductor class. Nonetheless, neither the original conductor class nor its diffusion counterpart would likely prove useful in any simulation that solves a governing equation that is not formally equivalent to the heat equation. This begs the question: “When reusing codes, what classes might we best construct from them?”

Most developers would agree with the benefits of breaking a large problem into smaller problems, but choosing those smaller problems poses a quandary without a unique solution.