szaghi
commented
8 years ago Hi all,
I am going to try the Abstract Factory Pattern as the one shown into the Rouson et. al book Scientific Software Design: The Object-Oriented Way, ISBN:0521888131 9780521888134. Into the book there is a very nice, yet not so simple, application example concerning the solution of the Burgers' equation. You can find the codes here. I am very worried that I have not completely "assimilated" the Rouson's lessons, thus I will try explain my efforts here.
desiderata API
I would like to have an abstract type (the factory type) that will build each actual WENO interpolator under the user demand. Says:
- provide a very simple user API for initializing and using the selected WENO interpolator;
- allow developers to easily implement their own interpolator:
- provide an abstract factory the interface of which should:
- initialize the actual WENO interpolator accordingly to the user settings;
- interpolate the user data;
- finalize the interpolator correctly when is necessary;
- provide auxiliary methods being of general utility.
Rouson's Abstract Factory Pattern... in my mind
I woul like to allow the user to perform something like:
class(weno_interpolator), pointer :: weno
class(weno_interpolator_factory), allocatable :: weno_creator
allocate (weno_interpolator_upwind_factory :: weno_creator)
weno => weno_creator%create(...) ! with the necessary arguments specific for upwind-like weno
do while (I_want_is_true)
interpolated = weno%interpolate()
...
enddo where:
- the abstract creator is necessary for dealing with different types of WENO, see my final thought of this post;
- the
wenovariable remains abstract until it is concretely instantiated with the upwind type by means of the upwind-type creator.
However, If I understand right (at least superficially) the Rouson's lessons, in order to allow such a scenario, we need at least 4 modules:
use weno_interpolator_module
use weno_interpolator_factory_module
use weno_interpolator_upwind_module
use weno_interpolator_upwind_factory_modulean abstract WENO interpolator
type, abstract :: weno_interpolator
contains
procedure, deferred :: foo
...
end typea concrete WENO interpolator
type, extends(weno_interpolator) :: weno_interpolator_upwind
contains
private
procedure :: interpolate
procedure :: compute_smothness_indicators
...
end typean abstract WENO interpolator factory
type, abstract :: weno_interpolator_factory
contains
procedure(create_interface), deferred :: create
end type
abstract interface
function create_interface(self, etc...)
import :: field_factory
class(weno_interpolator_factory), intent(in) :: self
class(weno_interpolator), pointer :: create_interface
end function
end interfacea concrete WENO interpolator factory
type, extends(weno_interpolator_factory) :: weno_interpolator_upwind_factory
contains
procedure :: create => create_weno_interpolator_upwind
end type
contains
function create_weno_interpolator_upwind(self, etc...)
use weno_interpolator_upwind_module, only : weno_interpolator_upwind
class(weno_interpolator_upwind_factory), intent(in) :: self
class(weno_interpolator), pointer :: create_weno_interpolator_upwind
create_weno_interpolator_upwind => weno_interpolator_upwind(...)
end function First thoughts
- too many modules;
- too many types;
- user can be confused by abstract and concrete types;
- ... what a confusion...
As a consequence: is an abstract factory pattern over-killing the problem? Or simply, did I mislead Rouson et al.?
My opinion is now that a simple abstract type provided as contract to the developers could be enough. Or at least, we can simplify the above pattern, relying on a simpler Factory one (not completely abstract).
A first issue
Different WENO flavors need different inputs and provide different outputs, e.g. the upwind biased approaches (on which I am familiar) typically perform the interpolation on two subsequent locations for avoiding doubling the computations of some variables, whereas other approaches (e.g. CWENO, but I am not sure) could not care about this being better constructed and thus providing the interpolation at just one location. In this case the data hiding and encapsulation poses an issue: how to deal with different interpolators by the same interface? this is the reason why I think to the Abstract Factory Pattern, but the above issues raised up.
zbeekman
cmacmackin
Hi all,
as I have alreadtingy introduced into issue#2, I would like to exploit Rouson lessons and implement our library via an Object Oriented Way.
Presently, I have not clearly defined which API I would like. Essentially I guess that library should:
In this regards, the input stencils and output interpolated value(s) could be:
The second case is more complex and necessitate an accurate choice of the objects patterns, in particular data encapsulation increases the difficulty and maybe a Factory pattern is not enough. However, also the first more simple API necessity a careful design at least for the internal (to the library) implementation.
Which pattern you suggest and why? I am very newbie in this field. My previous OOP codes are not well designed and do not follow a precise pattern.