Types in Types verschachteln?

RockWilder · 26. August 2009

Mahlzeit miteinander!

Zwecks Auswertung der Arbeitsaufträge (Anzahl und Arbeitswerte) unserer Kunden, sowie das Matching welcher Auftragsbearbeiter wieviel (auch wieder nach Anzahl und Arbeitswerte) so macht bin ich gerade dabei, eine kleine DB zusammen zu basteln. Nun kann ich ja einen Type "Bearbeiter" machen, der den Namen, die Anzahl und die Gesamtsumme aller Aufträge beinhaltet. Nur: wie komme ich dabei auf den jeweiligen Kunden? Kann ich ein Type "Kunde" machen, der den Namen und den Type "Bearbeiter" enthält?
Wenn nicht: wie bekomme ich sonst das Matching hin, dass Bearbeiter1 beim Kunden1 12 Aufträge mit der Wertigkeit 15 gemacht hat, beim Kunden2 hat er 5 Aufträge mit der Wertigkeit 8 gemacht, der Bearbeiter2 hat beim Kunden1 10 Aufträge mit der Wertigkeit 10 gemacht, beim Kunden 3 1 Auftrag mit der Wertigkeit 1, usw. usf.?

Und das ganze am Besten auch noch so übersichtlich, dass man derzeit 14 Bearbeiter und 21 Kunden verhackstücken und bei Bedarf auch noch erweitern kann? Irgendwie fehlt mir gerade die zündende Idee.

THX in advance!
RW

taurec · 26. August 2009

Ja die kannst du auch verschachteln, d.h. du verwendest Typ 1 as Variable im Typ2

RockWilder · 26. August 2009

Du meinst also:

Code

Type bearbeiter	name As String	cnt As Integer	sum As IntegerEnd TypeDim wer1 As bearbeiterDim wer2 As bearbeiterDim wer3 As bearbeiterDim wer4 As bearbeiterType kunde1	name As String	wer1 As String	wer2 As String	wer3 As String	wer4 As StringEnd TypeDim wo As kunde1

Und dann

Code

Print wo.wer1.cnt

?

taurec · 26. August 2009

Nein:

Code

Type bearbeiter
    name As String
    cnt As Integer
    sum As Integer
End Type




Type kunde1
    name As String
    wer1 As Bearbeiter
    wer2 As Bearbeiter
    wer3 As Bearbeiter
    wer4 As Bearbeiter
End Type


Dim wo As kunde1

Alles anzeigen

Und dann kannst du so drauf zugreifen

RockWilder · 28. August 2009

Hmpf ... hätte ich mal nicht nur gelesen, sondern sinnentnehmend gelesen, was du geschrieben hast. Dank Dir!

Aber ein Type kann ich nicht in eine andere Sub rüberwerfen? Bisher hab ich eine Sub, die alle meine Aufträge und Bearbeiter verwurstet. Auf Grund der Menge an Bearbeiter und Ausnahmen und Ausnahmen der Ausnahmen sind mittlerweile knapp 200 Zeilen in der Sub. Ist mir zu unübersichtlich, daher würde ich gerne splitten in diverse Schritte. Allerdings motzt der Designer was von einer illegalen Refenz ByVal. 'Wat nu?' sprach Zeus

THX in advance
RW

hchudek · 28. August 2009

Hallo,

eigentlich doch eine ideale Aufgabenstellung für OOP (Objekt-Orientierte Programmierung).

Wir haben ein Kundenobjekt, ein Auftragsobjekt und ein Bearbeiterobjekt.

Damit sind die ganzen Teile entkoppelt und wenn sich bei einem was ändert musst du nicht alles bei den anderen ändern.

Entweder hast du dann eine Liste der Kunden, jedes Kundenobjekt enthält dann eine Liste von Auftragsobjekten (also alle Aufträge, die beim Kunden gemacht wurden).
Das entsprechende Auftragsobjekt enthält dann Infos zu dem Auftrag und unter anderem auch das Bearbeiterobjekt.

