myCSharp.de - DIE C# und .NET Community
Willkommen auf myCSharp.de! Anmelden | kostenlos registrieren
 
 | Suche | FAQ

» Hauptmenü
myCSharp.de
» Startseite
» Forum
» FAQ
» Artikel
» C#-Snippets
» Jobbörse
» Suche
» Regeln
» Wie poste ich richtig?
» Forum-FAQ

Mitglieder
» Liste / Suche
» Wer ist wo online?

Ressourcen
» openbook: Visual C#
» openbook: OO
» Microsoft Docs

Team
» Kontakt
» Übersicht
» Wir über uns

» myCSharp.de Diskussionsforum
Du befindest Dich hier: Community-Index » Diskussionsforum » Entwicklung » Code-Reviews » Property, die nur einmal gesetzt werden kann
Letzter Beitrag | Erster ungelesener Beitrag Druckvorschau | Thema zu Favoriten hinzufügen

Antwort erstellen
Zum Ende der Seite springen  

Property, die nur einmal gesetzt werden kann

 
Autor
Beitrag « Vorheriges Thema | Nächstes Thema »
LaTino LaTino ist männlich
myCSharp.de-Poweruser/ Experte

avatar-4122.png


Dabei seit: 03.04.2006
Beiträge: 2.993
Entwicklungsumgebung: Rider / VS2019 / VS Code
Herkunft: Thüringen


LaTino ist offline

Property, die nur einmal gesetzt werden kann

Beitrag: beantworten | zitieren | editieren | melden/löschen       | Top

(@mods: falls das doch in die snippets soll, nur zu, ich war mir unsicher)

Möglichkeit eins: readonly
Das Schlüsselwort readonly kann auf Felder einer Klasse angewendet werden. Felder, die so markiert werden, können für nicht-statische Klassen nur direkt bei der Deklaration, oder im Konstruktor der Klasse gesetzt werden. Danach können sie nicht mehr verändert werden.

C#-Code:
class ExampleClass
{
    private readonly int _readonlyField;

    public int ReadonlyProperty => _readonlyField;

    public ExampleClass(int readonlyValue)
    {
        _readonlyField = readonlyValue; //einziges Mal, dass die Variable gesetzt werden kann.
    }
}

Möglichkeit zwei: Nullable
Diese Möglichkeit eignet sich für Werttypen - Zahlen zum Beispiel. Das Feld, in dem ihr Wert gespeichert wird, ist ein Nullable<T>, und der Setter des Property prüft, ob das Feld bereits einen Wert hat.

C#-Code:
class ExampleClass
{
    private int? _nullableField;

    public int? ReadonlyProperty
    {
        get
        {
            if(_nullableField.HasValue) return _nullableField;
            throw new InvalidOperationException($"Field {nameof(_nullableField)} has not been set (yet)!");
        }
        set
        {
            if(_nullableField.HasValue) throw new InvalidOperationException($"Field {nameof(_nullableField)} has already been set!");
            _nullableField = value;
        }
    }
}

Möglichkeit drei: Set-Memory
Ein Set-Memory ist einfach eine Variable, in der gespeichert wird, ob eine Property gesetzt wurde oder nicht. Diese Möglichkeit eignet sich für alle Typen, funktioniert aber nur, wenn der Set-Memory auch wirklich jedesmal gesetzt wird, wenn die Property sich ändert.

C#-Code:
class ExampleClass
{
    private bool _setMemory;
    private int _readonlyProperty;

    public int ReadonlyProperty
    {
        get { return _readonlyProperty; }
        set
        {
            if (!_setMemory)
            {
                _readonlyProperty = value;
                _setMemory = true;
            }
            else throw new InvalidOperationException($"Field {nameof(_readonlyProperty)} has already been set!");
        }
    }
}

Möglichkeit drei++
Die in Möglichkeit drei beschriebene Vorgehensweise lässt sich natürlich noch in eine eigene Klasse kapseln, so dass die Übersicht in der benutzenden Klasse nicht verloren geht.

