Du verwendest einen veralteten Browser. Es ist möglich, dass diese oder andere Websites nicht korrekt angezeigt werden. Du solltest ein Upgrade durchführen oder ein alternativer Browser verwenden.
Hallo allerseits, seit langem mal wieder was von mir und gleich ne Frage
Was haltet ihr von dieser Klasse? Ich habe mir überlegt, ob es nicht gut wäre eine Klasse zu haben, die die Funktionalität von getter und setter Methode in sich vereinigt und trotzdem Accessrichtlinien zulässt. Ich weiß bloß nicht ob das viel Sinn macht und frage daher mal ob das passt (Normalerweise sind public Variablen ja Tabu, aber Ausnahmen?)
Java:
public class Member<T>
{
public static final byte MEMBER_WRITE = (0<<1);
private T obj;
private final byte fl;
public Member()
{
this.obj = null;
this.fl = 0;
}
public Member(byte fl)
{
this.obj = null;
this.fl = fl;
}
public Member(T obj)
{
this.obj = obj;
this.fl = 0;
}
public Member(T obj, byte fl)
{
this.obj = obj;
this.fl = fl;
}
public T get()
{
return obj;
}
public void set(T obj)
{
if((fl & ((1 << 0))) != 0)
{
this.obj = obj;
}
else
{
throw new RuntimeException("Member is ReadOnly");
}
}
}
Usage-Beispiel:
Java:
public class Foo
{
public final Member<String> hello = new Member<String>("hello"); //read-only Member
public final Member<String> hello2 = new Member<String>("hello2",MEMBER_WRITE); //read-write Member
public static void main(String args[])
{
Foo foo = new Foo();
System.out.println(foo.hello.get()); //read funktioniert
foo.hello.set(""); //Runtime Exception
System.out.println(foo.hello2.get()); //read funktioniert
foo.hello2.set(""); //write auch
}
}
Macht eine solche Klasse Sinn oder sind public Member generell Tabu? Weil ansich spart man sich somit bei vielen gettern und settern massig Code.
P.S.: Die flags sind absichtlich bytes weil ich noch nicht weiß was ich noch an Flags hinzufüge. Im Moment würde ja eine bool-Variable reichen.
Der sinn soll ja sein, dass du kontrollieren kannst, wer auf deine Member zugreift. UND vor allem auch die Möglichkeit hast nicht plausible Werte abzuweisen.
Wenn du das so machst, dann hast du nix damit gewonnen, da jeder jeden Wert einfügen kann. :bahnhof:
Außerdem wie willst du das Read verhindern in deiner Klasse?? Da müsstest du ReadWrite und ReadOnlyMember machen. Und dann hast du das Problem, dass die eigene Klasse das auch nicht kann -.-
Um das Problem zu beheben brauchst du die in C# möglichen Propteries.
Und noch eine Anmerkung: Stat einem 0/1 byte tuts auch ein boolean.
edit: Und er kontrolliert ja den Zugriff: Jeder kann lesen, aber ob man den Wert überschreiben kann wird bei der Erstellung des Objekts im Konstruktor bestimmt.
Ich hab schon geschrieben dass ich das weiß, aber vielleicht kommen noch ein paar Flags hinzu.
Und noch was: Die Klasse soll nicht die normale Art von Member ersetzen sondern nur Variablen, die auch nach außen hin benötigt werden verwalten.
UND vor allem auch die Möglichkeit hast nicht plausible Werte abzuweisen.
Das Ziel der Klasse soll es sein die Properties von C# in ähnlicher Weiße nachzubilden. Dass es im selben Stil geht habe ich ja nicht behauptet und dass die private Member ganz anders deklariert werden müssen ist auch klar.
Ein weiterer Nachteil dieser Art getter und setter zu schreiben ist zudem dass Fehler bei den Zugriffen erst zur Laufzeit erkannt werden können (anhand der RuntimeException).
Java:
public class Foo
{
public final Member<String> hello = new Member<String>("hello"); //read-only Member
public final Member<String> hello2 = new Member<String>("hello2",MEMBER_WRITE); //read-write Member
}
public class Bar
{
public static void main(String args[])
{
Foo foo = new Foo();
System.out.println(foo.hello.get()); //read funktioniert
foo.hello.set(""); //Runtime Exception
System.out.println(foo.hello2.get()); //read funktioniert
foo.hello2.set(""); //write auch
}
}
Das Ziel der Klasse soll es sein die Properties von C# in ähnlicher Weiße nachzubilden. Dass es im selben Stil geht habe ich ja nicht behauptet und dass die private Member ganz anders deklariert werden müssen ist auch klar.
Ein weiterer Nachteil dieser Art getter und setter zu schreiben ist zudem dass Fehler bei den Zugriffen erst zur Laufzeit erkannt werden können (anhand der RuntimeException).
Ist genau das, was ich sagen will. Du machst hier nix besser oder einfacher. Du shiftest das Problem in eine weitere Klasse.
Es bringt nicht einen Vorteil gegenüber dem deklarieren des Members in der Klasse.
OK während ich das hier schreibe fällt mir höchstens ein, dass es Code für getter und setter entfernt.. -.- Wenn es eine BeanKlasse ist, dann habe ich ehh diese generiert und die getter und setter werden so erzeugt. Außerdem müsste ich Validatoren injecten oder durch ableitung implementieren, was wieder zu massig Klassen führt.
