Laden...

Kann man im C# Funktionen über einen String aufrufen?

Erstellt von svennie89 vor 3 Jahren Letzter Beitrag vor 3 Jahren 891 Views
S
svennie89 Themenstarter:in
8 Beiträge seit 2012
vor 3 Jahren
Kann man im C# Funktionen über einen String aufrufen?

Hallo,
ich habe eine gewisse Anazhl von Funktionen

Funktion_1
Funktion_2
.....
Funktion_60

Basierend auf einer Variablen iFunktion (1-60) möchte ich diese Funktionen aufrufen.

Das mache ich im Momant über eine switch Anweise

Ich könnte mir aber auch vorstellen, dass ich das sinnvoller machen könnte in dem ich eine Varable mit callFunction = "Funktion_" + iFunktion erstelle und diese dann irgendwie aufrufe.

Nur das "Irgendwie" und ob es möglich ist, ist mir nicht klar.

Gibt es da etwas.

Ich kann mich dunktel erinnern, dass es in einer anderen Sprache sowas wie call @callFunktion gab.

Gibts es in C# auch so eine Möglichkeit ?

Danke
Sven

4.931 Beiträge seit 2008
vor 3 Jahren

Was ist denn dein genauer Use-Case dafür (String bzw. Zahl als Benutzereingabe)?

Du kannst alternativ noch ein Mapping benutzen (Dictionary<string, Action>) oder aber per Reflection die Methoden aufrufen.

Es kommt mir aber alleine von den Namen her schon sehr suspekt vor 60 (quasi unbenannte) Funktionen zu haben. Da gibt es sicherlich besser Design-Alternativen.

16.807 Beiträge seit 2008
vor 3 Jahren

Davon abgesehen, dass es in C# Methoden und nicht Funktionen heisst, ist das auch in anderen Sprachen eher ein klassischer Designfehler.
Du hast in anderen Sprachen eher "Glück", dass diese so einen schmutzigen Workaround erlauben; nicht aber in einer typisierten Sprache wie C# 😉

Wie Th69 schon geschrieben hat: erzähl mal was Du wirklich vor hast, und nicht wie Du Dir einen Workaround wünschst.

M
368 Beiträge seit 2006
vor 3 Jahren

Delegates könnten hier auch eine Option sein

Goalkicker.com // DNC Magazine for .NET Developers // .NET Blogs zum Folgen
Software is like cathedrals: first we build them, then we pray 😉

S
svennie89 Themenstarter:in
8 Beiträge seit 2012
vor 3 Jahren

Die Methoden (:-) sind nicht unbekannt. Ich habe mir ein Kalenderprogramm geschrieben mit aktuell 60 unterschiedlichen Kalendern.
Abhänging von der Auswahl wird die Funktion aufgerufen die den jeweiligen Kalender erstellt.

switch (iAuswahl)
{
     case 1:
        CreateKalender1();
        break;
.....

     case 59:
         CreateKalender59()
         break;
    default:
         CreateKalender60()
         break;
     
}

Ich möche das einfach so lösen:

   callFunction = &quot;CreateKalender&quot; + iFunction;  
   aufruf der Funktion callFunktion  

Dadurch möchte ich den Code kleiner halten un übersichtlicher. Speziell wenn weiterer Kalender dazu kommen.

16.807 Beiträge seit 2008
vor 3 Jahren

Das ist okay, dass Du das so lösen willst; aber Du musst halt akzeptieren, dass das in einer Sprache wie C# halt einfach nicht funktioniert.

Dein Beispiel zeigt, dass Deine Struktur hier mit 60 verschiedenen Methoden total unsinnig ist; und wie gesagt: auch in anderen Sprachen würde man das in ordentlicher Form so nicht machen - auch wenn einfache Sprachen sowas durch Hacks zulassen.
Man würde eine einzige Methode haben, der man dann Optionen übergeben kann, um die verschiedenen Kalender zu erzeugen.


CalendarOptions options = new CalendarOptions();
CreateCalendar(options);

Dann kannste Deine Optionen entsprechend organisieren (zB viele Optionen in einer Liste halten) und zB. anhand einer Id (Kalenderwoche?) identifizieren.

var calendarOption = allOptions.SingleOrDefault(cal => cal.Week == iAuswahl);
CreateCalendar(calendarOption);

Aber pro Kalender eine Methode - so funktioniert halt OOP nicht.
[FAQ] Wie finde ich den Einstieg in C#?

Wenn Du C# falsch anwendest, dann ist das so, als ob Du einen Hammer falschrum hälst und Dich wunderst, wieso der Nagel nicht in die Wand geht.

T
2.219 Beiträge seit 2008
vor 3 Jahren