(Vorschlag T-Virus)

C#-Code:
class ExampleClass
{
    private readonly SetAnywhereReadonly<int> _readonlyValue = new SetAnywhereReadonly<int>();

    public int ReadonlyProperty
    {
        get => _readonlyValue.Value;
        set => _readonlyValue.Value = value;
    }
}

class SetAnywhereReadonly<T>
{
    private bool _setMemory;
    private T _value;

    public T Value
    {
        get => _value;
        set
        {
            if (!_setMemory)
            {
                _value = value;
                _setMemory = true;
            }
            else throw new InvalidOperationException($"Field {nameof(_value)} has already been set!");
        }
    }
}

LaTino
(ruhig ergänzen / diskutieren)
EDIT: Vorschlag von T-Virus ergänzt

Dieser Beitrag wurde 4 mal editiert, zum letzten Mal von LaTino am 18.05.2017 08:26.

Neuer Beitrag 18.05.2017 07:58 E-Mail | Beiträge des Benutzers | zu Buddylist hinzufügen
T-Virus T-Virus ist männlich
myCSharp.de-Mitglied

Dabei seit: 17.04.2008
Beiträge: 1.499
Entwicklungsumgebung: Visual Studio, Codeblocks, Edi
Herkunft: Nordhausen, Nörten-Hardenberg


T-Virus ist offline Füge T-Virus Deiner Kontaktliste hinzu

Beitrag: beantworten | zitieren | editieren | melden/löschen       | Top

Wäre hilfreich die Klasse als Generic zu haben.
Dann kann man die Instanz der Klasse als Property verwenden, die diesen Zweck erfüllt.
Wird bei einer Klasse die mehrere solcher Properties braucht, sonst schnell unübersichtlich.
So kann ich einfach eine entsprechende Instanz erstellen und diese verwenden.

T-Virus
Neuer Beitrag 18.05.2017 08:12 E-Mail | Beiträge des Benutzers | zu Buddylist hinzufügen
LaTino LaTino ist männlich
myCSharp.de-Poweruser/ Experte

avatar-4122.png


Dabei seit: 03.04.2006
Beiträge: 2.993
Entwicklungsumgebung: Rider / VS2019 / VS Code
Herkunft: Thüringen

Themenstarter Thema begonnen von LaTino

LaTino ist offline

Beitrag: beantworten | zitieren | editieren | melden/löschen       | Top

Stimmt. Eine Möglichkeit, das zu tun, habe ich mal ergänzt.

LaTino
Neuer Beitrag 18.05.2017 08:27 E-Mail | Beiträge des Benutzers | zu Buddylist hinzufügen
Abt
myCSharp.de-Team

avatar-4119.png


Dabei seit: 20.07.2008
Beiträge: 13.825
Herkunft: Stuttgart/Stockholm


Abt ist offline

Beitrag: beantworten | zitieren | editieren | melden/löschen       | Top

Was wäre denn ein konkreter Use Case?
Neuer Beitrag 18.05.2017 10:28 Beiträge des Benutzers | zu Buddylist hinzufügen
LaTino LaTino ist männlich
myCSharp.de-Poweruser/ Experte

avatar-4122.png


Dabei seit: 03.04.2006
Beiträge: 2.993
Entwicklungsumgebung: Rider / VS2019 / VS Code
Herkunft: Thüringen

Themenstarter Thema begonnen von LaTino

LaTino ist offline

Beitrag: beantworten | zitieren | editieren | melden/löschen       | Top

Für readonly?

