C# Getter + Setter, Public vs. Private: (Schwach)sinn?

[Rossibaer]

Bei der Implementierung von Interfaces muessen alle vom Interface deklarierten Methoden Public implementiert werden -> wenn nicht gibts nen Compilererror. Ausserdem dienen Interfaces dazu immer ein Minimum an Funktionalitaet bereitzustellen/sicherzustellen.

Sorry das ist falsch. Interface Methoden/Properties lassen sich in C# auch als Private implementieren und sind dann nur über das Interface selbst erreichbar bzw. aufrufbar. Was den Compilerfehler angeht, wenn du die Interface Member implizit implementierst, könnte es schon die Ursache für den Compilerfehler sein.

Mit einem Interface kannst du die Klasse auch nur "markieren" ohne direkt Member implementieren zu müssen. Dadurch wird jedoch keine Funktionalität implementiert! Das macht Sinn wenn du nur bestimmte Klassen-Objekte in den Funktionalitäten erlauben oder in Generic-Klassen nur auf bestimmte Klassen einschränken willst.

  public interface Test
  {
  }

  public class MyTest : Test
  {
  }

  public class MyTest2
  {
  }

  public class GenericTest<T> where T : Test
  {
  }

  GenericTest<MyTest> test1; // ok, weil markiert
  GenericTest<MyTest2> test2; // Compilerfehler, weil nicht markiert

 

[Darii]

Und ob das sinn macht , Properties wurden eingefuehrt damit man immer den gleichen Attributwert erhaelt, so soll auch innerhalb einer Klasse mit dem Property gearbeitet werden.

Darum ging es doch gar nicht. Es ging weder um den Sinn/Unsinn von private im Allgemeinen noch um den Sinn/Unsinn von Properties im Allgemeinen. Sondern es ging darum, dass es unsinnig ist, einen privaten Setter zu definieren, statt ihn ganz wegzulassen, wenn seine Benutzung keinen Sinn macht.

Bei der Implementierung von Interfaces muessen alle vom Interface deklarierten Methoden Public implementiert werden -> wenn nicht gibts nen Compilererror.

Gna. Das war ein Beispiel. HaGGi.13(und anscheinend auch deine) Vorgehensweise auf den Rest übertragen. Wie du richtig erkannt hast, macht das nämlich keinen Sinn.

Ausserdem dienen Interfaces dazu immer ein Minimum an Funktionalitaet bereitzustellen/sicherzustellen.

Was willst du mir damit sagen?

Was genau daran Irrefuehrend ist kann ich nicht nachvollziehen

Oh das ist ganz einfach, wenn einer setter existiert(wenn auch private) dann gehe ich davon aus, dass er auch benutzt werden kann/sollte. Aber das soll/kann er in diesem Fall nicht. Wie gesagt: private ist kein Marker für „nicht benötigt/funktioniert nicht“. Derjenige der nach dir auf den Code schaut, wird vielleicht den privaten Setter benutzen weil er existiert.

 

[olampl]

Sondern es ging darum, dass es unsinnig ist, einen privaten Setter zu definieren, statt ihn ganz wegzulassen, wenn seine Benutzung keinen Sinn macht.

Oh das ist ganz einfach, wenn einer setter existiert(wenn auch private) dann gehe ich davon aus, dass er auch benutzt werden kann/sollte. Aber das soll/kann er in diesem Fall nicht. Wie gesagt: private ist kein Marker für „nicht benötigt/funktioniert nicht“. Derjenige der nach dir auf den Code schaut, wird vielleicht den privaten Setter benutzen weil er existiert.

Wie ich schon sagte es ist beides moeglich, fuer den Benutzer der Klasse macht es keinen unterschied ob der Setter nun Private ist oder geloescht wurde...

Natuerlich ist private kein Marker fuer "funktioniert nicht", dennoch ist es aus meiner sicht sauberer ihn als private zu markieren als ihn einfach zu loeschen/wegzulassen.

Und selbstverstaendlich kannst Du einen als Private deklarierten Setter innerhalb deiner Klasse auch verwenden, was spricht dagegen?


Wegen der Interfaces, klar macht es keinen Sinn alle (moeglichen, auffindbaren) interfaces explizit zu Implementieren, dennoch kann es sinnvoll sein, manche Methoden/events... dem benutzer nicht zur verfuegung zu stellen und einzelen Interfaceimplementierungen eben explizit zu machen, aber loeschen kannst du sie nicht -> sonst error

Sorry das ist falsch. Interface Methoden/Properties lassen sich in C# auch als Private implementieren und sind dann nur über das Interface selbst erreichbar bzw. aufrufbar. Was den Compilerfehler angeht, wenn du die Interface Member implizit implementierst, könnte es schon die Ursache für den Compilerfehler sein.

