Develop Reference

C# Call function from another class

I think my question is best descirbed by a code snippet:
class A
{
public void FunctionToBeCalled();
}
class B
{
public void FunctionToBeCalledAfter();
}
Now, after a FunctionToBeCalledAfter() call, FunctionToBeCalled() needs to "know" it must be called. B cannot have an A member, but A can have a B member. Is there any way this can be implemented in C#?
Why i need this:
Class A is Application level on OSI stack. Classes B and C(unmentioned before) are Transport Level. C makes calls to FunctionToBeCalledAfter, and after this FunctionToBeCalled needs to be called. But sincer A is a higher level, B and C cannot depend(have a member A), i don't know how to call FunctionToBeCalled.

I see 2 ways to accomplish this, one easier but (arguably) less elegant, one a little more involved but (arguably) more elegant
The less elegant solution: Singleton
A Singleton pattern enforces that there can only ever be one instance of a class at any given time, this seems to line up with your description of A (which from here on out I'll call Foo, and I'll be calling B Bar). So let's implement it:
public class Foo
{
private static Foo _instance;
public static Foo Instance => _instance ?? (_instance = new Foo());
// Private constructor so no one else can instantiate Foo
private Foo() { }
public void FunctionToBeCalled() { /* your code here */ }
}
public class Bar
{
public void FunctionToBeCalledAfter()
{
// Your existing code here
Foo.Instance.FunctionToBeCalled();
}
}
Now, the problem here is if your requirements ever change and you need multiple Foos, that'll be quite a refactor to implement it. Another (larger) downside is that we explicitly reference (i.e depend on) Foo, which isn't great and a problem if Bar is inside a project/ library that cannot directly reference Foo. Luckily solution 2 fixes those problems:
The more elegant solution: Events
public class Foo
{
// We don't need Foo to be a singleton anymore
public void FunctionToBeCalled() { /* Your code here */ }
}
public class Bar
{
public delegate void FunctionToBeCalledAfterEventHandler();
public event FunctionToBecalledAfterEventHandler FunctionToBeCalledAfterEvent;
public void FunctionToBeCalledAfter()
{
// Your existing code here
OnFunctionToBeCalledAfterEvent(); // Fire the event
}
private void OnFunctionToBeCalledAfterEvent()
{
FunctionToBeCalledEvent?.Invoke();
}
}
Now, everywhere where you're creating an instance of Bar you need to have a reference to Foo and subscribe to the event like so:
// foo = instance of class Foo
var bar = new Bar();
// The compiler is smart enough to find out that 'FunctionToBeCalledAfterEvent'
// has the same signature as 'FunctionToBeCalledAfterEvent' and can call it directly
// If this just so happens to not be case, see second way to subscribe to events
bar.FunctionToBeCalledAfterEvent += foo.FunctionToBeCalled;
// Or
bar.FunctionToBeCalledAfterEvent += () => foo.FunctionToBeCalled();
Events are great

Class B can have an event that other parties can handle. At the end of B.FunctionToBeCalledAfter this event would be invoked. Anyone who registered for this event would then be notified. Usual boilerplate code involves one virtual method that invokes one event. It's the standard way of adding events. If there is no need for additional data in the event then EventArgs is used. If additional data is needed then you could replace EventArgs with EventArgs<YourData>, or as an alternative, introduce a class XxxArgs derived from EventArgs with this additional data.
Class B
{
public event EventHandler FinishedFunctionToBeCalledAfter;
protected virtual void OnFinishedFunctionToBeCalledAfter(EventArgs e)
{
EventHandler handler = FinishedFunctionToBeCalledAfter;
handler?.Invoke(this, e);
}
public void FunctionToBeCalledAfter()
{
...
OnFinishedFunctionToBeCalledAfter(EventArgs.Empty);
}
}
Now when class A gets a hold of an object of class B it would add its event handler to it:
class A
{
public void FunctionToBeCalled();
public void FinishedFunctionToBeCalledAfter(object source, EventArgs e);
public void IntroduceObject(B b)
{
b.FinishedFunctionToBeCalledAfter += FinishedFunctionToBeCalledAfter;
}
}
When this object b of class B should end its life class A must know about it so that it can remove its event handler:
b.FinishedFunctionToBeCalledAfter -= FinishedFunctionToBeCalledAfter;

passing a method as a constructor's parameter

