Finalmente, tenemos ya varias clases abstractas que instanciamos mediante la creación de algunas de sus clases concretas hijas en función de un fichero de configuración.
Algunas de estas clases abstractas son: OdeSolver
, SpatialDecomposition
, PdeSolver
, Kernel
, EoS
, Equation
, Display
que pueden ser concretadas en alguna de sus clases herederas (por ejemplo SpatialDecomposition
podria ser instanciada como AllPair
, como LinkedList
o como cualquiera que implementemos posteriormente).
A nivel de código, lo que nos encontramos es lo siguiente:
- En el fichero de configuración aparece algo como
SpatialDecomposition=LinkedList
o<SpatialDecomposition>LinkedList</SpatialDecomposition>
, en función del formato que tenga nuestro fichero de configuración - Este fichero lo lee una clase
Configuracion
que posteriormente es capaz de suministrar esta información. - En algun lugar de nuestro código tenemos
SpatialDecomposition *spatialDecomposition
y una composición alternativa de acciones donde en una de las ramas, la que se corresponde a la información que nos suministraConfiguración
, conspatialDecomposition = new LinkedList(...)
- En la clase abstracta
SpatialDecomposition
tenemos un método virtualgetNNP
que implementan todos sus descendientes, de manera que enLinkedList
tenemos su correspondiente implementación para esta clases concreta. - Cuando realizamos la invocación del método
spatialDecomposition->getNNP(...)
(->
en lugar de.
porque tenemos un puntero a la clase y no la clase) este siempre tendrá este formato independientemente de la clase concreta que tengamos en un momento determinado por debajo, por lo que si posteriormente decidimos utilizarAllPair
, la llamada anterior queda de la misma manera.
Esto permite que exista una capa de abstracción de manera que el conjunto principal de clases trabaja invocando a métodos virtuales de clases abstractas que se transforman en llamadas a métodos concretos de la clases descendiente instanciada de manera trasparente.