Nun ja, falsch ist es, weil ich das wort Public verwendet habe und nicht in zusammenhang mit dem wort Implizit, mea culpa
Bisher habe ich Interfaces entweder Explizit (das meintest du wohl) oder Implizit (davon sprach ich) verwendet..., (abgesehn davon wir das aus deinem beispiel auch nicht klar.)
aber Implementiert werden muss jede Methode, Property, Indexers und Event des Interface, das ist meine Kernaussage.

 

[Grantig]

es wirkt irgendwie falsch auf mich weil praktisch alles "doppelt" dasteht.

Dass "alles doppelt dasteht" kannst du auch vermeiden indem du Auto-Implemented Properties benutzt.
Man muss nur beachten, dass Auto-Implemented Properties immer Setter und Getter definieren müssen.

Das sieht dann so aus:

public class Test
{
    #region Properties

    public string StandardProp
    { get; set; }

    public string ReadOnlyProp
    { get; private set; }

    public string WriteOnlyProp
    { private get; set; }

    #endregion


    public Test(string prop1, string prop2, string prop3)
    {
        StandardProp = prop1;
        ReadOnlyProp = prop2;
        WriteOnlyProp = prop3;
    }
}

 

[Gobble-G]

Und selbstverstaendlich kannst Du einen als Private deklarierten Setter innerhalb deiner Klasse auch verwenden, was spricht dagegen?

...dass es im Fall eines leeren Setters keinen Sinn macht, sondern irreführend ist. Daher fliegt der Setter in dem Fall raus. Hier ein beliebiges Beispiel aus der MSDN.

 

[HaGGi.13]

Ohhh... je... was hier abgeht nur weil ich einen "Schussel" Fehler gemacht habe...

Klar macht es meinem Beispiel oben keinen Sinn! Sorry, mein Fehler. (Ich habe das gerade erst so richtig mit bekommen.)

Denn der Getter gibt ja "a + b" zurück und somit ist es unsinn sort einen private Setter für Sum zu deklarieren. Ein Privater Setter macht da sinn, wenn nur a gewesen wäre oder nur b, denn dann hätte man die Möglichkeit geben können/müssen (wie es halt jeder beliebt) ihn (den Setter) nur in der Klasse sichtbar zu machen, sprich privat. Dann könnte a auch von der Klasse heraus gesetzt werden und das nur aus der Klasse.
Ich hoffe man kann meinen Gedanken Gängen folgen... (^_^)

 

[Gobble-G]

Es macht in keinem Fall Sinn, einen leeren Setter zu schreiben, egal was du in deinen Getter einbaust. Aber genau das hast du generalisiert behauptet:

Na ja, es gehört zum guten Stil den Setter mit zu setzen, auch wenn er leer wäre...

Wo ist da der Schusselfehler?

Desweiteren:

Ein Privater Setter macht da sinn, wenn nur a gewesen wäre oder nur b, denn dann hätte man die Möglichkeit geben können/müssen...

Das ist natürlich auch Quatsch. Getter und Setter müssen nichts miteinander zu tun haben. Es ist sehr wohl üblich, im Getter (z.B.) a+b zurückzugeben und im Setter c zu setzen. Was damit intern passiert, ist eine ganz andere Geschichte.

 

[olampl]

...dass es im Fall eines leeren Setters keinen Sinn macht, sondern irreführend ist. Daher fliegt der Setter in dem Fall raus. Hier ein beliebiges Beispiel aus der MSDN.

Hier ein beliebiges Beispiel aus der MSDN , mit private Setter

Wie ich schon sagte,wenn es Dich verwirrt loesch einfach den Setter in deinem code, es sind beide Varianten gueltig und machen sinn. (z.b. kann der Setter sehr einfach auf protected geaendert werden.)

Ich bin einfach faul und setze ihn private, eben fuer den Fall das ich ihn doch noch brauche.
Fuer den benutzer macht es keinen unterschied und der Entwickler hat in der Regel kein problem danmit, alles eine stilfrage/ansichtssache und es ist muesig daruber zu diskutieren.

lg

oli

EDIT: Falsches wort korrigiert

 

[Rossibaer]

So langsam wird der Thread wirklich interessant, so viele Meinungen und reger Gedankenaustausch, vorallem in so früher Stunde ... Gehen einige hier auch noch mal schlafen?

