Datenmodell aus ArrayListen ?

[Guest]

Hi,

ich überlege ob folgendes Datenmodell sinnvoll ist:

public class Mitglieder {
	private ArrayList<Person> personen = new ArrayList<Person>();
	int mitgliedsID;
}

public class Person{
	private ArrayList<BankDaten> bankdaten= new ArrayList<BankDaten>();
	String name, vorname;
	public ArrayList<BankDaten> getBankdaten() {
		return bankdaten;
	}
}

public class BankDaten{
	String bankname;
	int kontonr;
	int blz;	
}

In Mitglieder werden Personen gespeichert. Jede Person kann eine oder mehrere BankDaten haben.
Ein solches Datenmodell lässt sich relativ einfach bauen, jedoch hat es seine Nachteile (wie ich gerade feststellen muss :-/).
Man kann nicht direkt über einen Index auf bestimmte Werte zugreifen sondern muss jedesmal suchen:
Will man beispielsweise die BankDaten von Person "Mustermann", dann muss man eine solche Verrenkung machen:

	public ArrayList<BankDaten> getBankDaten(String name){
		
		ArrayList<BankDaten> daten = null;
		for(int i=0;i<personen.size();i++){
			if(personen.get(i).name.equals(name)){
				daten = personen.get(i).getBankdaten();
			}
		}
		return daten;
	}

Aber was soll ich sonst nehmen anstatt ArrayListen? Oder mache ich einen ganz grundsätzlichen Fehler?

 

[HLX]

Du könntest eine HashMap verwenden. Schlüssel ist die Person, als Wert hinterlegst du die ArrayList mit dessen Bankdaten.

Edit: bei Verwendung eines eigenen Objekttyps als Schlüssel musst du dessen equals- und hashCode-Methode überschreiben

 

[KSG9|sebastian]

Aber sehr schön ist sowas halt auch nicht.
Auserdem musst du ja auch den normalen Use-Case bedenken:

1. Alle Personen anzeigen
2. Eine Person auswählen
3. Zu der ausgewählten Person die Bankdaten anzeigen

Hier hast du die Person eh schon an der Hand, somit fällt das suchen flach.

Fall 2:

1. Eine Person suchen anhand einer PersonenNummer, Name, Adresse u.s.w.
2. Zur gefundenen Person die Bankdaten anzeigen

In dem Fall bringt dir eine Map nichts, weil man nicht nur nach dem Namen suchen kann.
Als nächstes kannst du den Namen nicht als Schlüssel in der Map verwenden, da es sicher einen Hans Meier auch 3x geben kann.
Somit müsstest du z.B. eine Personennummer verwenden. Aber das hilft dir dann auch nicht weiter da über die Personennummer eher selten gesucht wird.
Performancetechnisch bringt dir der Weg über die Map auch nix.

Somit ne Liste oder ein Set verwenden und eben über die entsprechenden Elemente drüberlaufen.

Gruß Sebastian

 

[Guest]

Performancetechnisch bringt dir der Weg über die Map auch nix.

Performance spielt erstmal eine untergeordnete Rolle.

Somit ne Liste oder ein Set verwenden und eben über die entsprechenden Elemente drüberlaufen.

Also ist mein Weg über die ArrayListen schon gut so? Dachte es gäbe da vielleicht etwas Besseres, denn schön ist das mit dem ewigen Durchsuchen der Listen ja nicht gerade...

 

[Marco13]

Wenn es um solche Modellierungsfragen geht, noch eine Nebenbemerkung:

public ArrayList<BankDaten> getBankdaten() 
{
      return bankdaten;
}

Das ist ziemlich "gefährlich" (also, in mancher Hinsicht unschön). Man legt sich dort auf eine Implementierung fest. Es sollte besser

public List<BankDaten> getBankdaten() 
{
      return bankdaten;
}

heißen. Aber das ist immernoch suboptimal: Man gestattet ziemlich fiesen Zugriff auf die Bankdaten. Jeder Idiot kann dort Änderungen machen:

class Betrüger extends Person
{
    void betrüge(Person person)
    {  
        List<Bankdaten> geklaut = person.getBankdaten();
        this.bankdaten.addAll(geklaut);
        person.getBankdaten().removeAll(); // Weg sind sie...
    }
}

(Schönes Beispiel, gell? :wink: )

"Sicherer" wäre sowas wie

class Person
{

    public int getAnzahlBankdaten() { return bankdaten.size(); }
    public Bankdaten getBankdaten(int index) { return bankdaten.get(index); }

    // Wenn's sein muss - aber nur zur Vedeutlichung, "sicher" ist sowas natürlich nicht:
    private String passwort = "Hallo";
    public Bankdaten removeBankdaten(int index, String passwort) 
    { 
         if (!this.passwort.equals(passwort))
         {
             System.out.println("F*** dich!");
             return;
         }
         bankdaten.remove(index); 
    }
}

 

[Gast]

Hi Marco,

das Beispiel hab ich nur erfunden um mein Problem (ArrayList in ArrayList) zu verdeutlichen. Ich selbst arbeite mit unkritischen Daten.

Dennoch bleibt die Frage ob das nicht besser geht. Dieses ewige Durchsuchen der Listen kann ja nicht das Gelbe vom Ei sein. Oder würdet ihr das auch mit (Array)Listen modellieren?

 

[Marco13]

Ja, eine Map<String, Person> nameZuPerson wäre doch in Ordnung!? Was spricht denn dagegen? (Davon ausgehend, dass Personen IMMER unterschiedliche Namen haben (aber wenn das nicht der Fall ist, kommt auch bei der aktuellen Methode was beliebiges raus)).

 

[KSG9|sebastian]

Das wird eben so modelliert. Und ich versteh dein Problem immernoch nicht. Warum "ewiges gesuche"?

Meist gehst du doch nur eine Ebene tiefer im Datenmodel, somit ist es max. eine Suchoperation.

- von allen Mitgliedern geht man auf eine Person
- von dieser einen Person geht man auf ein Bankkonto

Im ersten Schritt musst du 1x suchen (nämlich nach ner Person anhand von irgendwelchen Attributen).
Im zweiten Schritt werden z.B. alle Bankkonten angezeigt und der User wählt eines aus. Somit entfällt hier das "suchen im Code".

Wenn du natürlich solche Methoden wie

public void abheben(int personenNr, int kontoNr, double betrag){

}

machen willst musst du natürlich suchen. Allerdings machen solche Methoden in den allermeisten fällen keinen Sinn, siehe auch Coupling und Cohesion.

Es ist auch nicht Sinn der Sache das die Klasse Mitglieder weiß wie ein Bankkonto aussieht oder wie es Geld an einem Bankkonto abbuchen kann. Diese Logik gehört in den Controller, du baust das in die Modelklassen. Das ist schlechtes Anwendungsdesign.

 

[KSG9|sebastian]

Ja, eine Map<String, Person> nameZuPerson wäre doch in Ordnung!? Was spricht denn dagegen? (Davon ausgehend, dass Personen IMMER unterschiedliche Namen haben (aber wenn das nicht der Fall ist, kommt auch bei der aktuellen Methode was beliebiges raus)).

In ner Anwendung in der 10 Personen gepflegt werden mag das ja noch funktionieren. Aber auch nur dann wenn eine Person NUR über den Namen identifiziert wird. Nächster Nachteil: Sobald du eine Person suchen willst (also sowas wie *Müller) musst du über das keySet() laufen und vergleichen. Das ist Performancetechnisch so ziemlich das langsamste was man mit ner Map anstellen kann.


** Edit **
Nebenbei ist es der anerkannte Weg sowas über Collections oder Sets abzubilden. Und wenn du das ganze mal ausprogrammierst dann wirst du merken dass ne Map mehr Nach- als Vorteile bringt. Alleine die Persistierung von solchen Objekten wird schon fast zum Genickbruch führen.

 

[Guest]

Wenn du natürlich solche Methoden wie

public void abheben(int personenNr, int kontoNr, double betrag){

}