Die anderen Möglichkeiten sind ausschließlich dafür gedacht, die Beschränkung von readonly (Setzen ausschließlich im c'tor oder Deklaration) zu umgehen. So was ähnliches ist bei uns zB in den Factories im Einsatz, um die Stellen handlicher zu machen, die IoC per Property Injection realisieren. Oder du setzt eine readonly-Variable, die Werte benötigt, die im Konstruktor noch nicht verfügbar sind.

Letzten Endes alles Fälle, um die Art und Weise, wie eine Property benutzt wird, weiter einzuschränken, als die Sprache selbst das erlauben würde.

LaTino

Dieser Beitrag wurde 1 mal editiert, zum letzten Mal von LaTino am 18.05.2017 15:30.

Neuer Beitrag 18.05.2017 15:30 E-Mail | Beiträge des Benutzers | zu Buddylist hinzufügen
T-Virus T-Virus ist männlich
myCSharp.de-Mitglied

Dabei seit: 17.04.2008
Beiträge: 1.499
Entwicklungsumgebung: Visual Studio, Codeblocks, Edi
Herkunft: Nordhausen, Nörten-Hardenberg


T-Virus ist offline Füge T-Virus Deiner Kontaktliste hinzu

Beitrag: beantworten | zitieren | editieren | melden/löschen       | Top

@LaTino
Wäre es dann vielleicht noch hilfreich, auch deinen Fall über einen Konstruktor abzudecken?
Also beim setzen des Wertes über den Konstrutor gleich auch den Wert auf gesetzt zustellen?
Dann kann man den Wert entweder beim Initalisieren über den Kosntruktor oder durch entsprechenden Aufruf des Setter einmalig setzen.
Dann solltest du aber auch einen Default Konstruktor mitgeben der dann eben leer bleibt.
So kann man den Wert auch später setzen aber spart sich ggf. endlose null Prüfungen.

Ebenfalls wäre auch eine Getter für eine Abfrage ob der Wert bereits gesetzt wurde eine sinnvoll Erweiterung.
Somit würde man sich durch eine entsprechende Prüfung die Exception aus dem Setter sparen.
Wäre aber ggf. ein Sonderfall.

Nachtrag:
Würde reichen im Konstruktor den Setter aufzurufen.
Der erledigt schon alles.

T-Virus

Dieser Beitrag wurde 1 mal editiert, zum letzten Mal von T-Virus am 18.05.2017 17:15.

Neuer Beitrag 18.05.2017 17:09 E-Mail | Beiträge des Benutzers | zu Buddylist hinzufügen
Abt
myCSharp.de-Team

avatar-4119.png


Dabei seit: 20.07.2008
Beiträge: 13.825
Herkunft: Stuttgart/Stockholm


Abt ist offline

Beitrag: beantworten | zitieren | editieren | melden/löschen       | Top

Zitat von T-Virus:
Wäre es dann vielleicht noch hilfreich, auch deinen Fall über einen Konstruktor abzudecken?

An genau das würde ich denken, wenn ich diese Anforderung lese.
Wenn ich ein Property nur ein mal setzen will, und ich mach das über den Setter, dann stimmt doch was am Code nicht... verwundert

Daher die Frage des Anwendungsfalls:
welche Situation gibt es denn, die nicht über einen Konstruktor mit entsprechendem Design umsetzbar wäre?
So würde ich das persönlich als suboptimale Umsetzung empfinden.
Neuer Beitrag 18.05.2017 22:24 Beiträge des Benutzers | zu Buddylist hinzufügen
Palladin007 Palladin007 ist männlich
myCSharp.de-Mitglied

Dabei seit: 03.02.2012
Beiträge: 1.258
Entwicklungsumgebung: Visual Studio 2017
Herkunft: NRW


Palladin007 ist offline

Beitrag: beantworten | zitieren | editieren | melden/löschen       | Top

Eine konkrete Idee, wo das vielleicht hilft:

In einem ViewModel mit vielen Commands, die Commands sind bei mir immer readonly.
Allerdings kann das recht schnell den Konstruktor aufblähen, weshalb es zur Übersicht beitragen würde, wenn diese Command-Instantiierungen in einer eigenen Methode - z.B. InitCommands - statt finden.
Das geht natürlich nur, wenn die Property nicht readonly ist

Ein besseres Beispiel fällt mir aber auch nicht ein :D
Neuer Beitrag 18.05.2017 23:39 Beiträge des Benutzers | zu Buddylist hinzufügen
LaTino LaTino ist männlich
myCSharp.de-Poweruser/ Experte

avatar-4122.png


Dabei seit: 03.04.2006
Beiträge: 2.993
Entwicklungsumgebung: Rider / VS2019 / VS Code
Herkunft: Thüringen

Themenstarter Thema begonnen von LaTino

LaTino ist offline

Beitrag: beantworten | zitieren | editieren | melden/löschen       | Top

Wie gesagt, wenn man etwas intensiver mit property injection arbeitet, kann das unter Umständen ganz hilfreich sein. Natürlich kann man property injection komplett mit c'tor injection abbilden, aber es ist nunmal situationsabhängig, welche Methode ich einsetze.

Bin etwas befremdet darüber, dass bestimmte Techniken abgelehnt werden, nur weil einem kein Beispiel einfällt, wofür man selbst das brauchen könnte. Wenn man xy erreichen will, hat man Möglichkeit a, b und c, das zu erreichen. Da muss ich doch nicht darübner diskutieren, dass man selbst noch nie xy erreichen wollte.

LaTino

EDIT:
Noch mal langsam:
- sinnvoll, um einen Wert einmalig mit etwas zu füllen, dass zur Konstruktion noch nicht verfügbar ist. Nennt es write-once lazy loading, jedenfalls mit einer Mechanik, die sicherstellt, dass nur einmal gesetzt wird. Dass das hilfreich ist, wenn -zig Leute am Code rumbauen, von denen nicht jeder weiß, dass die Prop gesetzt sein muss, und dass sie nur einmal gesetzt werden sollte, muss ich nicht wirklich erläutern?
- im Konstruktor einen Setter aufrufen? Soviel Masochismus habe ich dann doch nicht, danke :D.
- Ja, ich gestehe gern zu, dass das Sonderfälle sind. Es kann aber hilfreich sein, und wenn man es braucht, hat man die obigen drei Möglichkeiten, es einigermaßen sauber zu implementieren.

Dieser Beitrag wurde 1 mal editiert, zum letzten Mal von LaTino am 19.05.2017 07:28.

Neuer Beitrag 19.05.2017 07:23 E-Mail | Beiträge des Benutzers | zu Buddylist hinzufügen
Abt
myCSharp.de-Team

avatar-4119.png


Dabei seit: 20.07.2008
Beiträge: 13.825
Herkunft: Stuttgart/Stockholm


Abt ist offline

Beitrag: beantworten | zitieren | editieren | melden/löschen       | Top

Das ist keine ablehnende Haltung; das ist nur - Du sagst es ja so gern- aus meinem Empfinden eher ein Anti Patterm :-)
Neuer Beitrag 19.05.2017 08:37 Beiträge des Benutzers | zu Buddylist hinzufügen
LaTino LaTino ist männlich
myCSharp.de-Poweruser/ Experte