Nun ja, falsch ist es, weil ich das wort Public verwendet habe und nicht in zusammenhang mit dem wort Implizit, mea culpa
Bisher habe ich Interfaces entweder Explizit (das meintest du wohl) oder Implizit (davon sprach ich) verwendet..., (abgesehn davon wir das aus deinem beispiel auch nicht klar.)
aber Implementiert werden muss jede Methode, Property, Indexers und Event des Interface, das ist meine Kernaussage.

Sorry, manchmal lese ich das was da steht und nicht das was gemeint war

Das Interface kannst du auch ohne jegliche Implementierungsvorschrift bzgl. Methoden, Eigenschaften und Ereignissen anwenden. Wie gesagt, ist es dann nur ein Marker um z.B. Klassen filtern zu können. Mein Beispiel war auf das absolute Minimum runter gebrochen. Ich wollte halt nur mal zeigen, dass Interfaces auch leer sein können. Ein konkretes Beispiel für diese "Technik" wäre, wenn du einen Form-Designer ähnlich dem Visual Studio schreibst, aber dann nur spezielle Control Klassen zu lassen möchtest. Genauso kannst du auch, wie in meinem Beispiel, eine generische Klasse auf bestimmte Klassen begrenzen. Jeder Versuch dann die generische Klasse mit einem anderen Typen zu typisieren schlägt schon beim Compilieren fehl. Hoffe das war jetzt etwas verständlicher.

 

[Darii]

Wie ich schon sagte es ist beides moeglich, fuer den Benutzer der Klasse macht es keinen unterschied ob der Setter nun Private ist oder geloescht wurde...

Der Benutzer der Klasse ist auch der, der die Klasse selbst irgendwann mal wieder anfassen muss. Im Zweifelsfall *du*. Und dann musstest du dir merken, dass es keinen Sinn hat diesen Setter zu benutzen.

Natuerlich ist private kein Marker fuer "funktioniert nicht", dennoch ist es aus meiner sicht sauberer ihn als private zu markieren als ihn einfach zu loeschen/wegzulassen.

Nein. Es ist nie sauber Code zu schreiben, der völlig überflüssig ist und zudem noch etwas anderes tut als man denkt.

Und selbstverstaendlich kannst Du einen als Private deklarierten Setter innerhalb deiner Klasse auch verwenden, was spricht dagegen?

Weil er in diesem Fall keinen Sinn macht??? Er setzt eine Eigenschaft, die du nie benutzen wirst. Viel schlimmer noch. Der Setter hat niemals Einfluss darauf, was der Getter ausgibt. Er ist ein Setter für etwas völlig anderes.

Hier ein beliebiges Beispiel aus der MSDN , mit private Setter

Das ist etwas *völlig* anderes. Dieser Setter macht ja auch Sinn. Liest du eigentlich was ich schreibe? Es geht *nicht* um setter im Allgemeinen, sondern um einen *speziellen* Fall.

 

[olampl]

Der Benutzer der Klasse ist auch der, der die Klasse selbst irgendwann mal wieder anfassen muss.Im Zweifelsfall *du*.

Der Benutzer der Klasse ist derjenige der meine Klasse/dll/exe anprogrammiert.

Ich bin nicht der Benutzer sondern der Entwickler.

Im Zweifelsfall *du*. Und dann musstest du dir merken, dass es keinen Sinn hat diesen Setter zu benutzen.

Naja, benutzen kann ich ein private set sowieso nur intern, was ich in der Regel nicht machen werde, jedoch machen kann. Und merken muss ich es mir auch nur bedingt, weil ich meinen code kommentiere. (Solltest Du auch machen )

Nein. Es ist nie sauber Code zu schreiben, der völlig überflüssig ist und zudem noch etwas anderes tut als man denkt.

Warum tut ein als private gesetztes set was anderes?
Wenn du ihn weglaesst, ist er ohnehin private, nur fuegt es dann halt der compliler hinzu.

Weil er in diesem Fall keinen Sinn macht??? Er setzt eine Eigenschaft, die du nie benutzen wirst. Viel schlimmer noch. Der Setter hat niemals Einfluss darauf, was der Getter ausgibt. Er ist ein Setter für etwas völlig anderes.

Welche Wert setzt er den, die des Attributs fuer dass das Property erstellt wurde! Du kannst ihn ohnehin nur intern verwenden, wie schon gesagt du kannst set verwenden musst aber nicht.

Der Setter hat niemals Einfluss darauf, was der Getter ausgibt. Er ist ein Setter für etwas völlig anderes.

Das wuerde ich so nicht unterschreiben, immerhin kann auch im Set schon das value manipuliert werden, das get spaeter wieder zurueckliefert.

Das ist etwas *völlig* anderes. Dieser Setter macht ja auch Sinn. Liest du eigentlich was ich schreibe? Es geht *nicht* um setter im Allgemeinen, sondern um einen *speziellen* Fall.