oder du hast eine Liste der Aufträge (evtl. eine neue Klasse Auftragsliste), diese enthalten dann alle Aufträge und (wie oben) jeweils pro Auftrag den Kunden und den Bearbeiter.

Auf dieser Auftragsliste kannst du dann die entsprechenden Auswertungen hin und herrechnen.

Nachteil : Man braucht erstmal die Grundlagen für OOP, Objekte usw

Vorteil : Ist viel flexibler für spätere Anforderungen und irgendwann braucht man OOP bzw die entsprechenden Grundlagen eh :-))), die entsprechenden Objekte kann man für andere Gelegenheiten benutzen und das ganze später auch leicht(er) in Java übertragen.

:-))))

Viel Spass

Holger

RockWilder · 28. August 2009

Hallo Holger,

die Grundlagen wäre nicht das Problem. Das Problem ist viel eher, dass der Designer dafür bestenfalls minder geeignet ist, sauber zu programmieren und Klassen und Objekte zu verwalten. So, wie man es aus jeder vernünftigen IDE halt kennt.

Wenn die das Ding schon vereclipsisieren, warum die nicht gleich die bekannte Eclipseumgebung hergenommen haben, erschließt sich mir überhaupt nicht. Bis das nicht vernünftig und komfortabel tut, weigere ich mich rundweg, mir die Finger zu brechen. Für einen "mal eben so" programmierten Agenten (zumindest hätte er das anfangs sein sollen, nun wächst sich das doch aus) mache ich mir den Stress nicht.

Und Java kommt mir schon mal gleich gar nicht ins Haus!

hchudek · 28. August 2009

Hallo RockWilder,

volle Zustimmung was den Designer angeht. Soweit ich weiß sind aber am Designer einfach zu wenig Leute bei IBM dran, da kann man keine Super-Sprünge erwarten.

Aber mit 8.5.1 wirds ja jetzt besser. Die Beta sieht ja schon mal ganz ordentlich aus und man braucht jetzt auch keine Zusatztools, um sich nur mal die Klassenhierarchien anzuschauen oder eine übersichtliche Darstellung zu bekommen, sondern hat alles in seiner IDE (die dann leider halt mal den fünf- bis zehnfachen Speicherbedarf hat und zum starten mindestens doppelt bis dreimal so lange braucht ).

Zu Java : Wenn mans nicht braucht, ok, aber

1tens. gibts halt eine Menge an fertigem, gutem Code in der Java-Community, for free + dokumentiert (z.B. Logging oder Task-Management, spezielle Implementierungen von Algorithmen wie z.B. Sortierungen, Schlüsselerzeugung ( z.B. für Hashes), Java-Frameworks für Workflows usw. Es gibt zwar auch openntf, aber die Java-Gemeinde ist einfach viel größer als die Notes-Gemeinde).

2tens wird man durch die Eclipse-Plattform viel mehr Java-Code zu sehen bekommen + ich denke es ist dann gut, wenn man sich mit dem Thema schonmal auseinandergesetzt hat.

3tens gibts für die eher Skript-orientierten Programmierer (hey, absolut ohne Wertung hier, einfach nur zu Beschreibung der Programier-Sprachen-Art) Möglichkeiten mit z.B. Groovy zu arbeiten, Lotus Skript ist halt "closed" und alles, was IBM nicht macht, kann man selbst kaum machen. Java ist an dieser Stelle einfach offener (auch wenn Oracle jetzt bei manchem den Daumen draufhalten wird)

4tens kann man Java auch noch benutzen, wenn man aus dem Notes-Ökosystem heraustritt, mit den Grundlagen von Lotus Skript wird es dann schon schwieriger.