machen willst musst du natürlich suchen. Allerdings machen solche Methoden in den allermeisten fällen keinen Sinn, siehe auch Coupling und Cohesion.

Es ist auch nicht Sinn der Sache das die Klasse Mitglieder weiß wie ein Bankkonto aussieht oder wie es Geld an einem Bankkonto abbuchen kann.

Ja ich würde gerne auch solche Abfragen machen wie z.B. "Welche Kunden sind bei Bank X"..

Diese Logik gehört in den Controller, du baust das in die Modelklassen. Das ist schlechtes Anwendungsdesign.

Wie würde denn ein solcher Controller für die Modellklassen aussehen?

Nebenbei ist es der anerkannte Weg sowas über Collections oder Sets abzubilden. Und wenn du das ganze mal ausprogrammierst dann wirst du merken dass ne Map mehr Nach- als Vorteile bringt. Alleine die Persistierung von solchen Objekten wird schon fast zum Genickbruch führen.

Hast vielleicht dazu ein simples Beispiel, da ich momentan nicht weiß, wie du das mit Collections abbilden willst bzw. welchen Vorteil das hat.

 

[HLX]

Diese Logik gehört in den Controller, du baust das in die Modelklassen. Das ist schlechtes Anwendungsdesign.

Dem muss ich widersprechen. Diese Logik ist Anwendungslogik und somit dem Model zuzuordnen. Der Controller dient lediglich der Anwendungssteuerung und darf Logik-Operationen anstoßen und dessen Ergebnis verarbeiten bzw. die Fehlerbehandlung durchführen. Das liegt u.a. daran, dass sich der Controller aufgrund der GUI-Steuerung i.d.R. schlecht von einer GUI-Technologie trennen lässt und somit nicht für andere grafische Oberflächen wiederverwendbar ist. Wiederverwendbare Logik gehört somit ins Backend --> Model.

Deiner übrigen Ausführung (auch hinsichtlich meines Vorschlages s.o.) stimme ich zu.

 

[KSG9|sebastian]

Diese Logik gehört in den Controller, du baust das in die Modelklassen. Das ist schlechtes Anwendungsdesign.

Dem muss ich widersprechen. Diese Logik ist Anwendungslogik und somit dem Model zuzuordnen. Der Controller dient lediglich der Anwendungssteuerung und darf Logik-Operationen anstoßen und dessen Ergebnis verarbeiten bzw. die Fehlerbehandlung durchführen. Das liegt u.a. daran, dass sich der Controller aufgrund der GUI-Steuerung i.d.R. schlecht von einer GUI-Technologie trennen lässt und somit nicht für andere grafische Oberflächen wiederverwendbar ist. Wiederverwendbare Logik gehört somit ins Backend --> Model.

Deiner übrigen Ausführung (auch hinsichtlich meines Vorschlages s.o.) stimme ich zu.

Ich hab mich etwas schlecht ausgedrückt. Die Logik um durch die verschiedenen Ebenen zu navigieren gehört natürlich ins Model.

Aber eine Methode getUmsatz(String bankName, String personenName, int kontonr) gehört nicht in die Klasse Bank oder sonstwohin. Sowas sollte man wenn überhaupt in eine andere Klasse auslagern.

Was für ein simples Beispiel hättest du denn gerne?

class PersonenVerwaltung{
  private List<Person> personen;

  public Person getPerson(int pNr){
     Person p = null;
     for(Person pers : personen){
        if(pers.getPersonenNummer() == pNr){
           p = pers;
           break;
        }
     }
     return p;
  }

  // entsprechende addPerson, deletePerson ... Methoden
}

class Person{
   private List<Adresse> adresse;
   
   // hier auch wieder entsprechende addAdresse, getAdresse u.s.w. Methoden
}

Das ist genauso sehr oder wenig umständlich wie mit Maps zu arbeiten. Nur dass du bei Maps recht schnell Workarounds verwenden muss und wenn es blöd läuft die komplette Logik neu machen musst.

Die Logik um eine Person zu suchen wird meist auf Server-Seite anhand der Persistenzschicht abgebildet.
Es macht wenig Sinn 15000 Personen zu laden wenn nur 3 benötigt werden. Deshalb die Suche über die Persistenzschicht und die Ergebnisse zurückgeben.
Eine findXYZ-Methode macht da meist wenig Sinn.

 

