Prev: set a single click event for a large group of buttons on a form?
Next: c# and hyper access
From: Federico Degrandis on 1 Jan 2010 11:15
Hello everyone!
I should implement a kind of fluent interface I'm just a little perplexed
about how to do:

GetBus (Bus interface)
.. GetSensor (NumSens)
.. GetComponent (Name)
.. GetDimension (Name)
.. ApplyFilter (filtername)
.. ApplyFilter (filtername)
.. ApplyFeatures (FeatureName)
.. GetResults ()

These are basically methods that the user can call and have to be invoked
in this order (the ApplyFilter can called several times)

GetBus returns an instance of Bus, GetSensor instance of Sensor
GetComponent instance of Component and so on.

At first I thought to put the method GetBus inside a class
FluentFlow, GetSensor inside the Bus class and GetComponent in Sensor class.
The problem is that at the end GetResults must interact with the instance of
Bus (in order to
run some threads).

The solutions that came to my mind are:
- Use some kind of message broker where basically the class that
contains the method getResults () tells the instance of Bus to run the
thread
- Include all methods in the FluentFlow class (the problem is that they
only be called in that order)
- Create classes XXXFluentInterface managed by the FluentFlow class in order
to
handle even the order of the methods (GetBus will return BusFluentInterface
that will have a method GetSensor returning SensorFluentInterface)

Any idea?

Cheers
Federico

From: Peter Duniho on 1 Jan 2010 17:29
Federico Degrandis wrote:
> Hello everyone!
> I should implement a kind of fluent interface

Why? Where does this requirement come from?

> I'm just a little
> perplexed about how to do:
>
> GetBus (Bus interface)
> .. GetSensor (NumSens)
> .. GetComponent (Name)
> .. GetDimension (Name)
> .. ApplyFilter (filtername)
> .. ApplyFilter (filtername)
> .. ApplyFeatures (FeatureName)
> .. GetResults ()
>
> These are basically methods that the user can call and have to be invoked
> in this order (the ApplyFilter can called several times)

It is not clear why the methods must be called in a particular order.
Is it that you have to have a Bus to call GetSensor()? And that you
have to have a Sensor to call GetComponent()? And that you have to have
a Component to call GetDimension()?

Or something else?

If the former, then this seems fundamentally incompatible with a fluent
interface, which presupposes that each call can return the same object
that was used to make that call.

If it's something else, then you should elaborate on why the order is
important. In general, having a specific order of operations imposed on
an interface suggests that those operations should all be encapsulated
in a single method, rather than forcing the client to comply with the
given order.

> GetBus returns an instance of Bus, GetSensor instance of Sensor
> GetComponent instance of Component and so on.
>
> At first I thought to put the method GetBus inside a class
> FluentFlow, GetSensor inside the Bus class and GetComponent in Sensor
> class.

Whatever you do, don't include the word "fluent" in your class name.
Design patterns are implicit in the type's interface; there's no need to
put the pattern's name in the type's name itself.

> The problem is that at the end GetResults must interact with the
> instance of Bus (in order to run some threads).

Then it seems to me the fluent interface pattern doesn't apply.

> The solutions that came to my mind are:
> - Use some kind of message broker where basically the class that
> contains the method getResults () tells the instance of Bus to run the
> thread
> - Include all methods in the FluentFlow class (the problem is that they
> only be called in that order)
> - Create classes XXXFluentInterface managed by the FluentFlow class in
> order to
> handle even the order of the methods (GetBus will return
> BusFluentInterface that will have a method GetSensor returning
> SensorFluentInterface)

All of the above are only "solutions" in that they shoehorn some other
design into the fluent interface pattern. Design patterns aren't there
to be forced upon the code; they exist to be used when the code already
lends itself nicely to the pattern.

Absent any other information, I'd say the real solution is to not force
the fluent interface pattern on the entirety of the code. It may well
still apply within some specific objects you have, but to try to force
the entire interface into a fluent pattern doesn't appear to be useful
in this case.

Pete
From: Federico Degrandis on 1 Jan 2010 21:01
Hi peter, thanks for reply!
I know that it's not a fluent interface or better it doesn't supply the
fluent interface pattern but I need something similar

> It is not clear why the methods must be called in a particular order. Is
> it that you have to have a Bus to call GetSensor()? And that you have to
> have a Sensor to call GetComponent()? And that you have to have a
> Component to call GetDimension()?

Yes!

I choose to use something similar to the fluent interface because it's more
simple to understand to the
developers that are going to use the library.

I need to call the methods in this order because they are processing a data
flow.

What do you suggest?

Thanks
Federico

PS: sorry for my poor english!

