Designfrage bzw. Meinung zur Umsetzung

[Marco13]

Das mit der Synchronisation hatte ich ja schon angedeutet. Wenn alles read-only ist, stellt sich die Frage nicht.
Aber wenn man wirklich "gewissenhaft" drangehen würde: Sollten die "emf" und "contr" wirklich dort liegen? Wenn ich das richtig sehe, wird das nur für den Aufruf "contr.getAllAddress()" gebraucht, was vermutlich eine Collection zurückliefert. Demnach könnte man der Klasse im Konstruktor eine Collection geben (die kann dann auch mal woanders her kommen, was für Tests ganz praktisch sein kann). Dann würde es sich ggf. anbieten, den Konstruktor private zu machen, und sowas wie

1
2
3
4
5
6
public static GlobalAddressHandler createThisDefaultThingy()
{
    EntityManagerFactory emf = Persistence.createEntityManagerFactory("PraxisPU");
    AddressJpaController contr = new AddressJpaController(emf);
    return new GlobalAddressHandler(contr.getAllAddress());
}

anzubieten.

Die
private Map<String, ArrayList<Address>> addressMap
könnte noch final sein.

Sonst... mal weitersehen, sobald mein Morgenkaffee wirkt

[F.S.WhiTeY]

Zitat: FArt

	Kann nicht sein. Serializable ist ein Vertrag, den deine Klasse erfüllen muss. Jetzt hast du ein Attribut EntityManagerFactory, und das ist nicht serialsierbar (oder?). Ist es der AdressJpaController? Ist Adress serialsierbar, weil du eine Map davon hälst? Bedenke, dass Änderungen die server version UID ändern können und somit die nächste Version u.U. nicht mehr kompatibel zu dieser sein kann. Warum hast sind zwei Attribute im Scope package protected? Du hast eine öffentliche init() Methode und rufst diese im Konstruktor auf, somit kann die jeder immer wieder aufrufen. Ist das so gewollt? Außerdem ist weder die Klasse noch die Methode final. Eine Ableitung könnte deine Klasse unbrauchbar machen. Was ist der Zweck bzw. der Vorteil dieser Klasse? Was bringt es die Adressen so zu halten?

Moin,

viele Fragen und hier mal die Antworten. Ich hab zwar nicht auf jede eine, allerdings auf einige.

Zitat:

	Jetzt hast du ein Attribut EntityManagerFactory, und das ist nicht serialsierbar (oder?). Ist es der AdressJpaController?

Der AdressJPAController auf jeden fall. Ist ein "DAO" mit CRUD-Methoden. Der emf ist es allerdings wirklich nicht (gerade nachgelesen) da sollte ich mir über die implementierung nochmal gedanken machem.

Zitat:

	Ist Adress serialsierbar, weil du eine Map davon hälst?

Adress ist serialisierbar, den Kontext mit der Map verstehe ich nicht.

Zitat:

	Bedenke, dass Änderungen die server version UID ändern können und somit die nächste Version u.U. nicht mehr kompatibel zu dieser sein kann.

Der Satz erschließt sich mir auch nicht

Zitat:

	Du hast eine öffentliche init() Methode und rufst diese im Konstruktor auf, somit kann die jeder immer wieder aufrufen. Ist das so gewollt? Außerdem ist weder die Klasse noch die Methode final. Eine Ableitung könnte deine Klasse unbrauchbar machen.

Ja das ist so gewollt. Die Klasse hält lediglich die Daten, sollte sich in dem Datenbestand ( Model ) etwas ändern, MÜSSEN die Datenbestände aktualisiert werden.
Eine Ableitung der Klasse ist eigentlich nicht vorgesehen zumindest nicht aus meiner Sicht.

Zitat:

	Was ist der Zweck bzw. der Vorteil dieser Klasse? Was bringt es die Adressen so zu halten?

Simpel und einfach: Arbeitspeicher Spaarn. Das sind daten auf die jeder User zugreifen können muss und teilweise auch noch damit arbeiten können muss. Wenn ich 1000 User habe, die sich diese Daten aus der Persistenz-Schicht holen, habe ich die Map 1000 mal im Arbeitsspeicher, das ist unnötig da ich die Daten so einmal aus der DB hole und jeder User in seiner Session damit arbeiten kann.

Zitat:

	P.S. die Klasse heißt "Global" und ist nicht synchronisiert. Ist sichergestellt, dass keine konkurrierenden Zugriffe stattfinden?

