Prev: set a single click event for a large group of buttons on a form?
Next: c# and hyper access
From: Peter Duniho on 2 Jan 2010 14:21
Federico Degrandis wrote:
>> 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?

Unfortunately, you haven't provided enough detail for me to know what
the answer to that question is. Why is GetResults() a member of the
Feature class rather than the Bus class? Can you not simply pass a
reference to an instance of the Bus class to the GetResults() method?
Could the Feature class know about the Bus instance some other way?
Alternatively, can some other code have the Bus instance start some
operations, and then pass those results to the Feature class? Are you
dealing with a strictly single-threaded implementation here, or is there
some asynchronous behavior involved?

Those are just a few of the questions that come to mind.

The question so far is very sparsely described. Too sparse for me to
see any specific answer.

Pete
From: Federico Degrandis on 3 Jan 2010 14:39
So, I have to manage a flow which comes from a bus (I have to manage two or
more kind of bus).
The flow is composed by one or more sensor data and with the GetSensor(Num)
method I get only data for the specified sensor.
Each sensor data has three or more components (Accelerometer, Magnetomer,
etc... I have to manage custom components with a
plugin system)...Then I have to apply some filter to the data components and
at the end we have the GetResults (from Feature class)
method that should start the flow or better should say to the Bus instance
to start the flow acquisition. When the flow acquisition starts
the bus class will pass the data to the Sensor instance which will extract
its data and so on.

> Are you dealing with a strictly single-threaded implementation here, or is
> there some asynchronous behavior involved?

I'm dealing with a multi-threaded implementation. I have one thread for each
sensor
(if the user call GetSensor(num) three times
instanceBus.GetSensor(1).....GetResults() ,
instanceBus.GetSensor(2).....GetResults() there'll be
two threads)

Thanks
Federico




"Peter Duniho" <no.peted.spam(a)no.nwlink.spam.com> ha scritto nel messaggio
news:eoTvJD#iKHA.1572(a)TK2MSFTNGP04.phx.gbl...
> Federico Degrandis wrote:
>>> 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?
>
> Unfortunately, you haven't provided enough detail for me to know what the
> answer to that question is. Why is GetResults() a member of the Feature
> class rather than the Bus class? Can you not simply pass a reference to
> an instance of the Bus class to the GetResults() method? Could the Feature
> class know about the Bus instance some other way? Alternatively, can some
> other code have the Bus instance start some operations, and then pass
> those results to the Feature class? Are you dealing with a strictly
> single-threaded implementation here, or is there some asynchronous
> behavior involved?
>
> Those are just a few of the questions that come to mind.
>
> The question so far is very sparsely described. Too sparse for me to see
> any specific answer.
>
> Pete

From: Peter Duniho on 3 Jan 2010 15:49
It would have been helpful, to me at least, if you had answered each of
my questions, point by point. I didn't pose them rhetorically.

That said�

Federico Degrandis wrote:
> So, I have to manage a flow which comes from a bus (I have to manage two
> or more kind of bus).
> The flow is composed by one or more sensor data and with the
> GetSensor(Num) method I get only data for the specified sensor.