avatar-4122.png


Dabei seit: 03.04.2006
Beiträge: 2.993
Entwicklungsumgebung: Rider / VS2019 / VS Code
Herkunft: Thüringen

Themenstarter Thema begonnen von LaTino

LaTino ist offline

Beitrag: beantworten | zitieren | editieren | melden/löschen       | Top

Hm, jein. Das gewünschte Verhalten an sich ist nix schlimmes, die Verwendung birgt in sich aber ein hohes Risiko, Probleme zu bereiten. (siehe Setteraufruf im Konstruktor, was eben wirklich in die Hose gehen kann und nicht offensichtlich ist). Tatsächlich sind hier die Tests für die betreffenden Komponenten unter denen, die am häufigsten rot werden. Nur ist der Einsatz gerechtfertigt und auch nicht ohne weiteres ersetzbar :). Wenn man's braucht, sollte man zusehen, ob man sein Design nicht so ändern kann, dass Variante eins - simples readonly - benutzt werden kann. Dann ist man auf der sicheren Seite, und bekommt obendrein sogar Compilerfehler, wenn man's falsch macht.

LaTino
Neuer Beitrag 19.05.2017 09:42 E-Mail | Beiträge des Benutzers | zu Buddylist hinzufügen
Deaktiviertes Profil Deaktiviertes Profil ist männlich
myCSharp.de-Mitglied