Schau hier haben wir die Wurzel allen Uebels,[Ironie] wenn Du natuerlich den einen speziellen Fall meinst, ist es natuerlich unsinn. [/Ironie]

Es gibt in meinen Augen auch keinen speziellen fall warum das nicht moeglich sein sollte, ich halte es fuer allgemeingueltig.
Es ist einfach egal, wenn Du eine andere Meinung nicht gelten lassen willst/kannst ok, jedoch ist Deine auch nicht der Weisheit letzter schluss.

 

[HaGGi.13]

Es macht in keinem Fall Sinn, einen leeren Setter zu schreiben, egal was du in deinen Getter einbaust. Aber genau das hast du generalisiert behauptet:

Wo ist da der Schusselfehler?

Desweiteren:

Das ist natürlich auch Quatsch. Getter und Setter müssen nichts miteinander zu tun haben. Es ist sehr wohl üblich, im Getter (z.B.) a+b zurückzugeben und im Setter c zu setzen. Was damit intern passiert, ist eine ganz andere Geschichte.

Es ist in sofern ein Fehler von mir gewesen, weil ich etwas anderes meinte als ich geschrieben hatte... Sorry. Ich habe das ganze Spiel hier versucht auf etwas allgm. zu beziehen und nicht expliziet auf dieses Beispiel des Eröffners.
Sprich, das Beispiel von olampl in der MSDN.

Das heißt, ich habe irgendwie hier vorbei geredet zumal ich noch ein schlechtes Beispiel dazu gegeben habe, wo es nun nicht darfür zutrifft, bzw. schlecht zutrifft. Und ich habe nun auch nicht umbedingt vorausgesetzt, dass der Getter immer etwas mit dem Setter zu tun haben muss... so sollte es auch nicht rüber kommen...

 

[Gobble-G]

Hier ein beliebiges Beispiel aus der MSDN , mit private Setter

Wie Darii schon schrieb, verfehlt das das Thema, da in deinem Beispiel der Setter nicht leer ist, sondern der Wert direkt am Property gespeichert wird. Dieser Wert ist sogar direkt wieder abrufbar, was im Falle eines leeren Setters nicht möglich ist.
Blätter nochmal zurück und lies! Dann siehst du, dass vom *Spezialfall* des leeren Setters der Form

public string Property
{
    get { return "abc"; }
    private set { }
}

gesprochen wurde.

Schönen Tag!

 

[Housechen]

Hier ein beliebiges Beispiel aus der MSDN , mit private Setter

Jo, dass nutze ich auch, nur klappt das nicht so wirklich, wenn ich im Setter dann validieren will (Stackoverflowexception, ruft sich ja selbst immer wieder auf dadurch).

 

[HaGGi.13]

...poste mal bitte deinen Code.

 

[Darii]

Schau hier haben wir die Wurzel allen Uebels,[Ironie] wenn Du natuerlich den einen speziellen Fall meinst, ist es natuerlich unsinn. [/Ironie]

Ich meinen nicht einen speziellen Fall, sondern den speziellen Fall, von dem ich die ganze Zeit rede und mit dem diese Diskussion auch angefangen hat.

Es gibt in meinen Augen auch keinen speziellen fall warum das nicht moeglich sein sollte, ich halte es fuer allgemeingueltig.

<ironie>Wenn du nicht hinguckst(liest), dann wundert mich das nicht, dass da nix in deinen Augen ist.</ironie>

Es ist einfach egal, wenn Du eine andere Meinung nicht gelten lassen willst/kannst ok, jedoch ist Deine auch nicht der Weisheit letzter schluss.

Das Problem ist nicht, dass du eine andere Meinung hast, das Problem ist, dass du anscheinend nicht verstehst worum es mir geht. Deswegen redest du die ganze Zeit von etwas völlig anderem als ich, ich hab jetzt schon zweimal versucht dir zu erklären, dass wir aneinander vorbeireden. Wenn du das jetzt immer noch nicht einsiehst, und du weiterhin denkst, ich würde deine Meinung nicht gelten lassen, dann klinke ich mich hier aus. Für hoffnungslose Fälle ist mir meine Zeit zu schade.

Zumindest HaGGi.13 hat inzwischen verstanden, was ich meine, also kann es nicht daran liegen, dass ich mich völlig unverständlich ausdrücke.

 

[HaGGi.13]

[...]
Zumindest HaGGi.13 hat inzwischen verstanden, was ich meine, also kann es nicht daran liegen, dass ich mich völlig unverständlich ausdrücke.

Hey, was solln das heißen!?