|
Focus your design effort on the highest level business logic and unique requirements.
'Patterns' are a trap.
Specifically, if you have some message coming in on your port,
Your design will consist of a description of that message, and the action taken.
Whether your code 'Polls' or uses 'Events' is irrelevant to this design.
At one layer or another we are ALWAYS polling:
These are your options:
Write code that 'polls'.
Use a library that polls on another thread and raises an event to your code.
Use a library that uses lower level hardware that polls at an embedded level.
Use a library, that uses hardware, that uses a chip that raises an interrupt as a result of the microprocessor 'polling' pins very quickly.
If your highest level design is agnostic of 'design' patterns, then it is done right.
It can be implemented successfully by any combination of language, or 'pattern'
|
|
|
|
|
Two things.
Why are you replying on a very old comment?
What relevance does polling have to do with the comment?
|
|
|
|
|
CPallini wrote: Do you use design patterns?
Yes, and I used Singleton to restrict the number of connections to the database. After getting benefit from this, now I'm looking for other patterns too, so, recently started studying design patterns -- though its not regular. But during study, noted that self studying design patterns is a bit challenging to understand.
How you covered (are covering) design patterns?
Regards.
________________________________
Success is not something to wait for, its something to work for.
|
|
|
|
|
uroojkhan wrote: How you covered (are covering) design patterns?
Like you I'm self studying design patterns (I've the book of Gamma, Helm, Johnson, Vlissides) and, like you, I find them quite challenging. I think that if you need one pattern in you project, then you'll have a chance to deeply understand it.
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
|
|
|
|
|
CPallini wrote: I've the book of Gamma, Helm, Johnson, Vlissides
Thanks for the book (Design Patterns: Elements of Reusable Object-Oriented Software) reference.
CPallini wrote: I think that if you need one pattern in you project, then you'll have a chance to deeply understand it.
True. But before using patterns we must have know how about it.
Thanks and Regards
________________________________
Success is not something to wait for, its something to work for.
|
|
|
|
|
uroojkhan wrote: But before using patterns we must have know how about it.
True, of course. But the book we wrote about is of big help, because it first identifies and clarifies the problem the pattern addresses, then explains the details of the pattern itself.
Cheers
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
|
|
|
|
|
Hi,
uroojkhan wrote: Thanks for the book (Design Patterns: Elements of Reusable Object-Oriented Software) reference.
You mau refer this book from here & here.
regards,
Divyang Mithaiwala
Software Engineer
|
|
|
|
|
Many thanks for the valuable links. I'm still searching the book because its not available in the local market
Regards
________________________________
Success is not something to wait for, its something to work for.
|
|
|
|
|
Hi,
I was wondering if there are some guidelines regarding the following issue in the .NET framework:
Polling based design (the client polls the server every X interval for changes) Vs. Events driven design (the client registers to the event and the server will raise the event)?
i am not sure when to use each of the above...
|
|
|
|
|
There is an alternative: Observers. Polling requires significant effort to keep state in sync so that you can keep track of changes. Events are good, but do require that items subscribe to the events to keep track of them.
the last thing I want to see is some pasty-faced geek with skin so pale that it's almost translucent trying to bump parts with a partner - John Simmons / outlaw programmer
Deja View - the feeling that you've seen this post before.
|
|
|
|
|
In my experience, this depends greatly on the thing being interfaced with and the platform.
For example, some hardware devices support interrupts and can raise an interrupt when something happens, and then data can be read from the device. Some others do not support interrupts and need to be polled (rapidly) so that any data is not missed.
It may also depend on your platform. If targeting an battery-powered platform (or working with a battery operated device), polling can greatly reduce battery life over an interrupt-based approach.
For what you suggest above, I would have clients register with the server and have the server fire off events as required. This is less work all around in the long run - network traffic only exists when something is actually happening, and the server is not going to be chewing up CPU cycles by always answering "no" each time a client connects and asks "is anything available?".
Peace!
-=- James If you think it costs a lot to do it right, just wait until you find out how much it costs to do it wrong! Avoid driving a vehicle taller than you and remember that Professional Driver on Closed Course does not mean your Dumb Ass on a Public Road! DeleteFXPFiles & CheckFavorites (Please rate this post!)
|
|
|
|
|
Depends actually,
polling introduces a latency , which is equal to polling interval.
event's on other hand are instantaneous, so it depends whether a latency is accepted or not.
|
|
|
|
|
I just want to be the first to post a message on a new forum. Did I make it?
You may be right I may be crazy -- Billy Joel --
Within you lies the power for good, use it!!!
|
|
|
|
|
I saw this section morning I think on the codeproject we must wait for new changes
|
|
|
|
|
I hate these new forums. Everything shifts around.
Cheers,
Sebastian
--
Contra vim mortem non est medicamen in hortem.
|
|
|
|
|
Keeps your mind sharp!
|
|
|
|