[Gast]

Danke für das Beispiel!

Nach meinem Wissen liegt die Persistenzschicht zwischen den Daten und der Anwedungslogik. Was du hier aber genau mit Persistenzschicht meinst verstehe ich nicht ganz.

Eine Datenbank wird für die Anwendung nicht eingesetzt, da die Anzahl der Daten überschaubar ist. Dennoch möchte ich gerne beliebige Abfragen auf den Daten durchführen. Beispiel:
Welche Personen wohnen in der Stadt XY?

Meinst du mit Persistenzschicht, dass ich ein Datenmodell wie das in deinem Beispiel verwende und dann eine zusäztliche Schicht/Klasse baue, die eben solche Methoden, wie getPersonenInStadt(String stadt) anbietet und die entsprechenden Methoden implementiert. Also dass solche, mehrere Klassen betreffenden Methoden nicht in der Klasse PersonenVerwaltung definiert sein sollten?

 

[KSG9|sebastian]

Persistenzschicht ist der Teil welcher dein Datenmodel in irgendeiner Form speichert (meist in einer Datenbank oder auch in XML-Dateien).

Wie werden die Daten bei dir gespeichert? Gar nicht? Falls ja musst du eben im Datenmodel suchen.

Du kannst dir die benötigten Sucher-Methoden auslagern, z.B. so um eine Person in einer Stadt zu finden.

public class SearchUtils{
   public List<Person> findPersonInTown(int plz, List<Person> persons){
      List<Person> results = new ArrayList<Person>();
      for(Person person : persons){
          for(Adresse addy : person.getAdresse()){
             if(addy.getPlz() == plz){
                 results.add(person);
             }
          }
      }
   }
   return results;
}

 

[Gast]

Hi,

nein die Daten werden nicht gespeichert. Sie werden einmal aus einer XML Datei eingelesen und in ein -- noch nicht vorhandenes -- Datenmodell überführt.

Wenn ich jetzt aber deine Klasse PersonenVerwaltung und die dazugehörige Klasse SearchUtils ansehe, dann ist der Unterschied zu meinem ersten Modell doch gar nicht so groß, außer, dass du in den jeweiligen Klasse nur die die Klasse betreffenden Methoden hast und dann eine extra Klasse die darauf komplexere Methoden ausführt. Oder übersehe ich da was?
Damit du mich richtig verstehst: Ich würde das Datenmodell gerne von Anfang an richtig designen um spätere Überaschungen zu vermeiden. Ist der Weg, den du da beschreibst, also ein anerkannter Weg das zu lösen?

 

[maki]

Ich hör immer nur "Datenmodell"... die 80'er/90'er sind doch längst vorbei und hier handelt es sich nicht um eine ER Tapete, sollte eigentlich ein Domänenmodell sein.

Das mit der Persistenzschicht ist schon richtig, solltest du auf jedenfall hinter Interfaces kapseln, so dass du zum Schluss die SearchUtils nicht mehr zB. aus der GUI aufrufst, sondern eine Klasse hast, die sich darum kümmert.

 

[KSG9|sebastian]

Hi,
Damit du mich richtig verstehst: Ich würde das Datenmodell gerne von Anfang an richtig designen um spätere Überaschungen zu vermeiden. Ist der Weg, den du da beschreibst, also ein anerkannter Weg das zu lösen?

Ja, das wäre ein korrekter Weg es zu lösen.

 

[Guest]

Hi,
Damit du mich richtig verstehst: Ich würde das Datenmodell gerne von Anfang an richtig designen um spätere Überaschungen zu vermeiden. Ist der Weg, den du da beschreibst, also ein anerkannter Weg das zu lösen?

Ja, das wäre ein korrekter Weg es zu lösen.

Ok, dann werd ich das jetzt so versuchen. Vielen Dank nochmal für deine Hilfe!

Das mit der Persistenzschicht ist schon richtig, solltest du auf jedenfall hinter Interfaces kapseln

