TheVBTutorialsVB schrieb:

ich habe nach Guidelines gesucht, allerdings keine gefunden.

Wenn ich die Codeanalyse vom Studio durchführe, kommt immer dann der Hinweis, eine Prozedur nach static zu überführen, wenn in ihr nicht auf Member (Prozeduren und Variablen) verwiesen wird.

Das macht natürlich Sinn, denn dann kannst Du die Methode Solo aufrufen, ohne eine Instanz erstellen zu müssen.

Ich würde eine statische Methode namens Vector3.AreOrthogonal(Vector3, Vector3) und eine Instanzmethode namens Vector3.IsOrthogonalTo(Vector3) machen.

Ich würde das so handhaben:

Bei >= 3 Argumenten:
Instanzmethoden geben dem ersten Argument optisch eine besondere Bedeutung. Nur wenn dieses erste Argument auch wirklich eine besondere Bedeutung hat, sollte man eine Instanzmethode verwenden. Wenn alle Argumente "gleichwertig" sind, dann sollte es eine statische Methode sein.
Gut:

Nicht so gut:
(String.Format ist übrigens genau "falsch" herum. Warum das so gemacht wurde weiß ich nicht.)

Bei 2 Argumenten:
Hier gilt das gleiche wie bei >= 3 Argumenten, aber es gibt öfter Ausnahmen.
Gut:

Nicht so gut:

Aber folgendes ist manchmal auch nötig:


Bei einem Argument:
Statische Methoden bei denen das einzige Argument von dem Typ ist, in dem die Methode deklariert ist, sind nur seeehr selten wirklich sinnvoll. Im Framework gibt es interessanterweise viele solche Methoden:

Warum das so gelöst wurde, weiß ich nicht, aber wenn man nur den Stil betrachtet, würde ich das nicht so machen.
Gut:

Nicht so gut:



Das sind natürlich nur Guidelines und keine festen Regeln. Guidelines kann man auch mal umgehen, wenn es in der Situation sinnvoll ist. Ich denke, das ist auch irgendwo Gefühlssache und Erfahrung.
Hier ein Beispiel für so eine Ausnahme: Verwendet man das Argument nur als ganzes und "schaut nie hinein", dann kann es sinnvoll sein, eine statische Methode zu verwenden.
Also zum Beispiel das:

Anstatt das:

Ich kann das jetzt nicht rational begründen, aber ich hatte mal so eine Situation (den Entities IDs zu geben hat das Debuggen extrem erleichtert) und da empfand ich es als schöner, eine statische Methode zu verwenden.

TheVBTutorialsVB schrieb:

Okay also wenn ich das richtig verstehe ist die Ansicht hier: Besser static wenn keine Attribute der Klasse in der Methode benötigt werden und alternativ einfach beide Implementierungen.

Danke

Dem würde ich widersprechen. Sowohl inhaltlich als auch dass icch denke, dass du das nicht richtig verstanden hast.
Rod gibt dir doch gute Guideline - ist das nicht genau, wonach du frugst?

RodFromGermany schrieb:

kommt immer dann der Hinweis, eine Prozedur nach static zu überführen, wenn in ihr nicht auf Member (Prozeduren und Variablen) verwiesen wird.

Wenn du nun eine Methode

TheVBTutorialsVB schrieb:

public bool IsOrthogonal(Vector3 other)...

anlegst, dann greift die doch notwendigerweise auf Objekt-Member zu, und damit ists doch geklärt.

---

Aber auch ohne iwelche herangezogene GuideLines - denk doch einfach mal einfach:
Man sagt: "Vektor A ist Orthogonal zu Vektor B".
Designe so, dass das direkt in Code formulierbar ist:Intuitiver kann man das meiner Meinung nach nicht designen - was meinst du?

@ErfinderDesRades Moin.
Wenn ich mir die static Procedures in den Klassen Rectangle und Co ansehe, ware dies ebenfalls salonfähig:

Hi
ich kenne keine abstrakte Regel, würde aber am ehesten auf Niko Ortners Versuch, die Intuition dahinter zu erklären, zurückgreifen.

Bzgl. String.Format: Ich vermute, dass es damit zusammenhängt, dass man "{0} ist so kluk.".Format("~blaze~") nicht lesen kann und den Zusammenhang bei komplexeren Zusammenhängen nicht erkennen kann. Da ist mir String.Format("{0} verwendet _niemals_ Ironie.", "~blaze~") dann doch lieber.

