Willkommen auf myCSharp.de! Anmelden | kostenlos registrieren
 | Suche | FAQ

Hauptmenü
myCSharp.de
» Startseite
» Forum
» Suche
» Regeln
» Wie poste ich richtig?

Mitglieder
» Liste / Suche
» Wer ist online?

Ressourcen
» FAQ
» Artikel
» C#-Snippets
» Jobbörse
» Microsoft Docs

Team
» Kontakt
» Cookies
» Spenden
» Datenschutz
» Impressum

  • »
  • Community
  • |
  • Diskussionsforum
gleichnamige Methoden (static,Instanz) mit identischer Signatur
RED-BARON
myCSharp.de - Member



Dabei seit:
Beiträge: 74

Themenstarter:

gleichnamige Methoden (static,Instanz) mit identischer Signatur

beantworten | zitieren | melden

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 ???
private Nachricht | Beiträge des Benutzers
Jamikus
myCSharp.de - Member



Dabei seit:
Beiträge: 246
Herkunft: NRW

beantworten | zitieren | melden

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

Oder habe ich etwas an deinen Beispiel missverstanden?
Dieser Beitrag wurde 1 mal editiert, zum letzten Mal von Jamikus am .
private Nachricht | Beiträge des Benutzers
RED-BARON
myCSharp.de - Member



Dabei seit:
Beiträge: 74

Themenstarter:

beantworten | zitieren | melden

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.
Dieser Beitrag wurde 1 mal editiert, zum letzten Mal von RED-BARON am .
private Nachricht | Beiträge des Benutzers
Ezio
myCSharp.de - Member

Avatar #avatar-3575.png


Dabei seit:
Beiträge: 189

beantworten | zitieren | melden

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.
private Nachricht | Beiträge des Benutzers
Abt
myCSharp.de - Team

Avatar #avatar-4119.png


Dabei seit:
Beiträge: 15.931

beantworten | zitieren | melden

Wenn sowas in Deinem Fall praktisch wäre, dann stimmt vermutlich der Grundaufbau schon nicht ;-)
private Nachricht | Beiträge des Benutzers
RED-BARON
myCSharp.de - Member



Dabei seit:
Beiträge: 74

Themenstarter:

beantworten | zitieren | melden

Der Grundaufbau ist schon okay, leider kann ich mich
nur noch an die Idee von gestern Abend erinnern, jedoch
nicht mehr an meinen Zustand ;-)
private Nachricht | Beiträge des Benutzers
Parso
myCSharp.de - Member



Dabei seit:
Beiträge: 157

beantworten | zitieren | melden

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.
Wenn's zum weinen nicht reicht, lach drüber!
private Nachricht | Beiträge des Benutzers
Uwe81
myCSharp.de - Member



Dabei seit:
Beiträge: 282
Herkunft: Ludwigshafen

beantworten | zitieren | melden

Zitat
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.....
private Nachricht | Beiträge des Benutzers
Palin
myCSharp.de - Member



Dabei seit:
Beiträge: 1.090

beantworten | zitieren | melden

Zitat von Uwe81
Zitat
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.
Sollte man mal gelesen haben:

Clean Code Developer
Entwurfsmuster
Anti-Pattern
private Nachricht | Beiträge des Benutzers
Palladin007
myCSharp.de - Member

Avatar #avatar-4140.png


Dabei seit:
Beiträge: 1.803
Herkunft: Düsseldorf

beantworten | zitieren | melden

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.
Dieser Beitrag wurde 1 mal editiert, zum letzten Mal von Palladin007 am .
private Nachricht | Beiträge des Benutzers
Abt
myCSharp.de - Team

Avatar #avatar-4119.png


Dabei seit:
Beiträge: 15.931

beantworten | zitieren | melden

Zitat von Palladin007
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.
private Nachricht | Beiträge des Benutzers
RED-BARON
myCSharp.de - Member



Dabei seit:
Beiträge: 74

Themenstarter:

beantworten | zitieren | melden

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.

Moderationshinweis von Coffeebean (13.03.2015 - 12:50)

Bitte benutze die richtigen Code-Tags [Hinweis] Wie poste ich richtig? Punkt 6

private Nachricht | Beiträge des Benutzers
Th69
myCSharp.de - Experte

Avatar #avatar-2578.jpg


Dabei seit:
Beiträge: 4.403

beantworten | zitieren | melden

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)
Dieser Beitrag wurde 1 mal editiert, zum letzten Mal von Th69 am .
private Nachricht | Beiträge des Benutzers
MarsStein
myCSharp.de - Experte

Avatar #avatar-3191.gif


Dabei seit:
Beiträge: 3.170
Herkunft: Trier -> München

beantworten | zitieren | melden

Hallo,
Zitat von Uwe81
Trivial threadsicher sind Methoden, die nur Parameter und Lokale Variablen verwenden.
Diese Aussage würde ich so nicht unterschreiben.
Trifft IMO nur zu, wenn die verwendeten Parameter alle Value Types (die auch nicht mit ref oder out übergeben werden) sind. Sobald man Referenzen übergibt, ist auch da der Spaß vorbei.

Gruß, MarsStein

edit: OT-color
Dieser Beitrag wurde 1 mal editiert, zum letzten Mal von MarsStein am .
Non quia difficilia sunt, non audemus, sed quia non audemus, difficilia sunt! - Seneca
private Nachricht | Beiträge des Benutzers
Abt
myCSharp.de - Team

Avatar #avatar-4119.png


Dabei seit:
Beiträge: 15.931

beantworten | zitieren | melden

.. und selbst int (char, byte, short..bool) ist in seiner Form als Eigenschaft nicht Thread-sicher.
private Nachricht | Beiträge des Benutzers