Wie meinst du das genau? Ein Interface PersonenVerwaltungsInterface, das alle Methoden beschreibt, die man auf der Personenverwaltung ausführen kann?

so dass du zum Schluss die SearchUtils nicht mehr zB. aus der GUI aufrufst, sondern eine Klasse hast, die sich darum kümmert.

Das verstehe ich nicht. Irgendwie muss ich ja von der GUI aus die Methoden aufrufen...

 

[KSG9|sebastian]

Mit abkapseln ist sowas gemeint:

public interface IPersistenceManager{
   public void savePerson(Person p) throws DBException;

   public boolean deletePerson(Person p) throws DBException;

   public List<Person> getAllPersons() throws DBException;
..
}


public class XMLPersistenceManager implements IPersistenceManager{
// implementierung
}

Die GUI bzw. der Controller kennt im besten Fall nur das Interface IPersistenceManager. Die konkrete Implementierung (hier: XMLPersistenceManager) wird per DependencyInjection erzeugt. Notfalls über nen statischen Initializer in Abhängigkeit von nem Systemproperty.
So kennt deine GUI/Anwendungsschicht keine Details zum Backend.

 

[Gast]

Von DependencyInjection habe ich zuvor noch nie gehört. Von dem was ich nachgelesen habe, ist das doch eher für größere Projekte, denn um das umzusetzen wird ein Framework wie Spring oder PicoContainer benötigt.

Ist ein sauberes MVC Konzept nicht schon genug um das Ganze loose zu koppeln?

 

[KSG9|sebastian]

Wieso brauchst du dafür Pico oder Spring?

Ne einfache Property-Datei genügt doch.

di.properties

de.test.IPersistenceManager=de.test.PersistenceManagerImpl

class DependencyResolver{
    private Properties props;
    public DepdendencyResolver(){
        props = new Properties();
        props.load(new File("di.properties"));
    }
    public <T> T resolve(Class<T> type){
        String value = props.getProperty(type.getName());
        Class<T> implType = Class.forName(value);
        return implType.newInstance();
    }
}

class ServiceLocator{
   private DependencyResolver resolver = new DependencyResolver();
   private IPersistenceManager persistenceManager;

   public IPersistenceManager getPersistenceManager(){
      if(persistenceManager == null){
         persistenceManager = resolver.resolve(IPersistenceManager.class);
      }
      return persistenceManager;
   }
}

 

[Guest]

Danke für das Beispiel!

Im Moment fühle ich mich so wie früher, als ich meine ersten Java Codezeilen geschrieben habe: Es fehlt der Überblick über das große Ganze.

Um etwas Licht ins Dunkle zu bringen hab ich mal versucht, es so graphisch darzustellen wie ich mir das im Moment vorstelle:

Ist das so korrekt?

 

[KSG9|sebastian]

ja, kann man so darstellen, richtig!

 

[Guest]

Prima!

Was mir jetzt noch unklar ist, ist der Unterschied dazu:

Abgesehen davon, dass es verpönt ist einen monolitischen Controller zu bauen, der alle Objekte kennt. Im Grunde ist der Service Locator doch genau das Gleiche denn auch er kennt alle Objekte.

 

[KSG9|sebastian]

Eigentlich wäre der Ablauf so:


GUI - Controller - ServiceLocator - DependencyResolver


Der Controller ist für die Logik zuständig. Der Controller holt sich über den ServicerLocator den IPersistenceManager.

Der ServiceLocator hat eine Instanz des DependencyResolvers und für jeden Manager (PersistenceManager..ABCManager...) eine Instanzvariable. Falls der gesuchte Manager null ist wird über den DepdendencyResolver versucht eine Instanz zu erzeugen.

Der IPersistenceManager ist wiederum dafür zuständig bestimmte Objekte zu laden, suchen, löschen oder updaten.

Die GUI sollte auch nicht direkt mit dem PersistenceManager kommunizieren. Der ServiceLocator ist auch kein Controller, er kapselt lediglich die DependencyInjection ab damit du im Controller nicht wissen muss was dort passiert.