While I was looking at some c# code I found a new class declaration which had passed a method as a constructor’s parameter.This is my first time I have seen something like this and it has no meaning for me .Although the whole application works fine I am still interested to know what is the main idea behind the scene.
var c = new List<TheClass>
{
new TheClass(TheMethod);
}
private void TheMethod()
{
//do somthing
}

I guess the TheClass constructor accepts an Action delegate:
public class TheClass
{
private readonly Action _action;
public TheClass(Action action)
{
_action = action;
}
}
This way TheClass can execute the provided action at a later time, and more than once.
For example:
public void DoAction()
{
_action();
}
You could also do:
var theClass = new TheClass(() => TheMethod());

There are many reasons that you might want to pass a method into the constructor of a class.
One of the most important is for so-called Dependency Injection, where want to inject a dependency into a class.
Suppose that a class needs to create an object. Normally, that class would do something like var item = new MyConcreteClass();.
However, that creates a strong dependency between the class creating the object and MyConcreteClass. This can make it harder to unit test or change implementations.
To circumvent this problem, you can do this:
Extract from MyConcreteClass an interface (say IMyInterface) which contains all the things you need to use from inside the class being written.
Pass to the class constructor a Func method which creates and returns a concrete class as IMyInterface.
Inside the class being written, call that Func to create the object rather than creating it directly using new.
The Func is therefore acting as a factory.
Code might look like this:
using System;
namespace Spacelabs.WcfDuplexDemo.Client
{
static class Program
{
static void Main()
{
var myClass = new MyClass(() => new MyConcreteClass());
myClass.DoSomething();
}
}
public interface IMyInterface
{
string MyMethod(int param);
}
public sealed class MyConcreteClass : IMyInterface
{
public string MyMethod(int param)
{
return param.ToString();
}
}
public sealed class MyClass
{
private readonly Func<IMyInterface> createMyInterface;
public MyClass(Func<IMyInterface> createMyInterface)
{
this.createMyInterface = createMyInterface;
}
public void DoSomething()
{
// Instead of var item = new MyConcreteClass(), we do the following:
var item = createMyInterface();
Console.WriteLine(item.MyMethod(12345));
}
}

The main idea is to defer execution of the method and control when it gets executed.
One use case for this is passing a method that creates and object so that the class controls when the object is created and it can control how many times it is created.

Are you unclear of why a method is being passed as an argument or specificly as an argument in a constructor?
CodeCaster already spoke short about Action delegates and if you're interested in storing methods in delegates like Action, I suggest you read up on Delegates here
I'd like to provide a short example of a class that contains an Action delegate: RelayCommand -> I've illustrated the use of this delegate with the MVVM pattern below:
class ViewModelDefault : INotifyPropertyChanged
{
public string TextProperty { get; set;}
public ICommand ButtonProperty
{
get {
RelayCommand relayCommand = new RelayCommand(ExecuteCommand);
return relayCommand;
}
}
private void ExecuteCommand()
{
HandlerClass handler = new HandlerClass();
handler.SaveTextInTextfile(TextboxProperty);
}
...
}
In the MVVM pattern, your main focus is to seperate data, logic and view, which is why using Delegate is perfect in this scenario.
You'd normally want to bind a property such as a string from the ViewModel to a View UI Element such as a TextBox.
Making use of delegates, allows you to bind a method (which would otherwise not be bindable to a UI element) through an Action property.
In the example above, the method ExecuteCommand is stored in an action field inside the RelayCommand object. This is bindable to a UI element, and will execute the method once it's requested.

Call Event Explicitly

Is that possible somehow to trigger an event which belongs another class in C#, such:
class foo
{
public delegate void myEvntHandler();
public event myEvntHandler onTesting;
.
.
.
}
class Main
{
public static void Main()
{
foo obj = new foo();
...
obj.onTesting.Invoke();
}
}
on this sample I mean: obj.onTesting.Invoke();

No you can't invoke it directly from another class. That's the point of events (Encapsulation).
You need a helper method
class foo
{
public delegate void myEvntHandler();
public event myEvntHandler onTesting;
public void RaiseEvent()
{
if(onTesting !=null)
onTesting ();
}
}
Then call RaiseEvent method instead
class Main
{
public static void Main()
{
foo obj = new foo();
...
obj.RaiseEvent();
}
}
If you need to invoke it the way you did, just remove the event keyword and use a delegate. Which doesn't prevent you form doing so.(I don't recommend it)

No. The whole purpose of events is to wrap a delegate while explicitly prohibiting all access to it other than adding/removing an event handler. The event keyword is there specifically to prevent any class other than the class that declares the event from invoking it.

