gleichnamige Methoden (static,Instanz) mit identischer Signatur

Hallo,

ich habe einen Fall indem es elegant wäre gleichnamige
Methoden (static, Instanz) mit identischer Signatur anbieten
zu können.

Class.Method1(....)
InstanzClass.Method1(...)

Was ich bisher gelesen habe, besteht diese Möglichkeit so nicht.
Oder doch ???

so wie hier [erledigt] Methoden überladen mit Klasse als Parameter --> Polymorphie?

Oder habe ich etwas an deinen Beispiel missverstanden?

Hallo, ich meinte konkret sowas.

public class Do
{
public static void It()
{}
public void It()
{}
}

class Programm
{
Do.It();

var do = new Do();
do.It();

}

Das wird vom Compiler so jedoch nicht akzeptiert. Ich verstehe das auch, nur
habe ich einen Fall, indem es sehr komfortabel wäre keine unterschiedlichen
Methoden-Namen zu haben.

Hallo RED-BARON,
du willst also eine nicht-statische Methode mit einer statischen Methode überladen, wobei beide die gleiche Signatur aufweisen?
Das geht nicht, die Art oder die Anzahl der Parameter MUSS sich unterscheiden, damit du überladen darfst.

Wenn sowas in Deinem Fall praktisch wäre, dann stimmt vermutlich der Grundaufbau schon nicht 😉

Der Grundaufbau ist schon okay, leider kann ich mich
nur noch an die Idee von gestern Abend erinnern, jedoch
nicht mehr an meinen Zustand 😉

Na klar geht das, aber nur wenn du es mit nem Interface machst und die gleichnamige Methode explizit implementierst:

    interface IDo
    {
        void It();
    }

    public class Do : IDo
    {
        public static void It()
        {
        }
        void IDo.It()
        {
            Do.It();
        }
    }

Obs dir was bringt..ist was anderes. Statische Methoden sind solange praktisch, solange du nicht versuchst threads zu verwenden, dann kann es knifflig werden.

Statische Methoden sind solange praktisch, solange du nicht versuchst threads zu verwenden, dann kann es knifflig werden.

Das ist so falsch. Das Problem tritt bei statischen Variablen auf. Gegen Statische Methoden, welche nur Parameter und lokale Variablen haben, spricht nichts. Im gegenteil halte ich das für eine sehr einfache Möglichkeit, Threadsicherheit zu erreichen.

Ist dann zwar quasi prozedurale Programmierung als OOP, aber wenn es zum Problem passt (mathematische Algorithmen o.Ä.) völlig OK.

Es ist sogar so, dass - wenn ich ein Objekt habe, welches einen Algorithmus durchführt und dabei seinen inneren Zustand temporär verändert - ich sehr gerne statische Hilfsmethoden schreibe die eine Instanz erzeugen, den Algorithmus ausführen, die Instanz wegwerfen und das Ergebniss zurückgeben. Quasi um Threadsicherheit zu garantieren.

Zusammenfassend zum Thema Threads:
Trivial threadsicher sind Methoden, die nur Parameter und Lokale Variablen verwenden.

Gefährlich sind immer äußere Zustände. Bei normalen Objekten kann mann dann verschiedene Instanzen anlegen, bei statischen, nicht readonly Variablen hat man ein Problem.....

Statische Methoden sind solange praktisch, solange du nicht versuchst threads zu verwenden, dann kann es knifflig werden.

Das ist so falsch. Das Problem tritt bei statischen Variablen auf. Gegen Statische Methoden, welche nur Parameter und lokale Variablen haben, spricht nichts. Im gegenteil halte ich das für eine sehr einfache Möglichkeit, Threadsicherheit zu erreichen.

@Uwe ganz unrecht hast du da natürlich nicht. Aber ich denken für mit der Threadsicherheit hält es sich in grenzen. Quellcode ändert sich und wenn dann ein Kollege 1 Jahr später denkt, er brauch eine Membervariable die static sein muss. Weil er sie in mehreren Methoden braucht. Gibt es plötlich komische Effekte in der Software. Die schwer zu finden sind.

Parsos hinweiß finde ich da nicht so schlecht.

Statische Methoden nutze ich nur in zwei Fällen:

Wenn ein in diesem Fall sinnvolles Pattern dies verlangt (z.B. Factory) oder, wenn die Methode in sich abgeschlossen und private ist.

Statische Variablen sind auch performanter. Das hat ein Kollege mal gelesen, dass der Compiler statische Methoden besser optimieren kann. Da ich häufig Methoden habe, die einzig dafür da sind, eine komplexe Methode in übersichtliche Teilaufgaben zu teilen, bietet es sich an, diese Methoden private static zu machen.

Aus dem Grund halte das Vorhaben von RED-BARON nicht vorteilhaft.
public static Methoden sind in den meisten Fällen sehr kritisch zu betrachten, wenn sie dagegen private und in sich abgeschlossen sind, dann kann man sie ja auch mal DoId_Internal nennen, da stört sich dann keiner drum. Microsoft macht das auch häufig.

Statische Variablen sind auch performanter. Das hat ein Kollege mal gelesen, dass der Compiler statische Methoden besser optimieren kann.

Das ist wahr - zumindest halb. Es ist nicht die Optimierung.
Da der Compiler bei static methods / vars eine call instructuon auf IL-Basis umsetzen kann, gibt es eine If-Abfrage (Ref = null) weniger.
Bei Methoden von Instanzen wird ein callvirt instruction umgesetzt. Ebenso ist der Footprint geringer, da die Methode im Overhead nur ein mal existiert.
Ich werf aber mal in dem Raum, dass Du das nur bei 0.001% der Umsetzungen wirklich merken könntest.
Hier wäre also die Frage sinnvoll static bei dieser Argumentation noch ist. Wenn das ein (wichtiger) Orientierungspunkt für ein Code-Design darstellt ist das definitiv der falsche Weg.

Wichtig heutzutage ist aber vor allem die Code Wartung und die Testbarkeit.
Und hier gewinnt die Instanz-Variante mit Meilen-weitem Vorsprung.

Ich hab das mit dem Interface mit Absicht nicht zur Sprache gebracht, da es mehr Verwirrung bringt als hilft.
Daher zweifle ich eher immer noch den Grundaufbau an.

Hallo,

wie Uwe schrieb:
"statische Hilfsmethoden schreibe die eine Instanz erzeugen, den Algorithmus ausführen, die Instanz wegwerfen"

genau das hatte ich so vor. Es soll aber auch die Instanz selber die Methoden
anbieten können ohne dann nochmals eine Instanz intern zu erzeugen, versteht sich.

Im konkreten Fall wird eine externe Ressource angesprochen auf die einmalig
und ohne "großen" Aufwand zugegriffen werden können soll. Ressource wird
dabei geöffnet und sofort wieder freigegeben.

Es soll aber auch möglich sein durch erzeugen der Instanz "sagen" zu können
ich möchte jetzt mehrere Zugriffe auf die Ressource durchführen.

Do.It_1() oder Do.It_2() oder Do.It_3()

using(var do = new Do())
{
 do.it_1();
 do.it_2();
 do.it_3();
}

Wenn es sich bei der Ressource z.B. um eine Netzwerkverbindung handelt
wird verständlicher was ich bezwecken möchte.

Du könntest auch die statischen Methoden in eine eigene statische Klasse packen. Dann hätte nur diese statische Klasse einen anderen Namen, aber die Methodennamen wären gleich.

Edit: und/oder in einen anderen Namensbereich (namespace)

.. und selbst int (char, byte, short..bool) ist in seiner Form als Eigenschaft nicht Thread-sicher.