Es ist eine ManagedBean im ApplicationScope... wenn ich das richtig verstanden habe bedeutet das automatisch Ja, es ist automatisch synchronisiert und konkurrierenden Zugriffe sind ausgeschlossen.
Da kümmert sich JSF und der Applikationserver drum.


Soweit erstmal, Marco bekommt seinen eigenen Post

LG

[F.S.WhiTeY]

Zitat: Marco13

	Das mit der Synchronisation hatte ich ja schon angedeutet. Wenn alles read-only ist, stellt sich die Frage nicht. Aber wenn man wirklich "gewissenhaft" drangehen würde: Sollten die "emf" und "contr" wirklich dort liegen? Wenn ich das richtig sehe, wird das nur für den Aufruf "contr.getAllAddress()" gebraucht, was vermutlich eine Collection zurückliefert. Demnach könnte man der Klasse im Konstruktor eine Collection geben (die kann dann auch mal woanders her kommen, was für Tests ganz praktisch sein kann). Dann würde es sich ggf. anbieten, den Konstruktor private zu machen, und sowas wie 1 2 3 4 5 6 public static GlobalAddressHandler createThisDefaultThingy() {     EntityManagerFactory emf = Persistence.createEntityManagerFactory("PraxisPU");     AddressJpaController contr = new AddressJpaController(emf);     return new GlobalAddressHandler(contr.getAllAddress()); } anzubieten. Die private Map<String, ArrayList<Address>> addressMap könnte noch final sein. Sonst... mal weitersehen, sobald mein Morgenkaffee wirkt

Hmm... nicht wirklich. Die Map darf garnicht Final sein. Ich muss das Object "updaten" können wenn sich im Moddel etwas ändert. Wenn jemand eine neue Adresse hinzufügt will ich das ganze ding ja nicht neu Erstellen sondern nur updaten. Das ganze wird ja über DI in einer andern Bean benutzt.( ManagedProperty )
Dabei war es nicht meine intention ein neues Object zurück zu werfen und den GC vorbeischauen zu lassen. Solange die Applikation lebt, soll dieses Object leben und "live" verändert werden.

Diese Addressen dürfen btw auch nicht gelöscht werden, was auch noch wichtig zu wissen ist meiner Meinung nach.

Ich schließe nicht aus das ich da auf einem falschen Weg bin, allerdings habe ich derzeit noch das gefühl meine Absichten nicht deutlich genug formuliert zu haben

Aber da könnt ihr ja nichts für

LG

[Landei]

Wenn du eine Map-Variable final machst, heißt das nicht, dass du da keine Werte mehr reinschreiben oder rauslöschen kannst, sondern nur, dass du die Referenz nicht auf eine andere Map oder null "umbiegen" kannst.

[F.S.WhiTeY]

Zitat: Landei

	Wenn du eine Map-Variable final machst, heißt das nicht, dass du da keine Werte mehr reinschreiben oder rauslöschen kannst, sondern nur, dass du die Referenz nicht auf eine andere Map oder null "umbiegen" kannst.

Also sozusagen eine finale Refferenz auf das Object, anstelle eines finalen Objectes?

Kommt es den so offt vor, das Codeteile "ungewissenhaft" genutzt werden und man dafür sorgen muss, dass die schnittstelle von außen nicht "falsch" genutzt werden kann? Ich beziehe das nun auf eine Entwicklung innerhalb eines Hauses, im Team.

Die Beispiele waren schon logisch, werte aber teilweise schon ein wenig die Intelligenz der Mitglieder ab

LG

[ThreadPool]

Zitat: F.S.WhiTeY

	[...] Kommt es den so offt vor, das Codeteile "ungewissenhaft" genutzt werden und man dafür sorgen muss, dass die schnittstelle von außen nicht "falsch" genutzt werden kann? Ich beziehe das nun auf eine Entwicklung innerhalb eines Hauses, im Team. [...]

Ja kommt es, und es wird auch gewissenhaft nicht die Dokumentation gelesen.

[F.S.WhiTeY]

Das is schon ein wenig schade aber ich kann es mir schon vorstellen. Ärgerlich wenn durch solche "Fehler" ein Debug gestartet wird und man sich nicht erklären kann wo es her kommt.

Das bedeutet allerdings für mich, dass ich mich gänzlich umstellen muss. Zumindest in hinblick auf die bereitstellung von Schnittstellen und Ressourcen nach "Außen".

Soviel zu: "Sie sind bereit für die Arbeitswelt wenn ihr Studium zu ende ist!"

