|
God Bless u Mark Churchill.
U are damn right and u have just saved someone from a burning station! Thanks a lot and more thanks for the information shared.
Now, to have my major worry settled, I just need to know how to connect to the POS machine in the fuel pump from a C# application and get the litre or cash values so that I can at least, record the sales of fuel for a prepay scenario. I have heard of WEPOS and POS for .NET but I don't know if that will do. I will appreciate any assistance or walk around rendered.
Just to add, secondly(minorly), I've observed something during prepay sale which i want to bring to your notice. While fuel is pumped into the vehicle, if the user holds down the inner holder of the hose nozzle at intervals, the volume of fuel released after pump or sold will be reduced! Suprisingly, I've confirmed this with sale measurements to fuel galloons. Perhaps, nozzle manufacturers might be able to build hose nozzle models that can't interrupt the volume to be dispensed. What do you think?
Anyway, thats by the way, my concern right now is how to solve my major worry as stated above. Many more thanks in advance as I look forward to hearing from soon.
|
|
|
|
|
Hi Guys,
I've been working on a system for a while now, and it initially started off with a handful of functions that could be applied to it. This increased over time to around, and i split them up and put related functions into appropriate classes. These classes are now exhibiting the same problem i had initially with 100 methods in the same class. (Messy and poor cohesion)
* I Have a set of low level classes that expose all the fine grain detail.
* I have a set of high level classes that contain complex functions that manipulate the low level classes.
* The high level functions are largely simple [void Function()]. Some with a few Private utility methods.
* The high level functions generally do not call one another in the same class.
* The high level functions DO call one another in different classes.
* All High level function calls are made through a HUGE case statement atm, that is wrapped in a Logging exception handler.
Many of these functions are invoked from Menu or Hotkeys or other argument free events such as Button press.
I get the impression that this lends itself to a Command Pattern, but while i understand the concept, i can't get my head around how to implement it. (Factory? Pre-loaded Command Dictionary?)
Also, how would i go about implementing a Command Tree? i.e. where one command calls another, and so on and so forth? And would this be a reasonable thing to do?
Any Ideas?
Cheers
Tris
-------------------------------
Carrier Bags - 21st Century Tumbleweed.
modified on Friday, May 16, 2008 11:35 AM
|
|
|
|
|
Tristan Rhodes wrote: Also, how would i go about implementing a Command Tree? i.e. where one command calls another, and so on and so forth? And would this be a reasonable thing to do?
From my memory I think I used Observable Pattern rather than a tree. It is also possible factories were involved.
led mike
|
|
|
|
|
Hi Mike,
Thanks for the reply.
I do have a number of observable components in the application and their events are handled in a centralized controller class. This class then runs the appropriate command / functionality.
(Yes i do have a factory in there as well somewhere, but it's not related to the Command chain )
My concern is what to do to manage this large collection of functions and what options are available. Does the Command Pattern seem to be the way to go with this?
While i am familiar with the pattern, i'm somewhat perplexed as to how to fit it into the application. I'm not interested in commands for the purpose of Undo / Redo which is the only implementation i am familiar with.
Any further advice?
Cheers
Tris
-------------------------------
Carrier Bags - 21st Century Tumbleweed.
|
|
|
|
|
Tristan Rhodes wrote: I'm not interested in commands for the purpose of Undo / Redo which is the only implementation i am familiar with.
Not sure how to help you here. The implementation of a specific command like Undo/Redo have nothing to do with the Command Pattern. Probably the most significant benefit of the pattern is the isolation of the implementation of the commands from the implementation of the invokers. If that would be helpful to your project then you should consider using it, however:
Tristan Rhodes wrote: I do have a number of observable components in the application and their events are handled in a centralized controller class. This class then runs the appropriate command / functionality.
That sounds like you have already centralized the implementation of your commands. Sometime interpreting design from someone else's point of view presented in text messages is not easy.
led mike
|
|
|
|
|
Need a UML comment type.
-------------------------------
Carrier Bags - 21st Century Tumbleweed.
|
|
|
|
|
I did experiment with Commands a while back, but found myself doing lots of this:
ICommandExecutor cmd;
switch (cmdName)
{
case "DeleteCurrentSite":
cmd = new DeleteCurrentSiteCmd(container);
case "AddNewSite":
cmd = new AddSiteCmd(container);
}
cmd.Execute();
Which didn't solve the problem of my Mammoth case statement, nor did it provide a convenient solution for the Commands calling Commands problem. It felt like i was going in the right direction, but i got lost and had to backtrack.
Does that seem reasonable?
Cheers
Tris
-------------------------------
Carrier Bags - 21st Century Tumbleweed.
|
|
|
|
|
Tristan Rhodes wrote: Does that seem reasonable?
using a switch statement? Almost never. Commands should be stored in a Map or Dictionary.
led mike
|
|
|
|
|
Bingo!
Thankyou, that's exactly what i've been angling for.
So, something like:
public ICommandExecutor GetCommand(string name)
{
if (_cmdDictionary.ContainsKey(name) == false)
_cmdDictionary.Add(name, _commandFactory.GetCommand(name));
return _cmdDictionary[name];
}
What would you have to do to handle commands which have parameters? Or would that be a symptom of bad design?
Cheers!
Tris
-------------------------------
Carrier Bags - 21st Century Tumbleweed.
|
|
|
|
|
Tristan Rhodes wrote: What would you have to do to handle commands which have parameters? Or would that be a symptom of bad design?
Have a class for arguments that is a parameter to the Execute method
ICommandExecutor::Execute( CommandArgs& args)
led mike
|
|
|
|
|
Hi Everyone,
I am working with corel draw. I want to change some settings while opening the Corel Draw(Means I want to disable some tool bars and command bars).I think it is posiible in OnLoad Event.
Where can i found that Onload Event for Corel Draw. If any one have any idea on this. Please help me.
~ Raja Baireddy
|
|
|
|
|
Hi, Everyone.
Can someone describe me what is the "stateless server"?
My thoughts (I still want to get an explanation about the term above):
I asked google[^].
The best definition I found is "A stateless server considers each page request independently".
So, I think, the main accent is that the stateless server doesn't do any differences between users' requests. It thinks like every request is a new, from a new user.
Let's imagine a google search server that only search functionality, a very-very simple search functionality: just go to an "indexed sites DB" for results.
Is that one a stateless? I think -- yes.
Because it doesn't bother itself with questions: "Is that user a new, what he did last time,...". It just parses the request, goes to the DB and answers. It uses no information about last requests, so "considers each page request independently".
Am I right?
Thanks, Aikin
|
|
|
|
|
AikinX wrote: Am I right?
Your statements are to specific.
Stateless[^]
In computer science, stateless refers to a system or protocol which does not keep a persistent state between transactions.
led mike
|
|
|
|
|
Yes, I saw this definition, but it told me nothing else
|
|
|
|
|
AikinX wrote: but it told me nothing else
There is nothing else to your question. Each server is different but Stateless means Stateless, period.
led mike
|
|
|
|
|
I re-read the definition and found that this one is a definition for stateless, not for stateless server. I didn't saw that before. It is a very useful one. Thanks.
But I don't think it is fully related to a "stateless server", because the one doesn't have it's own "persistent state". A server is a container for applications that are ran into the one. So It can only provide underlying applications with a more usable request to clients.
Yes, it can store some information, but not for itself -- for it's applications.
So, I think is better to use it's own definition: a stateless server[^]
A stateless server is a server that treats each request as an independent transaction that is unrelated to any previous request.
Although this definition is very useful to understand next ones: a stateless application, a stateless session, ...
Thanks again, led mike.
|
|
|
|
|
AikinX wrote: But I don't think it is fully related to a "stateless server"
It is definitely fully related. In the context of "a server" the definition of "stateless" does NOT change.
AikinX wrote: A server is a container for applications that are ran into the one.
No. It can be but the word "server" is not limited to that. In client-server architecture "server" refers to the process that services the clients. However there is a non client-server architecture use of a server process that may not service clients at all. It may not receive requests of any kind.
led mike
|
|
|
|
|
Stop, I've just realized. The Google seacher is not a server. It is an application running into the server
No, more questions, thanks.
|
|
|
|
|
In a helper class, I have a dictionary (object, target), where target can be created in a very few different ways, e.g. a delegate, a type or a specific object.
Specifying a System.Type for target will be the most common option, but the caller should be able to use a custom delegate as well.
One way to implement this is an abstract base:
class TargetBase
{
abstract object Convert(object o);
};
public class TypeAdapter
{
Dictionary<object, TargetBase> dict;
public void Add(Type source, Type target) { dict.Add(source, new TypeTarget(target); }
public void Add(Type source, MyDelegate target) { dict.Add(source, new DelegateTarget(target); }
object Map(object o) { return dict[o.GetType()].Convert(o); }
};
(I've omitted the Typetarget, DelegateTarget implementations for brevity)
Alternatively, since a delegate is in there anyway, I could use the delegate for the other options:
public class TypeAdapter
{
Dictionary<object, MyDelegate> dict;
public void Add(Type source, MyDelegate target) { dict.Add(source, new DelegateTarget(target); }
public void Add(Type source, Type target)
{
dict.Add(source, delegate(object o) { Activator.CreateInstance(target, o); }
}
object Map(object o) { return dict[o.GetType()](o); }
};
The current implementation uses struct containing either a delegate or a type, and acts depending on which one is not null. This is IMO quite ok, since there is only a minor chance of a 3rd option, and I can't conceive more.
I'd like to get some feedback which way you would go, and why. Topics I see are readability/maintainability and performance*
*) I claim "not a premature optimization" here, since it's intended as a library component I don't know how it will be used, and I have no feeling for the performance/overhead of virtual calls vs. delegates.
We are a big screwed up dysfunctional psychotic happy family - some more screwed up, others more happy, but everybody's psychotic joint venture definition of CP blog: TDD - the Aha! | Linkify!| FoldWithUs! | sighist
|
|
|
|
|
peterchen wrote: In a helper class
I see this "helper class" statement being used a lot recently. At first I wonder, did I skipped the chapter in Design Patterns[^] that discusses the Helper Class Pattern? Then I remember that I'm seeing it here on code project and realize that it is more likely a result of poor design.
If I am wrong help me pleeeezzz, it's urgent
led mike
|
|
|
|
|
Maybe it's not a very good label, would "utility class" be a better one?
I put everything under that label that is not explicitely domain-specific, i.e. doesn't have a roöe specific for the actual project at hand. Nonetheless, it has a very distinct role.
We could also call it "glue and plaster". The idea I am following might be in very thin air[^], I will see.
Maybe I should just have written "In a class"
We are a big screwed up dysfunctional psychotic happy family - some more screwed up, others more happy, but everybody's psychotic joint venture definition of CP blog: TDD - the Aha! | Linkify!| FoldWithUs! | sighist
|
|
|
|
|
peterchen wrote: Maybe it's not a very good label, would "utility class" be a better one?
No. Unless I also skipped the Utility Class Pattern chapter in Design Patterns as well. Keep in mind I don't really care what all you guys do in your projects, but when you post a question in the "Design" forum it seems appropriate to mention that you may not be following the principles of Object Oriented Design and the use of Design Patterns.
peterchen wrote: The idea I am following might be in very thin air[^], I will see.
When you go too far up, abstraction-wise, you run out of oxygen.
That doesn't seem to match what you posted because what you posted sounds like it fits a Creational Pattern[^]
led mike
|
|
|
|
|
phuket, CP ate my reply
led mike wrote: Unless I also skipped the Utility Class Pattern chapter in Design Patterns as well
Are you sure you are not mixing up "Design Patterns" with "Compendium of past, current and future entity classification systems"? They like, have the same cover color and stuff
I'm not looking for a creator as such - I don't have a clear picture yet myself, so I tried to avoid the underlying problem.
If you require the same interface from diverse types, you will have some that implement (i.e. know) the interface, and others for which you need a proxy (adapter? surrogate? your call! ). What I am throwing some brain cycles at is a kind of as operator where you can register a surrogate for certain types.
A similar pattern is used in serialization, where you can register surrogates for certain types that need specific handling.
Another thing (the one I'm actually coming from) is MVC for "aggregate" views (like lists, trees, grids etc.) Here, the surrogate could acts as a "node controller" for diverse data node classes.
I'm not yet sure if this makes sense, but also that was not my question
We are a big screwed up dysfunctional psychotic happy family - some more screwed up, others more happy, but everybody's psychotic joint venture definition of CP blog: TDD - the Aha! | Linkify!| FoldWithUs! | sighist
|
|
|
|
|
Yeah, I see someone liked your reply enough to vote it a 5. All that stuff you said is great but where in surrogates and aggregate views and interfaces and all those nice buzz words you used is a "Helper" class? I don't think so.
led mike
|
|
|
|
|
I showed you my definition of a "Helper class" (everything outside being domain specifc), now show me yours!
We are a big screwed up dysfunctional psychotic happy family - some more screwed up, others more happy, but everybody's psychotic joint venture definition of CP blog: TDD - the Aha! | Linkify!| FoldWithUs! | sighist
|
|
|
|
|