Skip to main content Accessibility help
×
Hostname: page-component-84b7d79bbc-g7rbq Total loading time: 0 Render date: 2024-07-26T04:16:43.477Z Has data issue: false hasContentIssue false

3 - Scientific OOP

from PART I - THE TAO OF SCIENTIFIC OOP

Published online by Cambridge University Press:  01 June 2011

Damian Rouson
Affiliation:
Sandia National Laboratories
Jim Xia
Affiliation:
IBM Canada Lab in Markham
Xiaofeng Xu
Affiliation:
General Motors Corp.
Get access

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.

Type
Chapter
Information
Scientific Software Design
The Object-Oriented Way
, pp. 57 - 82
Publisher: Cambridge University Press
Print publication year: 2011

Access options

Get access to the full version of this content by using one of the access options below. (Log in options will check for institutional or personal access. Content may require purchase if you do not have access.)

Save book to Kindle

To save this book to your Kindle, first ensure coreplatform@cambridge.org is added to your Approved Personal Document E-mail List under your Personal Document Settings on the Manage Your Content and Devices page of your Amazon account. Then enter the ‘name’ part of your Kindle email address below. Find out more about saving to your Kindle.

Note you can select to save to either the @free.kindle.com or @kindle.com variations. ‘@free.kindle.com’ emails are free but can only be saved to your device when it is connected to wi-fi. ‘@kindle.com’ emails can be delivered even when you are not connected to wi-fi, but note that service fees apply.

Find out more about the Kindle Personal Document Service.

Available formats
×

Save book to Dropbox

To save content items to your account, please confirm that you agree to abide by our usage policies. If this is the first time you use this feature, you will be asked to authorise Cambridge Core to connect with your account. Find out more about saving content to Dropbox.

Available formats
×

Save book to Google Drive

To save content items to your account, please confirm that you agree to abide by our usage policies. If this is the first time you use this feature, you will be asked to authorise Cambridge Core to connect with your account. Find out more about saving content to Google Drive.

Available formats
×