Dabei seit: 06.07.2014
Beiträge: 985


Deaktiviertes Profil ist offline

Beitrag: beantworten | zitieren | editieren | melden/löschen       | Top

@Palladin007

Wenn die Command-Properties über eine Methode gesetzt werden, dann deklariert man diese Properties als

C#-Code:
public Foo Foo { get; private set; }
private bool _fooInitialized;
public void InitializeFoo( Foo foo )
{
    if ( _fooInitialized ) throw new InvalidOperationException();
    Foo = foo;
    _fooInitialized = true;
}

Wenn die Commands aber sowieso von aussen kontrolliert werden, warum dann diese erhöhte Komplikation?

Ich lasse die einfach beschreibbar und gut ist. Das wäre eher etwas was in einen Unit Test geprüft wird (was du sowieso machen musst um zu überprüfen, ob dort auch wirklich InitializeCommands aufgerufen wurde)

Dieser Beitrag wurde 1 mal editiert, zum letzten Mal von Deaktiviertes Profil am 19.05.2017 09:55.

Neuer Beitrag 19.05.2017 09:49 Beiträge des Benutzers | zu Buddylist hinzufügen
Abt
myCSharp.de-Team

avatar-4119.png


Dabei seit: 20.07.2008
Beiträge: 13.825
Herkunft: Stuttgart/Stockholm


Abt ist offline

Beitrag: beantworten | zitieren | editieren | melden/löschen       | Top

Ernst gemeinte Frage...
Wieso kein Property ohne Setter und dafür eine TrySet-Methode, die false zurück gibt, wenn es im Readonly-Modus ist?

Für mich sieht das wirklich nach Konzept-Misshandlung von Eigenschaften aus.
Ich bemängle nicht die Anforderung, sondern die Umsetzung.

Zitat von LaTino:
Wenn man's braucht, sollte man zusehen, ob man sein Design nicht so ändern kann, dass Variante eins - simples readonly - benutzt werden kann. Dann ist man auf der sicheren Seite, und bekommt obendrein sogar Compilerfehler, wenn man's falsch macht.

Eben.
Neuer Beitrag 19.05.2017 10:06 Beiträge des Benutzers | zu Buddylist hinzufügen
Palladin007 Palladin007 ist männlich
myCSharp.de-Mitglied

Dabei seit: 03.02.2012
Beiträge: 1.258
Entwicklungsumgebung: Visual Studio 2017
Herkunft: NRW


Palladin007 ist offline

Beitrag: beantworten | zitieren | editieren | melden/löschen       | Top

@SirRufo:

Ich meine es eher so:

C#-Code:
public ICommand DoACommand { get; }
public ICommand DoBCommand { get; }
public ICommand DoCCommand { get; }

public MyClass()
{
    DoACommand = new DoACommand();
    DoBCommand = new DoBCommand();
    DoCCommand = new DoCCommand();
}

Sind das jetzt aber nicht nur 3 Commands, sondern z.B. 15, dann wird's schon voll.
Wenn im Konstruktor dann auch noch andere Dinge gemacht werden sollen, ist's schön, wenn das doch recht stumpfe erstellen der Commands in einer eigenen Methode liegt.

Das sähe dann so aus:

C#-Code:
public ICommand DoACommand { get; private set; }
public ICommand DoBCommand { get; private set; }
public ICommand DoCCommand { get; private set; }

public MyClass()
{
    CreateCommands();
}

private void CreateCommands()
{
    DoACommand = new DoACommand();
    DoBCommand = new DoBCommand();
    DoCCommand = new DoCCommand();
}