[Marco13]

Man kann da unterschiedliche Prioritäten setzen. Ich weiß auch, dass es eine ""Arbeitswelt"" gibt, in der auf solche Dinge nicht viel wert gelegt wird. Ich habe auch schon Aussagen gehört wie: "Ich kann das field doch public machen - wenn das irgendjemand verwendet ist er doch selbst schuld". Ausbreiten will ich das nicht, sonst reg' ich mich nur wieder auf

Fakt ist aber, dass es den "Amöben-Effekt" gibt, den Jaroslav Tulach in Amazon.com: Practical API Design: Confessions of a Java Framework Architect (9781430209737): Jaroslav Tulach: Books schön beschrieben hat: Man entwirft seine Schnittstellen, und denkt: "Ja, die sind schön sauber und klar". Das ist symbolisiert als schöner, runder Kreis. Im Laufe der Zeit stellt man fest, dass das nicht so ist. Genaugenommen stellt man es nicht unbedingt selbst fest, sondern die, die die API benutzen: "Ah, hier bekomme ich eine Liste zurück... da tu' ich noch ein paar Sachen rein, und verwende sie dann weiter". Und schon ist für den Benutzer der API unumstößlich und unabänderlich (!) klar, dass diese Liste, die er da bekommt, jetzt und für alle Zeit veränderbar sein muss. Das steht vielleicht (im schlechtesten Fall) NICHT so in der Spezifikation, aber ist ein Verhalten, das die API in der Realität (zumindest in einer bestimmten Version) eben HAT. Das ist dann symbolisiert durch eine "Amöbe", die etwa die Kreisform hat, aber kleine "Füßchen" aus dem Kreis herausstreckt.

Also: "Beware of the pseudopodia!"

[F.S.WhiTeY]

Da sich die Anforderungen gerade geändert haben, habe ich das mit der MAp erstmal verworfen.
Ich bin, leider gottes, gezwungen eine Liste zu benutzen.

Aber vilt. ist das nun eher nach eurem "Geschmack" :P

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
 
@ManagedBean(name = "global")
@ApplicationScoped
public class GlobalAdressHandler implements Serializable {
 
    private final List<Address> addresses;
    
    /** Creates a new instance of GlobalAdressHandler */
    public GlobalAdressHandler() {
        EntityManagerFactory emf = Persistence.createEntityManagerFactory("PraxisPU");
        AddressJpaController contr = new AddressJpaController(emf);
        this.addresses = contr.getAllInstituts();
        Collections.sort(addresses);
    }
    
    public void update(Address newAddress){
        
        addresses.add(newAddress);
        Collections.sort(addresses);
        
    }
 
    public List<Address> getAddresses() {
        
        return Collections.unmodifiableList(addresses);
 
    }
 
}

Wobei ich noch nicht wirklich verstanden habe, was bei return Collections.unmodifiableList(addresses); im Arbeitsspeicher passiert.

Wenn da jeweils eine neue Collection angelegt wird, ist mein vorhaben am Ar***

LG

[FArt]

Zitat: F.S.WhiTeY

	Wobei ich noch nicht wirklich verstanden habe, was bei return Collections.unmodifiableList(addresses); im Arbeitsspeicher passiert.

Hast du in den Code geschaut? Da sieht man recht gut, was passiert.

Zitat: F.S.WhiTeY

	Wenn da jeweils eine neue Collection angelegt wird, ist mein vorhaben am Ar***

???

[EikeB]

Zitat:

	Wobei ich noch nicht wirklich verstanden habe, was bei return Collections.unmodifiableList(addresses); im Arbeitsspeicher passiert.

Die Methode gibt dir eine UnmodifiableList zurück, die die übergebene Liste wrappt und die set/add Methoden unterbindet. Aber wie FArt schon sagte, das steht alles prima im Quelltext erläutert.

[Mujahiddin]

Collections.unmodifiableList gibt einfach deine Liste zurück, da wird weder was kopiert, noch irgendwas verändert. Es wird einfach ein neues Interface List erzeugt, das bei Leseoperationen auf deine Liste zurückgreift und bei Schreibeoperationen ne Exception wirft.

[Spacerat]

Zitat: F.S.WhiTeY

	Öhm... Da muss ich gesteh.. Keine Ahnung, sind beide eigentlich schon "Serialisiert" aber ich hab mir das so angewöhnt, weil mein Dozent in der Dazugehörigen Vorlseung das so gern gesehen hat. Anders ausgedrückt: Es gab Punktabzug wenn nicht.

