I'm working on a winforms application that is very complicated, and has massive callback chains being passed around all over the place.
As an example loosely based on this code, there could be a "Manager" class, that spawns a class "SetUpWorkerThreads" class, which creates a "HandleWorker" thread for say 10 workers.
The worker thread needs to call back to the manager class on occasion, to achieve this the code looks like this:
public class Manager
{
public delegate void SomethingHappenedHandler();
private void Init()
{
var x = new SetUpWorkerThreads(SomethingHappened);
}
private void SomethingHappened()
{
// Handle something happened
}
}
public class SetUpWorkerThreads
{
private readonly Manager.SomethingHappenedHandler _somethingHappened;
public SetUpWorkerThreads(Manager.SomethingHappenedHandler somethingHappened)
{
_somethingHappened = somethingHappened;
}
public void SetupTheThreads()
{
// Contrived!
for (int x=0; x<10; x++)
{
var worker = new Worker(_somethingHappened);
new Thread(worker.DoingSomething).Start();
}
}
}
public class Worker
{
private readonly Manager.SomethingHappenedHandler _somethingHappened;
public Worker(Manager.SomethingHappenedHandler somethingHappened)
{
_somethingHappened = somethingHappened;
}
public void DoingSomething()
{
// ... Do Something
_somethingHappened();
}
}
In reality, there can be many more classes involved, each passing around a mass of callbacks for various things. I realise that poor class/application design is playing a part in this, but are there better ways to go about handling these interactions between classes, specifically in winforms apps, and when a lot of threading is going on?
I can't see that the threading makes it more or less problematic.
One alternative is to use events instead of callbacks, but that won't break up the long chains and will give you an unsubscribing hell too.
One possible approach is to create an object responsible for handling all the events. Either as a singleton or as a single object that you pass to all your threads (instead of the callbacks). Then you can have a simple interface on the EventRouter object to raise events from the threads. You can then subscribe to events on the EventRouter where you need to handle "something happened".
Edit
Something the GoF pattern Mediator but with a publisher-subscriber twist.
Related
Should the event subscriber always register the event handler, or is it ok for another class to do it?
Example:
class EventPublisher {
public event EventHandler Event;
}
class EventSubscriber {
public void Handler(object sender, EventArgs e) { }
}
class Glue {
private EventPublisher _publisher = new EventPublisher();
private EventSubscriber _subscriber = new EventSubscriber();
public Glue() {
_publisher.Event += _subscriber.Handler;
}
}
Should the event subscriber always register the event handler, or is
it ok for another class to do it?
There is nothing inherently wrong with this design per se, though it really depends on your architecture and how scaleable and decoupled you want it.
Just a note, there is no context with the generic hypothetical you have put forward with Glue so its hard to tell your exact requirements.
...
These days, i rarely write traditional events and tend to use a more modern approach of Pub/Sub Producer/Consumer Decoupled Messages or an Event Aggregator (depending on the frameworks you are using). Consumers can subscriber at will, and producers can publish at will without any prior knowledge of each other. Martin Follower goes into this pattern in more detail on his site.
More-so, the advantages with Decoupled Messages (and kin), is consumers can subscribe to a conversation without having any previous knowledge of who the producers are, which gives you better decoupling which in turn creates a more maintainable and scalable system. If the system becomes large enough, pushing classes to Microservices can be a lot less painful.
On saying that, if this is only a very simple implementation (and tightly coupled implementation) there is nothing wrong with standard vanilla ice-cream flavored .NET events and having your subscriber register the event handler, though once again you have to break this down into the most logical concern for your design.
I.e should a SoundManager inherently know about a dog and its bark. Or should your dog class register to the sound manager. Your design intuition should lead the way
Anyway, good luck.
Programmatic, it is not wrong and will work smooth for you.
In fact you need to do this in the case where in EventSubscriber of which method
(Handler)should be called on Event , doesn't have object of EventPublisher class.
How to subscribe events is subjective matter, it depends on your over all flow and comfort.
But According to me, subscribing event in side of subscriber class make code more readable and easy to understand
you see to subscribe an event of any class, subscriber class must have an object of that class, but here in your example it doesn't have.
Generally people design architecture in such method when subscriber class itself hold the object of publisher class. This design has its own benefits in some flow, see below example,
public class EventPublisher
{
public event EventHandler HeavyLogicDone;
public void ExposedMethod(string subScriberSpecificData)
{
Thread logicCaller = new Thread(() => HeavyLogic(subScriberSpecificData));
logicCaller.Start();
}
private void HeavyLogic(string subScriberSpecificData)
{
//logic which may take time
if (HeavyLogicDone != null)
HeavyLogicDone(this, new EventArgsClass(subScriberSpecificData));
}
}
here EventPublisher class has a publicly exposed functionality, which should be called by EventSubscriber , but as this method may take time, it is being written in thread.
Now problem, as it is in thread, call of this method will return soon after starting the thread, subscriber can not start its functionality which is dependent on this method's result, it must wait. So to notify subscriber that task has been done, there is an event.
public class EventSubscriber
{
string currentData = "";
public EventSubscriber(EventPublisher eventPublisher, string data)
{
currentData = data;
eventPublisher.HeavyLogicDone += eventPublisher_HeavyLogicDone;
eventPublisher.ExposedMethod(currentData);
//Contineous without waiting for heavy logic to compelete
}
void eventPublisher_HeavyLogicDone(object sender, EventArgs e)
{
if(((EventArgsData)e).subScriberSpecificData == currentData)
{
//Do further task which is dependant to result of logic
//if now subscriber doesn't need to listen this event anymore
((EventPublisher)sender).HeavyLogicDone -= eventPublisher_HeavyLogicDone;
}
}
}
As you can seen when to subscribe an event and when to unsubscribe it, subscriber has all control now.
But, if you would be doing like this.
static void Main(string[] args)
{
EventSubscriber subscriber1 = new EventSubscriber("sub1");
EventSubscriber subscriber2 = new EventSubscriber("sub2");
EventPublisher pub = new EventPublisher();
pub.HeavyLogicDone += subscriber1.eventPublisher_HeavyLogicDone;
pub.HeavyLogicDone += subscriber2.eventPublisher_HeavyLogicDone;
pub.ExposedMethod("sub1");
pub.ExposedMethod("sub2");
}
First problem : As you can see, every time you are creating an instance of Subscriber, you have to explicitly write it's subscription and calling of publisher's method for current subscriber. that is coupled code, and you need to keep doing this every time.
and subscriber class
public class EventSubscriber
{
string currentData = "";
public EventSubscriber(string data)
{
currentData = data;
}
public void eventPublisher_HeavyLogicDone(object sender, EventArgs e)
{
if(((EventArgsData)e).subScriberSpecificData == currentData)
{
//Do further task which is dependant to result of logic
//if now subscriber doesn't need to listen this event anymore
((EventPublisher)sender).HeavyLogicDone -= eventPublisher_HeavyLogicDone;
}
}
}
Second problem : as subscription is not in control of subscriber class, and unsubscribing can be done only withing subscriber class. Code will be little mess to understand.
Use case
I'm developing a small application in C# that is called by another application to retrieve data from the Internet. It runs as a process on its own, but almost all of the interaction with it, is managed by the calling application. Therefor it does not have a GUI. However I'd like to add a progress bar using WPF that is shown during certain data retrievals that could take up to a minute. It's fairly easy to make an estimate of how much work is done and how much is left and therefor I find a progress bar suitable.
Research done
I have a fair understanding of threading after reading large parts of Albahari's pdf on threading (http://www.albahari.info/threading/threading.pdf). I have also read through a lot of posts on SO and MSDN in this matter. Most posts suggest the use of a background worker for the time consuming data retrieval while keeping the GUI in the main thread and therefor suggest solutions using a background worker. That feels awkward in this scenario though, where the main task is data retrieval and not GUI interaction.
I've spend a bunch of hours trying to make sense of different tutorials and forum posts while trying to conform them to my problem, but I have not succeeded and now I'm pretty much back to square one. Basically I'd like to end up with the following two classes outlined below:
ProgressBarWindow
public partial class ProgressBarWindow : Window
{
public ProgressBarWindow()
{
InitializeComponent();
}
public void setValue(int value)
{
// This function should be available from the main thread
}
}
Querier
Public class Querier
{
public List<Item> getItems()
{
// call ProgressBarWindow.setValue(0);
...
// call ProgressBarWindow.setValue(100);
// call ProgressBarWindow.Close();
}
}
It's my understanding that UI must run under single threads and therefor my ProgressBarWindow object could not be instantiated in a new thread while at the same time be available to the main thread (kind of).
Dispatcher.BeginInvoke appears to be my savior here but so far I haven't been able to figure out what should go into the Querier class and what to go in the ProgressBarWindow class. How can I make the two threads interact with the same instance of ProgressBarWindow?
Please ask if you need more details and I will try to clarify.
You can use the Progress class to update the UI with the current progress of a long running operation.
First create an instance of Progress in your UI:
Progress<int> progress = new Progress<int>(currentProgress =>
{
progressBar.Value = currentProgress;
//todo do other stuff
});
Then pass it to the long running process:
public List<Item> getItems(IProgress<int> progress)
{
progress.Report(0);
//todo do something
progress.Report(100);
}
Here is a generic function which i generally use:
public static void Invoke(this UIElement element,Action action)
{
element.Dispatcher.Invoke(action, null);
}
And to use it, simply call:
this.Invoke(() => ProgressBarWindow.SetValue(0));
So, in the getItems() function, you would have something along the lines of:
public List<Item> getItems()
{
ProgressBarWindow wnd;
MainWindow.Invoke(() => wnd = new ProgressBarWindow())
MainWindow.Invoke(() => wnd.SetValue(0))
...
MainWindow.Invoke(() => wnd.SetValue(100))
MainWindow.Invoke(() => wnd.Close())
}
Make sure you always have a way to get to the main window is anything (the one running from either App.xml, or App.Run(...). You can then issue any GUI actions through it (even if you have to create a new Loader window for example, as long as it's done within the main thread)
App.xaml
public partial class App : Application
{
private void Application_Startup_1(object sender, StartupEventArgs e)
{
Task.Factory.StartNew<List<int>>(() => Querier.GetItems());
}
}
ProgressBarWindow.xaml.cs
public partial class ProgressWindow : Window
{
public ProgressWindow()
{
InitializeComponent();
Querier.Start +=()=> Visibility = Visibility.Visible;
Querier.Stop += () => Visibility = Visibility.Collapsed;
Querier.ReportProgress +=OnReportProgress;
}
public void OnReportProgress(int value)
{
txtBox.Text = value.ToString();
}
}
ProgressBarWindow.xaml
<Grid>
<TextBox x:Name="txtBox"></TextBox>
</Grid>
Querier
public class Querier
{
public static event Action Start;
public static event Action Stop;
public static event Action<int> ReportProgress;
public static List<int> GetItems()
{
if (Start != null)
App.Current.Dispatcher.BeginInvoke(Start,null);
for (int index = 0; index <= 10; index++)
{
Thread.Sleep(200);
if (ReportProgress != null)
App.Current.Dispatcher.BeginInvoke(ReportProgress, index*10);
}
if (Stop != null)
App.Current.Dispatcher.BeginInvoke(Stop, null);
return Enumerable.Range(1, 100).ToList();
}
}
I am just trying to give an idea hope this will help.
Consider this code:
class GameEventsManager
{
public void StartGameEvent(GameEvent TheGameEvent)
{
SubscribeToGameEvent(TheGameEvent);
TheGameEvent.Begin();
UnsubscribeToGameEvent(TheGameEvent);
}
private void SubscribeToGameEvent(GameEvent TheGameEvent)
{
TheGameEvent.OnPlaySound += OnPlaySound;
TheGameEvent.OnShowWrittenItem += OnShowWrittenItem;
...
}
private void UnsubscribeToGameEvent(GameEvent TheGameEvent)
{
TheGameEvent.OnPlaySound -= OnPlaySound;
TheGameEvent.OnShowWrittenItem -= OnShowWrittenItem;
...
}
}
A GameEvent is a class that basically does this: when Begin() gets called, it raises events that get passed to the GameEventManager, so that it may "make" the appropriate changes to the game environment (this is by further propagating the events to the objects that are responsible for executing each particular instruction, like in the Observer pattern).
Now take into consideration that all of my InventoryItems (can trigger events, such as OnConsume, OnUse) are static fields in their particular classes. Although this may seem a bit rough around the edges, I feel that being able to do:
AddItem(WrittenItems.NoteFromKing) //NoteFromKing is a static field in WrittenItems
makes things a lot simpler, and it's a welcome sight considering I'm working on a quite complex game.
This, however, makes it very hard for me to list ALL of the game's items somewhere, in case this would be needed. Which brings us to my question:
A LevelManager, that manages things such as when the player interacts with a particular item in the level, tells the GameEventsManager to run a particular GameEvent, if required. The GameEventsManager then subscribes to the GameEvent, starts it, and then unsubscribes. Should I expect to see noticeable performance issues while following this subscribe/run/unsubscribe pattern? In the end, the manager might subscribe/unsubscribe to about 20 events inside GameEvent.
In case the subscribe/unsubscribe mechanism is slow, I could make a single subscribe process that runs at game initialization, but that would force me to build an extra structure, to list all of the items.
So, in short, I'd like to know if I should be expecting considerable slowdowns from this kind of implementation. Or more exactly, if subscribing to about 20 events, and then unsubscribing from them is considerably slow.
Language is C#, using .NET 2.0 subset under Unity 4.
This, however, makes it very hard for me to list ALL of the game's items somewhere
Why so? You could create an ItemManager (which is a singleton):
public class ItemManager
{
private static volatile ItemManager _instance;
private static object syncRoot = new Object();
private ObservableCollection<ItemBase> _registeredItems = new ObservableCollection<ItemBase>();
private ItemManager()
{
}
public ItemManager Instance
{
get
{
if (instance == null)
{
lock (syncRoot)
{
if (instance == null)
instance = new ItemManager();
}
}
return instance;
}
}
public void RegisterItem(ItemBase item)
{
_registeredItems.Add(item);
// Do some stuff here, subscribe events, etc.
}
public void UnregisterItem(item)
{
// Do some stuff here, unregister events, etc.
_registeredItems.Remove(item)
}
}
Afterwards you make all item classes derive from a class called "ItemBase". And in ItemBases Constructor you call this:
ItemManager.Instance.RegisterItem(this);
So you don't have to add every single item manually. For more information about the singleton pattern, take a look here: http://msdn.microsoft.com/en-us/library/ff650316.aspx.
A little benefit of this is also, that you can implement a general communication between the GameManager and the ItemManager.
I am just wondering about problems involved passing a parent to child, should it be done etc, so that a child can access functionality from the parent, in this case it involves threads. My scenario follows:
public class A
{
public A()
{
B b = new B(this);
Thread thread = new Thread(new ThreadStart(b.GO));
}
public string DoSomething() { return "Something Done"; }
}
public class B
{
A _a;
public B(A a)
{
_a = a;
}
public void GO() { _a.DoSomething(); }
}
Based on above I'm wondering about any convention clashes the occur, or problems that come into effect when you do something like this, is it bad to do this? I know that there definitely brings up some thread safety issues. But my overall question is ok to do this, does it bring up some other issues? How would I update values in the main thread?
The reason why I want it separate is because class B has a timer in it(not in shown code) that when it runs out does somethings, then tells class A that it has finished, resets the timer and goes back to sleep until the timer runs out again, how would I do that otherwise?
~Regards,
Heinrich
Looking at the code, you don't appear to have any threading issues. You might introduce a race condition if you are working on the same variables, but that isn't special to the situation you propose.
You would treat this like any other multi-threaded situation and lock resources that might be accessed by multiple threads.
I would recommend the following online book: http://www.albahari.com/threading/
I don't think you really have to connect them as tightly as you are, what you are trying to do is simply pass messages or states between threads. So the reason I would recommend not having them so tightly connected is to reduce coupling.
The website I referenced contains many different signaling techniques. Pick the simplest for your needs. I would need more details about your exact requirements to pick one for you.
Another way to handle what you are doing is for B to raise an event and for A to handle the event. That way you don't have to pass A into B. I don't know what your real structure is, but lets say that B's thread function does something more complicated and A implements IDisposable. What happens if A is disposed before B gets to the point that it is calling a method on A. To me the cleaner way to handle that situation is to have B raise an event and A register for it.
public class A
{
B _b;
public A()
{
_b = new B();
_b.DidSomething += HandleDidSomething;
}
private void HandleDidSomething(object source, EventArgs e)
{
// Handle the B did something case
}
public void WaitForBToFinish() { _b.DoneDoingThings.WaitOne(); }
}
public class B
{
Event EventHandler DidSomething;
ManualResetEvent DoneDoingThings = new ManualResetEvent(false);
public B() {}
public void StartDoingThings()
{
new Thread(DoThings).Start();
}
private void DoThings()
{
for (int i=0; i < 10; i++)
{
Thread.Sleep(1000);
OnDidSomething(new EventArgs());
}
DoneDoingThings.Set();
}
private void OnDidSomething(EventArgs e)
{
if (DidSomething != null)
{
DidSomething(e);
}
}
}
Note - You should implement IDisposable in class B and dispose of the ManualResetEvent, I just am too lazy to do all that for sample code, and just wanted to give you an idea about using events to signal work was done.
I have a class that is a "manager" sort of class. One of it's functions is to signal that the long running process of the class should shut down. It does this by setting a boolean called "IsStopping" in class.
public class Foo
{
bool isStoping
void DoWork() {
while (!isStopping)
{
// do work...
}
}
}
Now, DoWork() was a gigantic function, and I decided to refactor it out and as part of the process broke some of it into other classes. The problem is, Some of these classes also have long running functions that need to check if isStopping is true.
public class Foo
{
bool isStoping
void DoWork() {
while (!isStopping)
{
MoreWork mw = new MoreWork()
mw.DoMoreWork() // possibly long running
// do work...
}
}
}
What are my options here?
I have considered passing isStopping by reference, which I don't really like because it requires there to be an outside object. I would prefer to make the additional classes as stand alone and dependancy free as possible.
I have also considered making isStopping a property, and then then having it call an event that the inner classes could be subscribed to, but this seems overly complex.
Another option was to create a "Process Cancelation Token" class, similar to what .net 4 Tasks use, then that token be passed to those classes.
How have you handled this situation?
EDIT:
Also consider that MoreWork might have a EvenMoreWork object that it instantiates and calls a potentially long running method on... and so on. I guess what i'm looking for is a way to be able to signal an arbitrary number of objects down a call tree to tell them to stop what they're doing and clean up and return.
EDIT2:
Thanks for the responses so far. Seems like there's no real consensus on methods to use, and everyone has a different opinion. Seems like this should be a design pattern...
You can go two ways here:
1) The solution you've already outlined: pass a signaling mechanism to your subordinate objects: a bool (by ref), the parent object itself cloaked in an interface (Foo: IController in the example below), or something else. The child objects check the signal as needed.
// Either in the MoreWork constructor
public MoreWork(IController controller) {
this.controller = controller;
}
// Or in DoMoreWork, depending on your preferences
public void DoMoreWork(IController controller) {
do {
// More work here
} while (!controller.IsStopping);
}
2) Turn it around and use the observer pattern - which will let you decouple your subordinate objects from the parent. If I were doing it by hand (instead of using events), I'd modify my subordinate classes to implement an IStoppable interface, and make my manager class tell them when to stop:
public interface IStoppable {
void Stop();
}
public class MoreWork: IStoppable {
bool isStopping = false;
public void Stop() { isStopping = true; }
public void DoMoreWork() {
do {
// More work here
} while (!isStopping);
}
}
Foo maintains a list of its stoppables and in its own stop method, stops them all:
public void Stop() {
this.isStopping = true;
foreach(IStoppable stoppable in stoppables) {
stoppable.Stop();
}
}
I think firing an event that your subclasses subscribe to makes sense.
You could create a Cancel() method on your manager class, and on each of your other worker classes. Base it on an interface.
The manager class, or classes that instantiate other worker classes, would have to propagate the Cancel() call to the objects they are composed of.
The deepest nested classes would then just set an internal _isStopping bool to false and your long-running tasks would check for that.
Alternatively, you could maybe create a context of some sort that all the classes know about and where they can check for a canceled flag.
Another option was to create a
"Process Cancelation Token" class,
similar to what .net 4 Tasks use, then
that token be passed to those classes.
I am not familiar with this, but if it is basically an object with a bool property flag, and that you pass into each class, then this seems like the cleanest way to me. Then you could make an abstract base class that has a constructor that takes this in and sets it to a private member variable. Then your process loops can just check that for cancellation.
Obviously you will have to keep a reference to this object you have passed into your workers so that it's bool flag can be set on it from your UI.
Your nested types could accept a delegate (or expose an event) to check for a cancel condition. Your manager then supplies a delegate to the nested types that checks its own "shouldStop" boolean. This way, the only dependency is of the ManagerType on the NestedType, which you already had anyway.
class NestedType
{
// note: the argument of Predicate<T> is not used,
// you could create a new delegate type that accepts no arguments
// and returns T
public Predicate<bool> ShouldStop = delegate() { return false; };
public void DoWork()
{
while (!this.ShouldStop(false))
{
// do work here
}
}
}
class ManagerType
{
private bool shouldStop = false;
private bool checkShouldStop(bool ignored)
{
return shouldStop;
}
public void ManageStuff()
{
NestedType nestedType = new NestedType();
nestedType.ShouldStop = checkShouldStop;
nestedType.DoWork();
}
}
You could abstract this behavior into an interface if you really wanted to.
interface IStoppable
{
Predicate<bool> ShouldStop;
}
Also, rather than just check a boolean, you could have the "stop" mechanism be throwing an exception. In the manager's checkShouldStop method, it could simply throw an OperationCanceledException:
class NestedType
{
public MethodInvoker Stop = delegate() { };
public void DoWork()
{
while (true)
{
Stop();
// do work here
}
}
}
class ManagerType
{
private bool shouldStop = false;
private void checkShouldStop()
{
if (this.shouldStop) { throw new OperationCanceledException(); }
}
public void ManageStuff()
{
NestedType nestedType = new NestedType();
nestedType.Stop = checkShouldStop;
nestedType.DoWork();
}
}
I've used this technique before and find it very effective.
Litter your code with statements like this wherever it is most sensible to check the stop flag:
if(isStopping) { throw new OperationCanceledException(); }
Catch OperationCanceledException right at the top level.
There is no real performance penalty for this because (a) it won't happen very often, and (b) when it does happen, it only happens once.
This method also works well in conjunction with a WinForms BackgroundWorker component. The worker will automatically catch a thrown exception in the worker thread and marshal it back to the UI thread. You just have to check the type of the e.Error property, e.g.:
private void worker_RunWorkerCompleted(object sender, RunWorkerCompletedEventArgs e) {
if(e.Error == null) {
// Finished
} else if(e.Error is OperationCanceledException) {
// Cancelled
} else {
// Genuine error - maybe display some UI?
}
}
You can flatten your call stack by turning each DoWork() call into a command using the Command pattern. At the top level, you maintain a queue of commands to perform (or a stack, depending on how your commands interact with each other). "Calling" a function is translated to enqueuing a new command onto the queue. Then, between processing each command, you can check whether or not to cancel. Like:
void DoWork() {
var commands = new Queue<ICommand>();
commands.Enqueue(new MoreWorkCommand());
while (!isStopping && !commands.IsEmpty)
{
commands.Deque().Perform(commands);
}
}
public class MoreWorkCommand : ICommand {
public void Perform(Queue<ICommand> commands) {
commands.Enqueue(new DoMoreWorkCommand());
}
}
Basically, by turning the low-level callstack into a data structure you control, you have the ability to check stuff between each "call", pause, resume, cancel, etc..