Klingt auch stark nach einem fall von Factory Pattern.
Hier würde es Sinn machen das ganze via Interface ICalendar zu lösen und dann jeweils Ableitungen für die spezfischen Kalender zu bauen.
Und dann kannst du mit einer Factory einfach abhängig davon welchen Typen du willst, den konkreten Typen liefern.


//Interface was die Operation für alle Ableitungen vorgibt
public interface Calendar
{
    void Operation();
}

// DefaultCalender
public class DefaultCalendar : ICalendar
{
    // Implementiert die Operationen für diesen Kalender
    public void Operation()
    {
    }
}

// Weitere Ableitungen angedeutet
public class Calendar1 : ICalendar
// ....

public class Calendar1 : ICalendar
// ....

//Enum für unsere CalendarFactory
public enum CalendarType
{
    // Die Typen der Kalendar entsprechend zuweisen
    Default = 0,

    Calendar1 = 1,

    // ...
}

public static class CalendarFactory
{
     public static ICalendar CreateCalendar(CalendarType type)
     {
         switch(type)
         {
             case CalendarType.Default:
                return new DefaultCalendar();

            case CalendarType.Calendar1:
                return new Calendar1();

            // Weitere Typen kannst du hier einfügen
         }
     }
}

T-Virus

Developer, Developer, Developer, Developer....

99 little bugs in the code, 99 little bugs. Take one down, patch it around, 117 little bugs in the code.

16.807 Beiträge seit 2008
vor 3 Jahren

Das ist zwar OOP aber doch ziiiiiemlich mit Kanonen auf Spatzen 😉

T
2.219 Beiträge seit 2008
vor 3 Jahren

Kann man bestimmt auch einfacher machen, aber 60 unterschiedlichen Kalender nur durch Methoden abdecken ist doch etwas dürftig oder?
Oder sind es nur die Einstellungen z.B. an einem Kalender Control?
Dann wäre mein Ansatz tatsächlich etwas overdosed 😃

T-Virus

Developer, Developer, Developer, Developer....

99 little bugs in the code, 99 little bugs. Take one down, patch it around, 117 little bugs in the code.

16.807 Beiträge seit 2008
vor 3 Jahren

Oder sind es nur die Einstellungen z.B. an einem Kalender Control?

Das wissen wir ja nicht, weil es der Threadersteller bisher nicht gesagt hat.
Ich bin nun vom KISS-Prinzip ausgegangen und entsprechend der Anforderung, dass es hier nur um die Erzeugung von verschiedenen Kalender geht -> verschiedene Eigenschaften.
Da ist die einfachste Variante einfach eine Methode, die die Unterschiede entsprechend annimmt (in Form einer extra Klasse).
So kann man Varianz von Instanz trennen.

Eine Factory (hier) ist allein vom Aufwand (sieht man ja allein am Code Beispiel) weit weit weg von KISS.
Selbst wenn wir hier von extremst unterschiedlichen Kalenderarten sprechen, wäre die Factory eher der falsche Pattern.

Der Factory Pattern dient ja eigentlich als Constuctor-Ersatz, um Komplexität aus der Klasse auszulagern. zB auch wenn es darum geht für ein Interface dynamisch entsprechende Instanzen zu erzeugen, ohne die konkrete Implementierung zu kennen.
Das ist hier ja eher nicht der Fall - zumindest basierend auf den aktuell vorhandenen Informationen.

Von 60 verschiedene Methoden gleich auf Factory.. das ist halt Kanonen auf Spatzen.
Davon abgesehen wird vermutlich svennie89 den Pattern beim vermutlich vorhandenen Wissensstand nicht richtig anwenden können; das bringt ja dann auch nichts.

5.657 Beiträge seit 2006
vor 3 Jahren

Die Frage ist, wie man überhaupt Lösungsvorschläge zu dem Problem posten kann, wenn wir überhaupt nicht wissen, _wozu _es 60 verschiedene Kalender gibt, und worin die sich unterscheiden...

@svennie89:

Wenn du uns das mal erklärst, könnten wir dir einen zu deinem Vorhaben passenden Vorschlag machen

Weeks of programming can save you hours of planning

S
svennie89 Themenstarter:in
8 Beiträge seit 2012
vor 3 Jahren

Hallo,
ich habe es jetzt so gelöst:

var kalenderCreateMethod = "CreateKalender_" + iKalender;
var mi = this.GetType().GetMethod(kalenderCreateMethod, BindingFlags.NonPublic | BindingFlags.Instance);
mi?.Invoke(this, null);

16.807 Beiträge seit 2008
vor 3 Jahren

Gut, dass Du eine Lösung für Dich gefunden hast.

An alle anderen: bitte nicht nachmachen!
Gründe siehe Beiträge.