Object Member<T> Klasse

[Gruß Thomas!]

Hallo allerseits . 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?)

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:

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.
.
EDIT :
.

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
  }
}

War eigentlich so gemeint.

 

[Cherry]

Also entweder verstehe ich deine Frage nicht, oder machst dir Gedanken um völlige Randthemen.

Oder andersrum: ich sehe nicht, was an deiner Klasse keinen Sinn machen sollte. Ich meine, genau für solche Fälle gibts doch Generics. Und deine Konstanten public zu machen sehe ich jetzt auch nicht so kritisch, das wird doch an unzählichen Stellen in der Java-API genauso praktiziert.

Cherry

 

[Lynxeye]

Datenkapselung

Getter und Setter sind nie generisch und gehören logisch ganz klar zu einer bestimmten Klasse. Wenn deine Klassen alle Attribute per Getter/Setter exportieren sind es Strukturen und erfüllen damit nicht die Kriterien der objektorientierten Programmierung.

Wenn du wirklich eine Menge Code durch generische Getter/Setter sparen kannst, hast du zu viele davon und solltest dir Gedanken über das Design deines Programms machen, nicht wie du Schreibaufwand sparen kannst.

 

[andr_gin]

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

Ich glaube du hast nicht ganz verstanden, warum es Access Modifier wie private und public gibt. Das Ganze hat den Sinn, dass du jemandem, der die Klasse nicht kennt klar macht, welche Variablen er direkt ändern kann und welche nicht.

1.) Dir selbst in der selben Methode den Zugriff zu entziehen macht absolut keinen Sinn. Wenn du in deiner Methode nicht auf eine Variable schreiben willst, dann tu es einfach nicht.

2.) Der Sinn an den Access Modifiern ist, dass dir der Compiler schon zur Laufzeit sagt, dass das, was du da machst, eventuell zu einem Absturz führen kann, weil Variablen direkt änderst, die dafür nicht vorgesehen sind und er blockiert das Ganze und du musst nicht erst zur Laufzeit feststellen, dass das so nicht funktioniert. Wenn du einfach eine Exception wirfst, dann stellst du das auch erst zur Laufzeit fest und wenn der Codeteil nicht regelmäßig durchlaufen wird, wirst du das gar nicht so leicht feststellen. Man sollte seinen Programmierstil so wählen, dass möglichst viele Fehler schon vom Compiler mitgeteilt bekommt.

 

[Gruß Thomas!]

Das war ja nur eine theoretische Überlegung und mir war schon irgendwie bischen klar dass das nicht so toll sein kann.

 

[Hannnibal]

Hallo,

ich finde es nicht dumm Daten "read-only" setzten zu können.
Siehe auch http://en.wikipedia.org/wiki/Immutable_object

Allerdings ist dein Objekt auch nicht wirklich gut geschützt, denn wenn du dir die Referenz mit get holst, können die Daten anschließen unbeabsichtigt verändert werden.

Gruß,

Hannnibal