Hat euch euer Dozent dann nicht auch erklärt, wozu so eine serialVersionUID da ist und warum man eine berechnen lassen sollte? Und darüber hinaus... Try-Error und Serializable sind nicht grad' die besten Freunde. Wie oft man da eine neue SVUID benötigt...

[F.S.WhiTeY]

Zitat:

	Hat euch euer Dozent dann nicht auch erklärt, wozu so eine serialVersionUID da ist und warum man eine berechnen lassen sollte?

Ja und Nein. Dieses Thema wurde so gesehen nur angeschnitten. Die Kernaussage war, dass die Serialisierung die Persistierung unterstüzt.

Wie dieser Mechanismus in Java umgesetzt wird, war kein Thema. Da war die Zeit aber auch nicht für da. Es gibt so einige Themen die bei uns nur angschnitten wurden.

Paralelisierung z.B. da hat man ca. zwei Blöcke etwas gehört und wenn ich das zusammen fasse kam dabei heraus: Es gibt Threads in java, die kann man benutzen. Dabei kann man eine Observermuster implementieren wenn man will und es gibt, zumindest auf single core CPU's, keine wirkliche nebenläufigkeit sondern nur eine gefakte.

Dolle sache, damit kann ich im Alltag viel anfangen

Wenn ich meinen zweiten Studiengang beendet habe, werde ich nicht drum herum kommen einiges nach zu holen.

Und um Missverständniss aus zu schließen: Was das Programmieren angeht war ich einer der Besten in meinen Vorlesungen.

Ich denke ein großes Problem ist da die Bachelor / Master geschichte. Die Dozenten haben sau wenig Zeit mit uns und sollen uns nahezu das gleiche reinprügeln wie den Diplomern.
Das geht halt nicht immer gut. Dafür hab ich ohne ende Mathe gehabt. Nicht das Mathe nicht wichtig wäre aber das Verrhältniss stimmt meiner meinung nach nicht. Wenn man den Bachelor von 6 auf 8 Semester Regelstudienzeit anheben würde, hätte man auch fähigere Leute die da raus kommen.
Stat dessen darf ich mir Vorlesungen wie Lern und Arbeitstechniken geben, wo mir ein Sozialpädagoge erzählen will wie ich mich zu organisieren habe. Das Passt dann irgendwie nicht.

Ich kenne Leute die durchs Studium gekommen sind und bis zu letzt zu blöd waren ein Array zu Invertieren. Wenn sich das auf meine berufliche Laufbahn spiegelt, prost mahlzeit...

[andreT]

Zitat: F.S.WhiTeY

	... Leute die durchs Studium gekommen sind und bis zu letzt zu blöd waren ein Array zu Invertieren. Wenn sich das auf meine berufliche Laufbahn spiegelt, prost mahlzeit...

Ich will ja nicht noch Öl ins Feuer gießen, aber das Beste weisst du noch gar nicht : Die mit den "Array-Problemen" werden dann auch noch deine Chefs sein

[Spacerat]

Zitat: F.S.WhiTeY

	prost mahlzeit...

Das sag' mal laut... XD Mich beschleicht das Gefühl, dass man als autodidakt plötzlich mehr auf dem Kasten hat, als einer der's studiert hat. Wie kann man an ein Diplom kommen, wenn man nicht mal "Grundlagen" kennt? Deren Diplom kann man doch höchstens als Klodeckel verwenden, wobei man sich das Hochklappen bei grösseren Geschäften auch mal reinen Gewissens sparen kann.

[F.S.WhiTeY]

Zitat:

	Mich beschleicht das Gefühl, dass man als autodidakt plötzlich mehr auf dem Kasten hat, als einer der's studiert hat. Wie kann man an ein Diplom kommen, wenn man nicht mal "Grundlagen" kennt?

Naja dazu muss man mehrere Faktoren berücksichtigen:

1. Wie lange setzt du dich damit schon Autodidaktisch auseinander?

Im Studium bist du ca. 6 Semester also 3 Jahre. Von den drei Jahren machst du ca 1 Jahr Programmierung mit Grundlagen und "aufbauenden" Themen.

Der Rest ist Theoretische Informatik : Mathe, Algorithmik, wieder Mathe, Theoretische Informatik als Fach --> Komplexitäten, Berechenbarkeit usw. , wieder Mathe, UML und Softwaredesign, Algorithmik 2.

