Java - Klassenstruktur - Readable - ReadWritable

[bubble]

class ProjectConfig {

String owner = "unknown";
     Managers managers = new Managers();
}

class Managers {
     String classLoaderManager = "ds.managers.ClassLoaderManager";
     String classManager = "ds.managers.ClassManager";
     String instanceManager = "ds.managers.InstanceManager";
}

>   
> Bist du sicher, dass die Klasse "Managers" statt "Manager" heißen soll? Ich bin leider nicht so sehr in diesem Thema drin, aber so wie du diese Strings speicherst, klingeln bei mir die Alarmglocken.  

So wie oben zusehen, sind die zugewiesenen Strings eigentlich nur die Standard-Einstellungen, quasi würde das Programm erst ProjectConfig instantiieren, dann die eigentliche Projektkonfiguration aus einer Datei lesen und entsprechende Veränderungen in der ProjectConfig-Instanz überschreiben.  
(Und zu dem Managers/Manager-Namen: Ich hab 3 verschiedene Manager-Typen, einer kümmert sich halt um das erzeugen der Instanzen der Plugins, einen der sich darum kümmert welche Klassen noch geladen sein sollten und einen der sich bei noch nicht geladenen Klassen darum kümmert, den entsprechenden ClassLoader zu beschaffen. Über die Konfiguration soll es dann halt möglich sein, verschiedene Manager zu benutzen, bei der "Standardvariante" können die Plugins zur Laufzeit nicht ersetzt werden, so dass man immer das ganze Programm neustarten müsste um zb. eine neue Version eines Plugins zu installieren, eine andere Variante der Manager merkt sich welche Instanz, eine Referenz auf andere Instanzen hat und somit wäre es möglich zur Laufzeit einfach nur diese Instanzen kurz "herunter zu fahren", die neue Plugin-Version einzuspielen und die neuen Plugins wieder zu starten.)  
  

> > Das ganze ist ja mehr oder weniger eine Baumstruktur.  
>   
> Sehe das ähnlich wie Bernhard, sofern du nicht noch soetwas wie ds.foo.bar zusätzlich zu den ds.managers.sonstwas Einträgen hast, sieht es eher nach einer Liste aus. (Naja, andererseits kann man einen Baum mit einer Tiefe von 1 ggf. auch als Liste sehen...)  
>   
> > Nun hätte ich es gerne so, dass ich aus dieser Basis heraus 2 verschiedene Klassentypen hätte:  
> > Einmal nur lesbar und einmal les- und schreibbar.  
>   
> Was genau wird mit diesen Strings wie "ds.managers.ClassLoaderManager" passieren? Werden diese Klassen/Pakete irgendwie importiert oder so?  

Das geht glaube ich aus obigem hervor.  
  

> > Eine Variante wäre alle Member protected zu machen, ProjectConfig und Managers mit Getter-Funktionen auszustatten und daraus dann je eine Klasse mit Setter-Funktionen abzuleiten.  
> > Nun find ich das allerdings eine recht umständliche Lösung. Ich hätte es lieber so, dass ich nur eine schreib- und lesefähige "Hauptklasse" kreieren müsste und beliebig viele nur lesefähige Klassen bauen könnte.  
>   
> Also ich würde jetzt aus dem Bauch heraus eher vorschlagen, dass du ein Interface "ConfigReadable" erstellst, in dem du die nötigen getter definierst. Daneben würde ich dann ein weiteres Interface "ConfigWritable" erstellen, was "Configreadable" implementiert und um Methoden zum Ändern der Daten definiert. Aber sauber erscheint mir das auch nicht...  
>   
> > Ich könnte das ganze über ein Worterbuch a la List<String, Object> lösen, nachteil dabei ist aber, dass dann keine Vervollständigung per IDE möglich ist und im Endeffekt werden das um die 100 Schlüssel.  
> Wieso ist dann keine Vervollständigung möglich? Und warum das Object? Object sollte man möglichst vermeiden, wenn es nicht anders geht.  

Hier meinte ich die Autovervollständigung der IDEs. Bei `(new ProjectConfig()).getManagers().getInstanceManager()`{:.language-java} kann man halt die Autovervollständigung der IDEs verwenden. Bei einer Liste aber `(new CfgListe()).get("managers.instancemanager");`{:.language-java} würde das nicht mehr funktionieren.  
  

> > Einfach interfaces mit Getter- bzw. Setter-Funktionen und die Klasse implementiert beide kommt nicht in Frage, da ein simples "umcasten" möglich ist. (Über Reflexion geht es zwar generell, aber das sollte außen vor bleiben)  
  

> Umcasten ist das allerletzte was man tun sollte und zwar dann, wenn man die Grenzen von Java gerät. Vielleicht braucht man ja gar keine Reflection, aber dafür solltest du genauer erklären, was du da tun willst.  
  
Was ich quasi suche ist etwas mit dem ich hinterher nur eine Klasse hab aus der heraus ich die Setter "deaktivieren" könnte a la:  
~~~java
ProjectConfig cfg = new ReadOnly(new ProjectConfig());  
cfg.getOnwer();  
cfg.setOnwer("bla"); // wirft UnsupportedOperationException  
cfg.getManagers().setInstanceManager(); // wirft UnsupportedOperationException  
cfg.getManagers().getInstanceManager();  

MfG
bubble