Mit der Zeit bildet (bzw. zumindest hat es das bei mir getan) sich eine gewisse Intuition im Umgang mit den statischen Methoden aus. Bei mir ist die Intuition eher, dass statische Methoden etwas von außen betrachten, wohingegen die Instanz bei einem Aufruf auf ihr von sich aus etwas mitteilt.
Bspw.: char.IsDigit betrachtet von außen, ob der angegebene char eine Zahl 0-9 ist. Würde man es auf char selbst implementieren (wovon ich allerdings nicht weiß, ob das ohne weiteres möglich ist, da es sich um primitive Datentypen handelt), würde man eher die Instanz dazu auffordern, ihren Status mitzuteilen.
Ich denke, man befindet sich irgendwo auf dem Kontinuum zwischen "Gehört zur Instanz" und "Beurteilt die Instanz von außen" und trifft die Entscheidung dann auf dieser Basis, aber sicher wäre ich mir jetzt nicht.

Edit:
@Niko Ortner: Bzgl. deines Codes nochmal eine Anmerkung: Wenn du TryCast verwendest (mit Nullable geht das auch für Strukturen), kannst du dir das TypeOf sparen. Beachte aber, dass die Überprüfung a.GetType() == b.GetType() exakter ist und in den meisten Fällen die "Wahrheit" liefert.

Viele Grüße
~blaze~

Von mir dann ergänzend auch noch eine Anmerkung, weil das bisher nicht bemerkt wurde:

Niko Ortner schrieb:

If TextBox_FilePath.Text.IsNullOrWhiteSpace() Then

erzeugt dummerweise eine NullReferenceException, wenn der Text tatsächlich null sein sollte. Dürfte zwar bei Textboxen quasi nicht vorkommen (ich weiß nichtmal, ob das bei Textboxen überhaupt geht), aber auf Strings allgemein bezogen bevorzuge ich deswegen dann doch lieber die statische Methode String.IsNullOrWhitespace() bzw. String.IsNullOrEmpty().

~blaze~ schrieb:

Bzgl. String.Format: Ich vermute, dass es damit zusammenhängt, dass man "{0} ist so kluk.".Format("~blaze~") nicht lesen kann und den Zusammenhang bei komplexeren Zusammenhängen nicht erkennen kann. Da ist mir String.Format("{0} verwendet _niemals_ Ironie.", "~blaze~") dann doch lieber.

Darüber hatte ich auch nachgedacht. "{0} grüßt {1}".Format("Niko", "~blaze~") sieht im ersten Moment tatsächlich sehr ungewöhnlich aus. Aber ich kann nicht beurteilen, ob mir das nur so komisch vor kommt, weil ich es von String.Format anders gewohnt bin, oder ob ich es tatsächlich einfach so nicht schön finde.
Ich stimme Dir jedenfalls zu, dass String.Format am Anfang einer langen Zeile besser zu erkennen ist, als erst hinter dem Format-String.

~blaze~ schrieb:

Wenn du TryCast verwendest (mit Nullable geht das auch für Strukturen), kannst du dir das TypeOf sparen

Geht übrigens nur in C#. Also C# 2010 kann das bereits, VB 2015 kann es nicht (eventuell im 2017-er schon?). Ich dachte erst, der C#-Compiler hätte hier einen Spezialfall und würde effektiv das kompilieren:

aber Nullable<int> AsInt = Other as int?; wird tatsächlich direkt so kompiliert:

Das ist also ein Spezialfall in der CLR, denn normalerweise resultiert isinst in false, wenn der Typ nicht exakt übereinstimmt (oder davon erbt) und unbox kann normalerweise nur das rausholen, was tatsächlich drin ist.
Interessant, dass es das in VB noch nicht gibt.

~blaze~ schrieb:

a.GetType() == b.GetType() exakter ist und in den meisten Fällen die "Wahrheit" liefert.

Falls Du damit meinst, dass z.B. (New B).Equals(New D) auch True zurückgibt, weil D von B abgeleitet ist, dann ja. (Dieser Fall kann bei Wertetypen nicht eintreten.) Ich habe Equals aber ehrlich gesagt zu wenig verwendet, um abschätzen zu können, was sinnvoller ist. Nach Bauchgefühl würde ich sagen, dass das Verhalten Deiner Variante besser ist.
Nebenbei: Hier muss man dann explizit auf Other auf Nothing prüfen, was man sich wiederum bei Typeof Other Is __ spart

Arby schrieb:

erzeugt dummerweise eine NullReferenceException, wenn der Text tatsächlich null sein sollte.

Weißt Du was? Das ist mir jetzt ehrlich gesagt schon ein bisschen peinlich, dass mir das nicht gleich aufgefallen ist. Ich schieb's mal auf meine Müdigkeit.
In diesem Fall würde eine Instanzmethode natürlich überhaupt nicht funktionieren. Wobei ich aber sagen muss, solche Fälle sehe ich selten. Also eine Funktion, die ein Objekt der Klasse verwendet, in der sie deklariert ist, und dann sowohl für Nothing, als auch für manche Zustände konzeptuell das gleiche Ergebnis liefert. Bei Strings braucht man das recht oft, aber zum Beispiel gibt es folgendes nicht:
weil es nicht häufig der Fall ist, dass es sinnvoll ist, Nothing und einen gewissen Zustand als gleich zu betrachten.

Imho solltest du sie als Public Function von Vector machen. Da es ja mehr sinn macht einen Vektor mit einem anderen zu vergleichen. Und am ende willst du ja wissen, ob V2 zu deinem aktuellen Vektor rechtwinklig ist. Daher: machs als Member Function von Vektor

@Niko: Wäre dann zu​VertexNormal.CrossProduct(VertexTangent) folgendes ​VertexNormal.MultiplyBy(VertexTangent) eine Alternative?

Radinator schrieb:

machs als Member Function von Vektor

jo - das wollte ich auch mit post#6 sagen/zeigen.

Radinator schrieb:

@Niko: Wäre dann zuVertexNormal.CrossProduct(VertexTangent) folgendes VertexNormal.MultiplyBy(VertexTangent) eine Alternative?

Oder einen *-Operator bereitstellen?

Radinator schrieb:

eine Alternative

Bedingt. Siehe unten. Aber allgemein gefällt es mir nicht, dass die beiden Vektoren nicht als "gleichwertig" erscheinen. VertexNormal ist ja nicht speziell. Aber die Namenskonvention, "By" hier anzuhängen, finde ich gut.

ErfinderDesRades schrieb:

Oder einen *-Operator bereitstellen

Allgemein ja. Aber bei Vektoren muss man aufpassen. Es gibt DotMultiplication und CrossMultiplication. Verwendet man hier den *-Operator, dann erkenn man nicht gut, welches von beiden gemeint ist. Aber den *-Operator für Vektoren mit Skalaren zu verwenden, ist kein Problem.

~blaze~ schrieb:

Bspw.: char.IsDigit betrachtet von außen, ob der angegebene char eine Zahl 0-9 ist. Würde man es auf char selbst implementieren (wovon ich allerdings nicht weiß, ob das ohne weiteres möglich ist, da es sich um primitive Datentypen handelt)

Natürlich hätte man Char.isDigit auch als Instanzmethode implementieren können. char ist ja auch nur ein struct. Die Idee dahinter, dass die Methode statisch ist, ist diejenige, dass sie threadsicher ist. Die meisten Methoden in der Framework Class Library folgen diesem Schema (statische Methode = threadsicher, Instanzmethode = nicht threadsicher)

Siehe auch hier
jonskeet.uk/csharp/threads/threadsafe.shtml
sd.blackball.lv/library/CLR_vi…_Richter_4th_Edition).pdf S.751

ErfinderDesRades schrieb:

Oder einen *-Operator bereitstellen?

in der Mathematik wird das Kreuzprodukt von Vektoren immer mit x dargestellt, also würde ich dafür niemals den * Operator bereitstellen, dann noch eher das Skalarprodukt, aber auch da finde ich es meiner Meinung nach nicht angebracht.
XNA macht hier z.B. ein Komponentenweises multiplizieren:
msdn.microsoft.com/en-us/library/bb198137.aspx

Meine Meinung aus Sicht der Grafikentwicklung:
Beides bereitstellen manchmal ist das eine übersichtlicher, manchmal das andere.
Mit tendenz zu den static Methoden für die meisten sachen^^
Performancetechnisch macht es am ende ebenfalls keinen Unterschied, vorallem sollte man mMn Vectoroperationen immer schön inlinen.
Kannst dich ja auch einfach hier inspirieren lassen:
msdn.microsoft.com/en-us/libra…work.vector3_members.aspx

Wenn sich jemand beschwert kannst immer noch sagen du hältsts dich halt so gut an die Regeln wie Microsoft selbst, das muss ja reichen^^