Dann noch solch lustige Fächer wie: Digitale Schaltungen, Rechnerstruckturen, Rechnernetze, Datenbanken.

2. Was studierst du übehaupt?

Ich bin praktischer Informatiker. Meine Studium ist auf Software Design und Architektur ausgelegt. Im endefekt sollte ich der sein, der dem Programmiere (Fachinformatiker) sagt wo der Weg lang geht... aber Theorie und Praxis xD

Wer will jemanden mit dem Array-Problem ( Das sollte nen running gag werden ) ernst nehmen?

Als Fazit: Ich hab im Studium viel gelernt aber Programmieren war davon lediglich ein bruchteil. Aber ich studiere ja auch nicht "Programmierer" ich studiere engineering. Leider werden diese Leute nach dem Studium als "Programmierer" gehandelt.

Glatter Kommunikationsfehler zwischen Hochschulen und Wirtschaft würde ich sagen.

Und dann sind da ja noch ganz andere Studiengänge. Sowas wie : IT Management oder Wirtschaftsinformatiker.

Tolle leute für führende Positionen xD Die können meist weniger als Garnix.


Als Fazit für mich persönlich: Ich zieh das Studium auch im zweiten gang durch (Master), da mir das erste schon sehr viel an weit gefächertem Wissen verschafft hat. Desweiteren wollen Personaler diesen Wisch sehen.

Der Rest kommt durch Selbststudium und Erfahrung. Ich Programmiere hier gerade mein erstes "größeres" Projekt und hab im Studium nur laboraufgaben lösen müssen die der Wirklichkeit so nahe kommen wie fliegende Kühe. Die Komplexität dieser Aufgaben und die geforderte Umsetuzung sind Math.floor( NaN );

In diesem Sinne: PROST!

[Landei]

Zitat: F.S.WhiTeY

	Und dann sind da ja noch ganz andere Studiengänge. Sowas wie : IT Management oder Wirtschaftsinformatiker.

Alles Vorurteile

[Spacerat]

Offtopic:

@TO: Tja... Ich studiere nicht, hab' ich auch nie. Wollte zwar mal, aber das sollte aus finanziellen Gründen nicht sein. Java programmiere ich nur interessehalber und das schon etwas länger als nur 3 Jahre. Hab' 2 Ausbildungen - Metallbauer und Mechatroniker, jede Menge Fort- und Weiterbildungen (Pneumatik, Hydraulik, Automatisierungstechnik, Elektrotechnik und Elektronik, Digitaltechnik, CNC und SPS).
Meistens begenen mir Studenten halt recht Hochnäsig und das nur weil sie ein Diplom (o.ä.) vorweisen können, damit auf Clean-Code-Conventions herumreiten und deswegen mit vernebeltem Quelltext (also Quelltext, der nicht dem entspricht, was sie gelernt haben) kaum klar kommen. Die meisten davon sind allerdings noch Grünschnäbel, welche nur ihr frisch gedrucktes Diplom sehen und sich sonst ziemlich überheblich einen Dreck um die restliche Arbeitswelt scheren. Ich dagegen mach' mir noch die Mühe (naja... das geht inzwischen automatisch) und versuche selbst die wirresten Codezeilen zu entziffern. Und wer das bei dem hier schafft, der schafft's auch bei Quelltexten anderer Programmiersprachen. Deswegen kann ich mich meistens auch eines gewissen Sarkasmus wie oben nicht erwehren. UML? Was ist das?
Wenn du das mit deinen Vorsätzen ernst meinst, stellst du für mich eine gewisse Ausnahme unter deinen Mitstreitern dar. Und wenn ich heute auf mein Sparbuch schau', schraub' ich lieber weiter an irgendwelchen Baumaschinen rum, bevor ich noch mal ein Studium in Erwägung ziehe.
Zuletzt: In meiner Ausbildung zum Mechatroniker bleute man mir auch ein, dass für mich mindestens drei andere gehen dürften.

[F.S.WhiTeY]

Zitat:

	Meistens begenen mir Studenten halt recht Hochnäsig und das nur weil sie ein Diplom (o.ä.) vorweisen können, damit auf Clean-Code-Conventions herumreiten

Wie soll eine Mensch der Defiziete verstecken muss auch sonst reagieren? Sich diskreditieren und so schlau gucken wie er wirklich ist?

Nicht ohne grund steht in fast jeder Stellenanzeige das sie Leute mit Berufserfahrung suchen

Ich sag nur: Immer schön selbstbewusstes Auftreten bei völliger Ahnungslosigkeit xD