Short answer: No.
Longer answer: under the hood there no such thing as an "event" unlike delegates which are real objects. event is just a convenience for two methods (to add and remove handlers) and a private hidden field of type myEvntHandler.
Logically it makes no sense to raise an event from outside the class: The whole point of an event is that it is raised by the class when the class detects some trigger.
If you just want it to raise an event in order to test another class that has added a handler then the correct way to go is to:
move the event to an interface
implement the interface in your real class
create a test class that also implements the interface and add your "RaiseEvent" method to that.
Inject the interface into your unit under test

Action<T> equivalent for properties

I have a class that instantiates two classes which implement interfaces. I want one class to notify another class that something is OK. I could do it with an Action and then use private variables in the class but wondered if there was a direct way of doing it with properties so that when a property's value changes it updates a property on another class.
For example:
public class MyClass
{
public ILogger Logger {get;set;}
public ILogic Logic {get;set;}
private Form MyWinform;
public void Setup()
{
MyWinform = new MyWinform();
MyWinform.StartBatch += Logger.CreateFile; //Create file when user presses start
//How can I set a property on ILogic to be AllOk once ILogger says so??
//I could use an Action so that once all is ok I call IDecidedAlOK in ILogger which
//can then assign a private bool variable inside the class
Logic.ItsOKMethodSoSetVariableToTrue = Logger.IDecidedAllOKMethod;
}
public void DataIn(string Value)
{
Logic.DataIn(Value);
}
public void CreateInstances()
{
Logger = new FileLogger();
Logic = new MyLogic();
}
}
public class MyLogic : ILogic
{
public void DataIn(string Value)
{
//I want to check that all is ok before I do anything
//if (!AllOK)
//return;
//Do stuff
}
}

Implement INotifyPropertyChanged interface and subscribe to PropertyChanged event

I feel like it might be a bit more conventional to have your ILogger interface expose something like a "FileCreated" or "Ready" event, and allow your application to handle that event in order to update the ILogic object (or do whatever else is necessary).
EDIT: my apologies, after re-reading the question, I think I misunderstood what you were asking for.
There isn't any "natural" object that does exactly what you're asking, but you could create an anonymous delegate (or lambda expression) for this purpose:
Action<bool> loggerResult = (value) => Logic.ItsOKMethodSoSetVariableToTrue = value;

A property internally consists of two private methods, a get_XXX and a set_XXX, so unless you want to fetch the MethodInfo of those methods and invoke them (which are again methods) you have no choice but to implement a method calling approach.

Subscribing to event (INotifyPropertyChanged or some custom one) is OK, so is the method to pass a lambda-setter, but in some cases it might be more convinient to use a shared context object (much like the shared memory concept):
class ConversationContext
{
public bool EverythingIsOK { get; set;}
}
This object is passed to all interested objects (ILogic and ILogger) and they operate directly on it, instead of some internal properties. If change notifications are required, Implement INotifyPropertyChanged on it.
One positive aspect of this approach is that you won't get tangled in repeatedly firing events triggering other events and so on. A single object will hold the current state and no recurrent updates are needed.
Again, this is just one of many options.

How to define a new class that inherits from Delegate

is there anyway to do something similar to what ive got bellow.
What im trying to do is to invoke a list of delegates at a specific point in time and keep track of them, and for the sake of keeping code clean, keep the delegates to be invoked in a list of some sort.
public interface IServiceStatusDelegate
{
object DynamicInvoke(object[] args)
}
public class ServiceStatusDelegate
: Delegate, IServiceStatusDelegate
{
}
public class MyServiceStatusCheckedDelegate
: ServiceStatusDelgate
{
}
public class MyServiceStatusChangedDelegate
: ServiceStatusDelgate
{
}
public class MyClass
{
public ServiceStatusDelgate[] listOfDelegatesToInvoke;
public void InvokeRequiredDelegates()
{
foreach(ServiceStatusDelegate delegateToInvoke in this.listOfDelegatesToInvoke)
delegateToInvoke.DynamicInvoke(new object[]{this, DateTime.Now});
}
}

You don't need a list of delegates... any delegate you create in c# is going to be multicast, so all you need is any delegate, and you can combine them with +. Just invoke it and all targets will be reached. For example:
Action target = null;
...
target += Method1;
...
target += Method2;
...
if(target != null) target(); // calls Method1 and Method2
This could (although it isn't necessary for it to stand) be implemented via an event which will make the convention very obvious the caller.