: this() Als Konstruktor

Question

Ich versuche, ein besseres Verständnis der allgemeinen Praxis zu bekommen ... speziell abgeleitet this() in einem Konstruktor. Ich verstehe, dass es weniger Code, aber ich halte es für weniger lesbar. Ist es üblich/gut, es so zu machen? Oder ist es besser, einen zweiten Konstruktor zu schreiben, der es speziell behandelt?

public SomeOtherStuff(string rabble) : this(rabble, "bloop") { } 

oder

Public SomeOtherStuff(string rabble) 
{ 
    //set bloop 
} 

Jede Eingabe schätzten

Answer 1

Es ist eine gute Praxis, wenn immer möglich this() zu verwenden. Andernfalls duplizieren Sie einen Code, der gegen das DRY-Prinzip (Do not Repair Yourself) verstößt. Das Problem mit sich selbst zu wiederholen ist, dass jedes Mal, wenn Sie eine Änderung vornehmen müssen - auch wenn es eine einfache Änderung an einer einzigen Zeile des Codes ist - müssen Sie merken gleichen an mehreren Stellen ändern, und behalten Sie die multiple Kopien synchronisiert.

Sie sollten den Code nur "duplizieren", wenn Sie müssen, da es anders sein muss, so dass es nicht mehr ein Duplikat ist. Auf diese Weise ist ein Duplikat eine Nachricht an den Leser, dass der Code tatsächlich anders ist, und dies aus einem bestimmten Grund.

Answer 2

ich weniger kümmern uns um die Lesbarkeit und mehr für Zuverlässigkeit wäre.

Verketten Konstruktoren ist viel besser als Copypasting Konstruktor Methode Körper.

Answer 3

So ketten Sie Konstrukteure und es ist eine vollkommen gültige Sache zu tun.

Answer 4

Das Problem mit den zwei separaten Konstruktoren ist, dass sie oft identischen Code enthalten, was zu Problemen mit späteren Refactorings führen kann, wenn ein Konstruktor geändert wird und der andere nicht. So könnte man sehen, dass der Konstruktor mit diesem() als eine Anwendung der DRY principle verkettet ist.

Answer 5

Initialisierungslisten sind in der Industrie weit verbreitet.

Aus Gründen der Lesbarkeit ... ist das eine Frage der Meinung. Aber Wartbarkeit ist in der Regel ein höheres Ziel zu erreichen.

DRY ist eine gute Sache :)

Answer 6

Ich mag die erste Möglichkeit (Konstruktorverkettung), aber wenn Sie die zweite Möglichkeit, das Gefühl besser lesbar ist dann für das gehen, und Sie könnten, was doppelte Code, den Sie in die haben setzen Konstruktoren zu einer privaten Methode, um zu vermeiden, das von den Menschen erwähnte DRY-Prinzip zu brechen.

Außerdem versuche ich auch immer, im Stil des Codes zu arbeiten, an dem ich arbeite - wenn also der vorherrschende Stil der eine oder der andere ist, würde ich mit diesem Stil aus Konsistenz gehen.

Answer 7

Eine andere Möglichkeit zu DRY ist das Schreiben einer Initialisierungsmethode, zum Beispiel Init(rabble, bloop) und alle Konstruktoren rufen diese Methode auf.

Dies ist tendenziell weniger verwirrend und flexibler, vor allem dort, wo es viele Konstruktoren gibt.