Klar, kann ich den Setter auch einfach private lassen, ich versuche aber immer die Felder/Properties, die sich nicht ändern sollen/dürfen readonly zu machen, dann kann da gar nicht erst ein Fehler entstehen.
Da würde LaTinos Idee helfen. Die Setter sind zwar immer noch da, aber selbst wenn jemand auf die blöde Idee kommt, den ein zweites mal zu nutzen, dann fällt das spätestens bei den Tests auf.

Dieser Beitrag wurde 2 mal editiert, zum letzten Mal von Palladin007 am 19.05.2017 10:10.

Neuer Beitrag 19.05.2017 10:09 Beiträge des Benutzers | zu Buddylist hinzufügen
Abt
myCSharp.de-Team

avatar-4119.png


Dabei seit: 20.07.2008
Beiträge: 13.825
Herkunft: Stuttgart/Stockholm


Abt ist offline

Beitrag: beantworten | zitieren | editieren | melden/löschen       | Top

Und es ist nun besser mehrere Methoden zu haben statt die Arbeit in einen "vollen" Konstruktor zu packen...? verwundert

PS:

C#-Code:
public ICommand DoACommand { get; } = new DoCAommand();
public ICommand DoBCommand { get; } = new DoBCommand();
public ICommand DoCCommand { get; } = new DoCCommand();

public MyClass() { }

PS: wenn ein Konstruktor voll ist, dann ist das für mich ein Anzeichen, dass eine oder mehrere Basisklassen zur Übersicht beitragen könnte.
Neuer Beitrag 19.05.2017 10:14 Beiträge des Benutzers | zu Buddylist hinzufügen
Palladin007 Palladin007 ist männlich
myCSharp.de-Mitglied

Dabei seit: 03.02.2012
Beiträge: 1.258
Entwicklungsumgebung: Visual Studio 2017
Herkunft: NRW


Palladin007 ist offline

Beitrag: beantworten | zitieren | editieren | melden/löschen       | Top

Das ist nur ein kleines Code-Beispiel ^^

Ich nutze z.B. ganz gerne das RelayCommand bzw. manchmal bringt ein "echtes" Command (eigene Klasse) einfach keinen Vorteil.
Oder wenn ein Command einen Zustand des ViewModels braucht, der im Konstruktor erst hergestellt wird.