I assume by "get only data for", you actually mean GetSensor(num)
returns an object representing a specific sensor, and from that object
you can get the data the sensor comprises (e.g. the "three or more
components" you mentioned).

> Each sensor data has three or more components (Accelerometer,
> Magnetomer, etc... I have to manage custom components with a
> plugin system)...Then I have to apply some filter to the data components
> and at the end we have the GetResults (from Feature class)

Again, why is GetResults() in the Feature class? What _is_ the Feature
class? Why does it even exist? What is its relationship to the other
classes?

> method that should start the flow or better should say to the Bus
> instance to start the flow acquisition. When the flow acquisition starts
> the bus class will pass the data to the Sensor instance which will
> extract its data and so on.

Does the same data come from the bus, regardless of whether you've
actually retrieved a specific Sensor object? Or does the Bus only emit
data for the Sensor objects that exist?

>> Are you dealing with a strictly single-threaded implementation here,
>> or is there some asynchronous behavior involved?
>
> I'm dealing with a multi-threaded implementation. I have one thread for
> each sensor
> (if the user call GetSensor(num) three times

Did you really mean to write "three times"? Because the example you
give shows only two calls to GetSensor().

> instanceBus.GetSensor(1).....GetResults() ,
> instanceBus.GetSensor(2).....GetResults() there'll be
> two threads)

Where does the data go? What consumes the data? Are the data from all
Sensor instances aggregated somehow, or is each data stream from a given
Sensor consumed individually?

I have the sense that this has nothing to do with fluent interfaces. So
hopefully, that's clear and you're not trying to make a fluent interface
any more (or at least, not for the whole thing�I suppose some subset
might be able to take advantage, such as configuring the filtering).

Besides that, calling GetSensor() really should only retrieve a Sensor
instance. It sounds from your description, it sounds like a call to
GetSensor() causes some implicit change to the Feature class (whatever
that is). But IMHO it would be better design to require the client to
make that change explicit. Side-effects in code almost always lead to
maintenance problems.

In fact, if you approach it that way, I suppose you could still make
that part of the interface fluent also. That is, whatever new method
you add to the Feature class to add a Sensor instance to its flow graph,
that could return the same Feature instance, so that, for example, your
calls might look like:

Sensor sensor1 = ...;

Feature.AddSensor(sensor1).GetResults();

There may be other places where fluency works. I just don't think
you're going to be able to, or even want to, apply the fluent interface
pattern to the entire design.

Pete
From: Federico Degrandis on 3 Jan 2010 16:52
Thanks again for your help and sorry if I haven't answered all the questions
but I was in a hurry and I missed some.

> I assume by "get only data for", you actually mean GetSensor(num) returns
> an object representing a specific sensor, and from that object you can get
> the data the sensor comprises (e.g. the "three or more components" you
> mentioned).

It's right

> Again, why is GetResults() in the Feature class? What _is_ the Feature
> class? Why does it even exist? What is its relationship to the other
> classes?

I could insert the GetResults() method also in the Bus class

A Feature is like a behavior, when I call ApplyFeatures I tell the system to
try to recognize a
specific behavior (for example: the person is standing up, he's running,
etc)

It exists because a feature is an algorithm so I'm going to create a
specific Feature class for each feature

> What is its relationship to the other classes?

I'm doing data processing and the feature extraction is the final part of
this kind of data processing, so when I extract a
feature I get a result.

> Does the same data come from the bus, regardless of whether you've
> actually retrieved a specific Sensor object? Or does the Bus only emit
> data for the Sensor objects that exist?

The Bus class will retrieve all data available in the bus, then each sensor
will retrieve its data.

> Did you really mean to write "three times"? Because the example you give
> shows only two calls to GetSensor().

No, I didn't! Sorry

> Where does the data go? What consumes the data? Are the data from all
> Sensor instances aggregated somehow, or is each data stream from a given
> Sensor consumed individually?

The feature consumes the data, and each data stream is consumed individually
in a separeted thread (a thread for each sensor)

> I have the sense that this has nothing to do with fluent interfaces. So
> hopefully, that's clear and you're not trying to make a fluent interface
> any more (or at least, not for the whole thing�I suppose some subset might
> be able to take advantage, such as configuring the filtering).

I didn't want to use the Fluent Interface pattern, I would like only to call
the methods in a similar way
(Sorry if when I've started the thread I've explained the problem badly)

Yes, I could use the Fluent Interface in the filtering part

> Besides that, calling GetSensor() really should only retrieve a Sensor
> instance. It sounds from your description, it sounds like a call to
> GetSensor() causes some implicit change to the Feature class (whatever
> that is). But IMHO it would be better design to require the client to
> make that change explicit. Side-effects in code almost always lead to
> maintenance problems.

Calling GetSensor(sensNum) doesn't cause any change to the Feature class,
the feature is an algorithm so it works
indifferently either on the sensor1's data either on the sensor2's data.

When I get the bus instance I can call GetSensor more times. The Bus class
will multiplex the data flow
(hence there will be more copies of the flow) and it'll pass the data to
each sensor created (calling GetSensor)


> In fact, if you approach it that way, I suppose you could still make that
> part of the interface fluent also. That is, whatever new method you add
> to the Feature class to add a Sensor instance to its flow graph, that
> could return the same Feature instance, so that, for example, your calls
> might look like:
>
> Sensor sensor1 = ...;
>
> Feature.AddSensor(sensor1).GetResults();
>
> There may be other places where fluency works. I just don't think you're
> going to be able to, or even want to, apply the fluent interface pattern
> to the entire design.

It could be an idea!!

It isn't so easy to understand, if you want I could send you an email with
an image which explains fine the whole system.

Thanks for help!
Federico

"Peter Duniho" <no.peted.spam(a)no.nwlink.spam.com> ha scritto nel messaggio
news:ePCf$YLjKHA.4912(a)TK2MSFTNGP02.phx.gbl...
> It would have been helpful, to me at least, if you had answered each of my
> questions, point by point. I didn't pose them rhetorically.
>
> That said�
>
> Federico Degrandis wrote:
>> So, I have to manage a flow which comes from a bus (I have to manage two
>> or more kind of bus).
>> The flow is composed by one or more sensor data and with the
>> GetSensor(Num) method I get only data for the specified sensor.
>
> I assume by "get only data for", you actually mean GetSensor(num) returns
> an object representing a specific sensor, and from that object you can get
> the data the sensor comprises (e.g. the "three or more components" you
> mentioned).
>
>> Each sensor data has three or more components (Accelerometer, Magnetomer,
>> etc... I have to manage custom components with a
>> plugin system)...Then I have to apply some filter to the data components
>> and at the end we have the GetResults (from Feature class)
>
> Again, why is GetResults() in the Feature class? What _is_ the Feature
> class? Why does it even exist? What is its relationship to the other
> classes?
>
>> method that should start the flow or better should say to the Bus
>> instance to start the flow acquisition. When the flow acquisition starts
>> the bus class will pass the data to the Sensor instance which will
>> extract its data and so on.
>
> Does the same data come from the bus, regardless of whether you've
> actually retrieved a specific Sensor object? Or does the Bus only emit
> data for the Sensor objects that exist?
>
>>> Are you dealing with a strictly single-threaded implementation here, or
>>> is there some asynchronous behavior involved?
>>
>> I'm dealing with a multi-threaded implementation. I have one thread for
>> each sensor
>> (if the user call GetSensor(num) three times
>
> Did you really mean to write "three times"? Because the example you give
> shows only two calls to GetSensor().
>
>> instanceBus.GetSensor(1).....GetResults() ,
>> instanceBus.GetSensor(2).....GetResults() there'll be
>> two threads)
>
> Where does the data go? What consumes the data? Are the data from all
> Sensor instances aggregated somehow, or is each data stream from a given
> Sensor consumed individually?
>
> I have the sense that this has nothing to do with fluent interfaces. So
> hopefully, that's clear and you're not trying to make a fluent interface
> any more (or at least, not for the whole thing�I suppose some subset might
> be able to take advantage, such as configuring the filtering).
>
> Besides that, calling GetSensor() really should only retrieve a Sensor
> instance. It sounds from your description, it sounds like a call to
> GetSensor() causes some implicit change to the Feature class (whatever
> that is). But IMHO it would be better design to require the client to
> make that change explicit. Side-effects in code almost always lead to
> maintenance problems.
>
> In fact, if you approach it that way, I suppose you could still make that
> part of the interface fluent also. That is, whatever new method you add
> to the Feature class to add a Sensor instance to its flow graph, that
> could return the same Feature instance, so that, for example, your calls
> might look like:
>
> Sensor sensor1 = ...;
>
> Feature.AddSensor(sensor1).GetResults();
>
> There may be other places where fluency works. I just don't think you're
> going to be able to, or even want to, apply the fluent interface pattern
> to the entire design.
>
> Pete

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