Natürlich gibt es auch Nachteile, der Code ist schwieriger unterzubringen (In IDE erstellen, Klassen im Designer reinkopieren+ Agentenrümpfe anpassen usw..), die Lernkurve für Java ist relativ hoch und im UI kann ich (noch ???) nichts mit Java anfangen und für schnelle, kurze Programmierungen (rapid prototyping) ist es auch oft zu viel Overhead (obwohl, seitdem ich einige Skelette für Agenten, Schleifen usw benutze und mit entsprechenden Techniken direkt aus der Eclipse-Umgebung meine Tests machen kann, ohne jedesmal alles in den Notes-Client rüberzukopieren ist auch ein einfacherer Agent zeimlich genausoschnell programmiert wie ein Skript-Agent).

Aber ich denke auch, dass man die meisten Sachen im Skript gut und schnell lösen kann + dazu keine neue Sprache lernen muss. Die meisten OOP-Ansätze funktionieren ja auch in Skript, und wem das reicht, der muß sich ja nicht verbiegen.

Viele Grüße

Holger

Magtheridon · 31. August 2009

Naja, ich würde das Klassen nehmen, damit geht das alles etwas besser.

Wenn Du (erst einmal) nur public Membervariablen nimmst, hast Du quasi das Type-Konstrukt nachgebildet.

Class Bearbeiter
....
End Class

Class Kunde
Public wer1 As Bearbeiter
....
End Class

Sub xyz(k as Kunde)
Msgbox k.wer1.name
End Sub

RockWilder · 31. August 2009

Holger: im Großen und Ganzen hast du ja Recht. Nur, ich muss zugeben, dass ich -aus der Scriptsprachenecken (Amiga Basic) herkommend- für "mal eben schnell"-Agenten doch noch LS bevorzuge. Java als solches ist kein unbekanntes Thema für mich. Allerdings bin ich da noch nicht so flüssig, wie in LS. Daher versuche ich Java auf Einsatzgebiete zu beschränken, die entweder von anderen weiter gepflegt werden, oder wo absehbar ist, dass sie die nächsten Jahre benötigt werden. Solcherlei Code wird dann von unseren Entwicklern weiter gepflegt (die Java noch weniger ab können, als ich :lol:).
Die Beta vom .1er hab ich noch nicht gesehen. Wenn du sagst, dass die brauchbar sein wird, lass ich mich mal überraschen. Allerdings kann ich nicht nachvollziehen, dass der Designer so stiefmütterlich behandelt wird, weil "zu wenig Leute bei IBM dran" sein sollen. Zum Einen soll das nicht das Problem der Nutzerbasis sein (wie vieles andere, was IBM verbockt, auch nicht), zum Anderen hätten die doch nur die Eclipse-IDE nehmen müssen, ein wenig Funktionalität zum Handling von Notes-DBs dranprogrammieren, ein IBM-Logo drauf und fertig ist der Lack. Ok, stark vereinfacht, aber so in der Art hätte es laufen können. Jetzt haben die ein bischen Eclispe drunter geschoben, der Designer ist aber noch genau so eine Krücke, wie er seit eh und je war. Nun müssen die nochmal dran. Und Arbeit, die man nicht richtig macht, ist Arbeit, die man zweimal macht. Naja, zu vielen Produkt- und Strategieentscheidungen von IBM sag ich einfach nichts mehr, irgendwann wirds langweilig.

Magtheridon: du hast schon recht, eine strikte OO-Modellierung wäre sinniger gewesen. Allerdings ist mir das Handling von Objekten, Klassen, Methoden, Properties in der Designer-IDE einfach zu umständig und hakelig. Um nicht zu sagen: schlicht nicht vorhanden. Ich meine mich zu erinnern, dass es doch mal ein Eclipse-Plugin gab, dass Java-Code in DBs reingeschossen hat. Ich finds nur grad nirgends. Eventuell wäre das noch eine Alternative? Ich warte einfach mal auf den 8.5.1, dann seh ich weiter. Für den vorliegenden Anwendungsfall reicht die Codestruktur, wie sie jetzt ist, vollständig aus. Ist nicht schön, aber tut. Mehr ist nicht verlangt.

Jedenfalls Dank euch allen!

Teilen