On Tue, 13 Oct 2015 10:43:09 +0200
Arvin Schnell <[email protected]> wrote:
> On Tue, Oct 13, 2015 at 08:55:48AM +0200, Ancor Gonzalez Sosa wrote:
>
> > Yes. And it should be fairly easy to implement. But I still wonder
> > about how flexible and future-proof is to keep adding find_by_xx on
> > demand to the API.
> >
> > More flexible solutions would also be more complex to use for sure.
> > I just wonder if they are worth exploring. One obvious solution
> > (that would need refinement, of course) if having a search object
> > that accepts any number of key-pair filters. The most primitive
> > form just to expose the idea would be something like (in
> > pseudocode):
> >
> > s = Storage.search(device_graph, "filesystem")
> > s.add_filter("mountpoint", "/")
> > s.first()
>
> 1. This API converts compile-time checks to runtime errors,
> e.g. if you search for a flag that does not exist.
agreed. It should be what kind you search for. So it is better to have
something like search_filesystem
>
> 2. It's not type-safe in that the s.first() cannot return a
> Filesystem object but only a Device and then you need all the
> manual casts you don't want
above solve it.
.
>
> 3. The search function must be adapted for every new object and
> flag. Why is that be better than adding a find_by_xx function
> (in the class where xx is)?
Difference is that it should define Kind and not Target object.
Basically with find_by_xxx we are back in target_map times.
>
> > Or any other idea that can be implemented with a fixed set of
> > classes and methods instead of extending the existing classes with
> > new custom methods over time.
>
> The set of classes is not fixed. On research already people
> requested to have plugins to support new storage types so any
> design that has a central search function like above looks
> inappropriate.
Basically for plugins the best design is to have good concept base
class like filesystem, container that have methods that allows them
to connect to rest of graph
In general I think we should follow already know principles of good OO
design like open/closed principle
https://en.wikipedia.org/wiki/Open/closed_principle ,
SOLID or KISS
Josef
>
> ciao
> Arvin
>
--
To unsubscribe, e-mail: [email protected]
To contact the owner, e-mail: [email protected]