"Peter Duniho" <no.peted.spam(a)no.nwlink.spam.com> ha scritto nel messaggio
news:OaykdHziKHA.1540(a)TK2MSFTNGP06.phx.gbl...
> Federico Degrandis wrote:
>> Hello everyone!
>> I should implement a kind of fluent interface
>
> Why? Where does this requirement come from?
>
>> I'm just a little perplexed about how to do:
>>
>> GetBus (Bus interface)
>> .. GetSensor (NumSens)
>> .. GetComponent (Name)
>> .. GetDimension (Name)
>> .. ApplyFilter (filtername)
>> .. ApplyFilter (filtername)
>> .. ApplyFeatures (FeatureName)
>> .. GetResults ()
>>
>> These are basically methods that the user can call and have to be invoked
>> in this order (the ApplyFilter can called several times)
>
> It is not clear why the methods must be called in a particular order. Is
> it that you have to have a Bus to call GetSensor()? And that you have to
> have a Sensor to call GetComponent()? And that you have to have a
> Component to call GetDimension()?
>
> Or something else?
>
> If the former, then this seems fundamentally incompatible with a fluent
> interface, which presupposes that each call can return the same object
> that was used to make that call.
>
> If it's something else, then you should elaborate on why the order is
> important. In general, having a specific order of operations imposed on
> an interface suggests that those operations should all be encapsulated in
> a single method, rather than forcing the client to comply with the given
> order.
>
>> GetBus returns an instance of Bus, GetSensor instance of Sensor
>> GetComponent instance of Component and so on.
>>
>> At first I thought to put the method GetBus inside a class
>> FluentFlow, GetSensor inside the Bus class and GetComponent in Sensor
>> class.
>
> Whatever you do, don't include the word "fluent" in your class name.
> Design patterns are implicit in the type's interface; there's no need to
> put the pattern's name in the type's name itself.
>
>> The problem is that at the end GetResults must interact with the instance
>> of Bus (in order to run some threads).
>
> Then it seems to me the fluent interface pattern doesn't apply.
>
>> The solutions that came to my mind are:
>> - Use some kind of message broker where basically the class that
>> contains the method getResults () tells the instance of Bus to run the
>> thread
>> - Include all methods in the FluentFlow class (the problem is that they
>> only be called in that order)
>> - Create classes XXXFluentInterface managed by the FluentFlow class in
>> order to
>> handle even the order of the methods (GetBus will return
>> BusFluentInterface that will have a method GetSensor returning
>> SensorFluentInterface)
>
> All of the above are only "solutions" in that they shoehorn some other
> design into the fluent interface pattern. Design patterns aren't there to
> be forced upon the code; they exist to be used when the code already lends
> itself nicely to the pattern.
>
> Absent any other information, I'd say the real solution is to not force
> the fluent interface pattern on the entirety of the code. It may well
> still apply within some specific objects you have, but to try to force the
> entire interface into a fluent pattern doesn't appear to be useful in this
> case.
>
> Pete

From: Peter Duniho on 1 Jan 2010 23:51
Federico Degrandis wrote:
> Hi peter, thanks for reply!
> I know that it's not a fluent interface or better it doesn't supply the
> fluent interface pattern but I need something similar
>
>> It is not clear why the methods must be called in a particular order.
>> Is it that you have to have a Bus to call GetSensor()? And that you
>> have to have a Sensor to call GetComponent()? And that you have to
>> have a Component to call GetDimension()?
>
> Yes!
>
> I choose to use something similar to the fluent interface because it's
> more simple to understand to the
> developers that are going to use the library.

If it's not a fluent interface but you call it a fluent interface,
you're just going to confuse people.

> I need to call the methods in this order because they are processing a
> data flow.
>
> What do you suggest?

It's still not clear what the issue is. You wrote above that the
particular order is because you have to call a method in one class to
get an instance of another class so you can then call the method in that
other class, etc. Given that, it seems to me that the order of calling
is automatically enforced by that requirement. What more is there to do?

Pete
From: Federico Degrandis on 2 Jan 2010 10:29
> It's still not clear what the issue is. You wrote above that the
> particular order is because you have to call a method in one class to get
> an instance of another class so you can then call the method in that other
> class, etc. Given that, it seems to me that the order of calling is
> automatically enforced by that requirement. What more is there to do?

The issue is that the GetResults method (from the Feature class) has to
"say" to the Bus instance to start some operations.
How could I do?

Thanks
Federico

"Peter Duniho" <no.peted.spam(a)no.nwlink.spam.com> ha scritto nel messaggio
news:eR59Bd2iKHA.1536(a)TK2MSFTNGP06.phx.gbl...
> Federico Degrandis wrote:
>> Hi peter, thanks for reply!
>> I know that it's not a fluent interface or better it doesn't supply the
>> fluent interface pattern but I need something similar
>>
>>> It is not clear why the methods must be called in a particular order. Is
>>> it that you have to have a Bus to call GetSensor()? And that you have
>>> to have a Sensor to call GetComponent()? And that you have to have a
>>> Component to call GetDimension()?
>>
>> Yes!
>>
>> I choose to use something similar to the fluent interface because it's
>> more simple to understand to the
>> developers that are going to use the library.
>
> If it's not a fluent interface but you call it a fluent interface, you're
> just going to confuse people.
>
>> I need to call the methods in this order because they are processing a
>> data flow.
>>
>> What do you suggest?
>
> It's still not clear what the issue is. You wrote above that the
> particular order is because you have to call a method in one class to get
> an instance of another class so you can then call the method in that other
> class, etc. Given that, it seems to me that the order of calling is
> automatically enforced by that requirement. What more is there to do?
>
> Pete

 |  Next  |  Last
Pages: 1 2
Prev: set a single click event for a large group of buttons on a form?
Next: c# and hyper access