Dann fliegt der direkte Feldinitializer (so wird's zumindest in der Fehlermeldung genannt) raus, der kann nicht auf Instanz-Member zugreifen.

Dieser Beitrag wurde 1 mal editiert, zum letzten Mal von Palladin007 am 19.05.2017 10:19.

Neuer Beitrag 19.05.2017 10:19 Beiträge des Benutzers | zu Buddylist hinzufügen
Palin Palin ist männlich
myCSharp.de-Mitglied

Dabei seit: 22.08.2011
Beiträge: 1.090
Entwicklungsumgebung: VB.net


Palin ist offline

Beitrag: beantworten | zitieren | editieren | melden/löschen       | Top

Um ehrlich zu sein für mich wirkt es auch ein wenig wie ein Workaround, denn ich so eigendlich nicht verwenden sollte.

Grundlegend sollten ja bei der Initialisierung einer Klasse alle nötigen Abhänigkeiten vorhanden sein.
Wenn nicht initialisiere ich meist die Klasse an der falsche Stelle bzw. Zeitpunkt. Oder die Klasse hat vielleicht zu viele Verantwortlichkeiten (SRP).
Was meines Erachtens ein Design Fehler ist, der behoben werden sollte.

Dann wird noch die Instantiierung von der Initialisierung getrennt. Was meines Erachtens die Wartbarkeit verschlechtert. Ich muss immer an 2 Stellen nachschauen und ich muss wissen, das ich an 2 Stellen nachschauen muss.

Zitat von LaTino:
Dass das hilfreich ist, wenn -zig Leute am Code rumbauen, von denen nicht jeder weiß, dass die Prop gesetzt sein muss, und dass sie nur einmal gesetzt werden sollte, muss ich nicht wirklich erläutern?

An dem Punkt hab ich die Erfahrung gemacht, dass es am besten ist es im Konstruktor zu machen. Dann können die Leute nichts anderes machen als es zu setzen.

Ich hatte bei einer meiner Anstellung einen Kollegen, der Klassen so ähnlich aufgebaut hatte (OK da gab es auch noch Design Probleme). Das war wirklich nicht schon die Klassen zu benutzen.
Man hat die Klasse Instantiiert, die Methode aufgerufen, die man verwenden wollte. Und beim Testen des eigenen Codes kam dann der Fehler, das ein Property nicht gesetzt ist. Also Property gesetzt, Compiler wieder an geschmissen und beim Testen den Fehler bekommen, das ein weiteres Property nicht gesetzt ist. Das Spiel hat man dann noch ein paar mal wiederholt, bis man genervt zum Kollegen gegangen ist und gefragt hat welche Propertys man denn alle setzen muss um die Methode der Klasse zu benutzen. Seine Standard Antwort war dann meistens erstmals, die Klasse wird ja auch von anderen Benutzt schau mal welche Propertys die gesetzte haben. Und hat diese dann auch einfach gesetzt. Compiler gestartet und eine Exception bekommen, weil ein Property nicht gesetzt war. Zurück zum Kollegen, der ist dann mit zum Arbeitsplatz gekommen und hat sich das Angeschaut. Dann kam dann meist so was wie:"Ach die Methode verwendest du, die benutzt ja noch keiner. Wenn du die Methode benutzen willst, musst du noch die Propertys XYZ, dafür brauchst du dann aber, diese hier nicht zu setzen. Ist doch ganz einfach." Nein, es war nicht einfach, es war einfach nur Frustrierend seine Klassen zu benutzen. Und das schlimmste war, er war für das Firmen interne Framework (Painwork ist da wohl der bessere Begriff) zuständig. Alle 20 .Net Entwickler der Firma mussten den seine Klassen benutzen und hatten die gleichen Probleme wie ich. Er war überigens auch nicht besonders Glücklich, weil die anderen "dummen" Entwickler andauernd bei ihm standen und Fragen hatten und er nicht mehr wirklich zum Arbeiten kam.
Neuer Beitrag 19.05.2017 10:31 E-Mail | Beiträge des Benutzers | zu Buddylist hinzufügen
witte
myCSharp.de-Mitglied

Dabei seit: 03.09.2010
Beiträge: 862


witte ist offline

Beitrag: beantworten | zitieren | editieren | melden/löschen       | Top

Zitat von Palin:
Um ehrlich zu sein für mich wirkt es auch ein wenig wie ein Workaround, denn ich so eigendlich nicht verwenden sollte.

... und für mich wie eine Demonstration von NIH anhand von Lazy<T>.
Neuer Beitrag 19.05.2017 12:11 E-Mail | Beiträge des Benutzers | zu Buddylist hinzufügen
LaTino LaTino ist männlich
myCSharp.de-Poweruser/ Experte

avatar-4122.png


Dabei seit: 03.04.2006
Beiträge: 2.993
Entwicklungsumgebung: Rider / VS2019 / VS Code
Herkunft: Thüringen

Themenstarter Thema begonnen von LaTino

LaTino ist offline

Beitrag: beantworten | zitieren | editieren | melden/löschen       | Top

Zitat von witte:
und für mich wie eine Demonstration von NIH anhand von Lazy<T>.

Yep, war tatsächlich eine Motivation. Allerdings kein NIH - benötigt für net 2.0/CF.

LaTino
Neuer Beitrag 19.05.2017 14:18 E-Mail | Beiträge des Benutzers | zu Buddylist hinzufügen
Baumstruktur | Brettstruktur       | Top 
myCSharp.de | Forum Der Startbeitrag ist älter als 3 Jahre.
Der letzte Beitrag ist älter als 3 Jahre.
Antwort erstellen


© Copyright 2003-2020 myCSharp.de-Team | Impressum | Datenschutz | Alle Rechte vorbehalten. | Dieses Portal verwendet zum korrekten Betrieb Cookies. 01.06.2020 15:16