Das Notes Forum

Lotus Notes / Domino Sonstiges => Projekt Bereich => Thema gestartet von: Marinero Atlántico am 30.12.04 - 17:59:54



Titel: [GOF Side Thread] OO in LS
Beitrag von: Marinero Atlántico am 30.12.04 - 17:59:54
Hi,

 ;D tja immer noch nicht der feierlich angekündigte code, sondern ein weiterer theoretischer side-Thread.

Liegt aber u.a. auch daran, dass tragischerweise mein Arbeitsjahr noch nicht abgeschlossen ist.

Zumindest habe ich mir jetzt die OO Fähigkeiten von LS näher zu Gemüte geführt. Schliesslich muss ich den HF DP code portieren.
Sieht so aus, dass ich für die Ausgabe Notes-Logging (LS-NotesLog-Klasse, nicht log.nsf) verwende. Der HF DP code ist reiner Konsolen code und print statements sind keine Freude.

Hier der Vergleich zu Java (bzw. was LS-OO fehlt oder was es da mehr gibt). Wie gesagt gehe ich dann in den Beispielen später darauf ein, was die einzelnen Fremdwörter wie Polimorphismus, Abstrakte Klassen und ähnliches bedeuten.
Es ist nur jetzt eben frisch in der Erinnerung.
Für vorhandenes Notes-Talente, die jetzt ein bischen mit Java daddeln mag das auch sonstwie interessant sein.

Für mich in der Reihenfolge der Bedeutung in Vergleich zu Java. Wird möglicherweise fortgeführt:

I. Was fehlt LotusScript
- Keine Abstrakten Klassen oder Interfaces. 
Beide dienen in Java zur Unterstützung von Polymorphismus. Beide können nicht instantiiert werden.
In LotusScript kann jede Klasse instantiiert werden. Das ist nicht gut. Interfaces und Abstrakte Klassen dienen als eine Art "polimorphe Klammer" (Begriff ist von mir), was ziemlich gut ist (wird noch zu sehen sein).

- Keine Interfaces
In Java gibt es zwar keine Mehrfachvererbung. Zumindest oder völlig ausreichenderweise kann man aber durch Java-Interfaces ein Objekt in mehrerere, mehrere, mehrere sagen wir Vererbungsstränge sagen wir polymorphistisch einbinden.

- fehlender IDE support

<updated date="30.12.04">
- kein Methoden - overloading (s. u.)  >:(

- kein Variablen-shadowing (wird noch erklärt)

- kein Äquivalent zu final (CONST ist verboten!)
</updated>

- Keine Packages
In Java können Klassen in sogenannte Packages geordnet werden. Dies hilft der Übersichtlichkeit, wenn man viele Klassen hat und man hat auch zusätzliche access modifier

- Keine Reflection Möglichkeiten (Javabuch3 Kap. 43)
Man kann so Klassen in den code einbinden, die zur Laufzeit bekannt sind und zur Kompilierzeit nocht nicht bekannt sind.
Viele Java-Frameworks wie Spring, Hibernate, Struts, etc. benutzen die Reflection API stark. Der Wald und Wiesen Programmierer auch manchmal und es gibt zu diesem Thema nun sogar ein eigenes Buch bei Manning. Sun hat viel Mühe darin gesteckt, die Performance Kosten von Reflectioning (?) zu verringern.

- keine static Methoden oder Variablen
static Member (Überbegriff für Methoden und Variablen) gehören nicht zum Objekt sondern zur Klasse. Machen manchmal Sinn. Z.B. beim Singleton Pattern.

- Nur 1 Konstruktor pro Klasse möglich (kein Konstruktor overloading)
In Java kann es mehrere geben. Es wird immer der "passende" aufgerufen. Passend hängt von den dem new übergebenen Parametern ab:

Code:
Person person = new Person("Meier", 18);
// ruft auf:
Person(String name, int age) {
// stuff
}

Person person = new Person("Meier");
// ruft auf:
Person (String name) {
// stuff
}

In LotusScript ist zwar die Übergabe von Parametern möglich. Es kann aber nur einen Konstruktor pro Klasse geben.

- 2 statt 4 access modifier
In Java gibt es neben public und private noch <leer>(=package-visibility) und protected. Hilft bei der Kappselung in Anwendung mit vielen Klassen. 

- Keine Serialisierung
In Java können Objekte in einen Stream umgewandelt werden, der dann in einem File zwischengelagert wird oder übers Netzwerk geschickt werden kann. Sinnvoll für Anwendungen mit verteilten Objekten.
 
- Keine gemeinsame Parent-Klasse.
In Java erbt jede Klasse von java.lang.Object. Das unterstützt Polymorphismus. Man kann das natürlich selbst programmieren.


- Syntax für Aufruf des Parent Constructors in LS sehr merkwürdig
In Vererbungshierarchien wird der Constructor der Klasse von der geerbt wurde mitaufgerufen. Falls die Signatur des Constructors in Lotus Script Parameter erfordert, ist die Syntax echt gewöhnungsbedürftig. Später mehr.
 
- keine inneren Klassen
Kann in manchen Fällen relativ praktisch zu sein.

II. Was hat LotusScript zusätzlich:
- Explizites Löschen von Objekten
Offenbar gibt es einen Garbage Collector und zusätzlich kann man die Objekte explizit aus dem Speicher entfernen (destroy Methode). In Java ist man auf Gedeih und Verderb vom Garbage Collector angewiesen. Offenbar wird das aber in Java 1.5 ein bischen oder viel besser (weiss nicht).
 
- Neben Variablen und Methoden gibt es noch sogenannte Properties
Wie getter und setter in Java. In Java gibt es dafür Namenskonventionen (setXxx, getXyyy). Eigentlich ausreichend. Schlecht finde ich das mit den Properties aber nicht.


Bei der Portierung des HF DP gof codes wird dann zu sehen sein, inwieweit sich die Nachteile (und Vorteile) von LS gegenüber Java bemerkbar machen.

 


Titel: Re: [GOF Side Thread] OO in LS
Beitrag von: TMC am 30.12.04 - 19:18:37
Danke für die Informationen !

Nur aus Interesse (leider hänge ich in Java noch ganz am Anfang):
- Nur 1 Konstruktor pro Klasse möglich (kein Konstruktor overloading)
In Java kann es mehrere geben. Es wird immer der "passende" aufgerufen. Passend hängt von den dem new übergebenen Parametern ab:

Code:
Person person = new Person("Meier", 18);
// ruft auf:
Person(String name, int age) {
// stuff
}

Person person = new Person("Meier");
// ruft auf:
Person (String name) {
// stuff
}

In LotusScript ist zwar die Übergabe von Parametern möglich. Es kann aber nur einen Konstruktor pro Klasse geben.

In LotusScript übersetzt heißt das für mich, ich kann in Java z.B. so ein neues Objekt erstellen:
Dim guy as New Person("Hans")
oder
Dim guy as New Person("Hans", 300)

1:1 zusammengezählt heißt dies für mich, man kann in Java Parameter weglassen. In LotusScript: no way.
Ich habe die Problematik oft in LS, wenn ich globale Functions erstelle.
Ich will da manche Dinge offen halten. z.B.
Code:
Function DoSomeStuff(strBlaBla as Strung, boolean1 as Boolean, int2 as Integer)

Wenn ich nun diese Function aufrufe, muss ich immer alle 3 Parameter angeben, auch wenn z.B. int2 nur interessiert, wenn boolean1 = True ist.

Wenn dies in Java möglich ist, wäre es ein weiterer Punkt für Deine Liste "Was fehlt in LotusScript".
Dann wäre aber interessant, wie dies in Java gehändelt wird. Ein Select Case auf "wurde der 2. Parameter übergeben oder weggelassen" ?

Mehrere Konstruktoren pro Klasse in LS: müsste man wohl über Parameter händeln und entsprechend aufzweigen (Select Case / If-Else etc.).


Titel: Re: [GOF Side Thread] OO in LS
Beitrag von: Semeaphoros am 30.12.04 - 20:20:44
Matthias:
Da gibt es zwei Konzepte, und das gilt genau genommen nicht nur für die Konstruktoren, sondern eigentlich für jede Art von Subroutinen/Funktionen und ist eigentlich auch nicht wirklich ein OO-Thema, sondern eher Compiler-Bau/Sprachen-Design.

Es gibt zwei Konzepte: das eine sind fakultative Parameter. Die kennt LotusScript bei den eingebauten Funktionen/Methoden, nicht jedoch bei User-Defined Functions/Subs/Methoden. Beispielsweise bei der Massagebox, da kannst Du die letzten Paramter weglassen, dann werden sie durch einen Default-Wert ersetzt.

Das andere - mehrere Konstruktoren oder gleichnamige Methoden (nur OO) oder mehrere, gleichnamige Subs/Functions -  läuft ein wenig anders:

Während bei fakultativen Parametern der Typ der Parameter immer der gleiche ist, kann dies beim Overloading anders sein: die gleiche Funktion kann mehrfach definiert sein und die Parameterliste kann bei jeder Definition anders aussehen:

Definition 1:
Ausgabe (Name As String, Anzahl as Integer)

Definition 2:
Ausgabe (Size As Integer,Price As Double,ItemName As String, Count As Integer)

In diesem Fall sind die Signaturen der Func/Sub/Method völlig unterschiedlich. Und beim Kompilieren wird die betreffende Routine durch einen Vergleich des Aufrufs und der betreffenden Signaturen (oder bei Late-binding zu Runtime) ausgewählt.

Auch das beherrscht LotusScript bei den eingebauten Routinen, beispielsweise beim Print-Statement und bei verschiedenen Typ-Convertierungen (es spielt da keine Rolle, welchen Typ der Parameter hat), aber wiederum nicht bei den Userdefined Funcs/Subs/Methods.


Axel: ein Seitenhieb sei erlaubt: die Java-Implementation ist ... sorry ... hinverbrannt, das macht das ganze Gemüse total unübersichtlich. Statt einem Overload des Constructors New wäre es viel schlauer gewesen, eine Implementation à la Delphi zu wählen, wo mehrere Konstruktoren mit unterschiedlichem Namen definiert werden können und beim Instantiieren eines Objektes (Create) muss der zu verwendende Konstruktor namentlich aufgeführt werden. Das erhöht ganz gewaltig die Lesbarkeit des Sourcecodes. Da kann Java leider die unglückliche Elternschaft nicht verbergen.


Titel: Re: [GOF Side Thread] OO in LS
Beitrag von: Marinero Atlántico am 30.12.04 - 20:28:05
Axel: ein Seitenhieb sei erlaubt: die Java-Implementation ist ... sorry ... hinverbrannt, das macht das ganze Gemüse total unübersichtlich. Statt einem Overload des Constructors New wäre es viel schlauer gewesen, eine Implementation à la Delphi zu wählen, wo mehrere Konstruktoren mit unterschiedlichem Namen definiert werden können und beim Instantiieren eines Objektes (Create) muss der zu verwendende Konstruktor namentlich aufgeführt werden. Das erhöht ganz gewaltig die Lesbarkeit des Sourcecodes. Da kann Java leider die unglückliche Elternschaft nicht verbergen.

Das ist richtig. Man kann aber mit statischen Factory-Methoden arbeiten.
Es gibt Diskussionen im Internet der Art "new considered evil".
Ein noch blöderer Aspekt dieses Konstruktor_heisst_wie_klasse_Phänomen ist ... aber das führt jetzt zuweit.
Etwas, dass btw. auch so ähnlich in EJB2.0 geändert wurde. Egal.

So geht das mit static Factory-Methode:
Code:
class Person {

// wg. private kann Objekt nur über Factory Methode erzeugt werden
private Person (String name, int age) {
this.name = name;
this.age = age;
}

public static Person createPersonWithoutParameters() {
return new Person("No_Name", -1);
}

public static Person createPersonWithName(String name) {
return new Person(name, -1);
}

public static Person createPersonWithNameAndAge(String name, int age) {
return new Person (name, age);
}
}


Titel: Re: [GOF Side Thread] OO in LS
Beitrag von: Semeaphoros am 30.12.04 - 20:29:56
Sicher, man kann damit umgehen, sobald man das Problem erkannt hat, sagen wir mal, solange man den Code unter eigener Kontrolle hat, und keinen Fremdcode einbindet, da muss man dann wohl nehmen, was man bekommt ..... aber das ist ja klar .... :)


Titel: Re: [GOF Side Thread] OO in LS
Beitrag von: TMC am 30.12.04 - 20:42:02
Danke für die Erklärung, Jens.
Dies bestätigt meine bisherigen Erfahrungen.

Wie schrieb letztens Joe Litton auf seinem Blog ?
You might be a geek if ...... You have ever (or probably often) thought, "So many languages and technologies...so little time"

Da ist (leider) sehr wahr. Der Tag müsste länger sein.


Titel: Re: [GOF Side Thread] OO in LS
Beitrag von: Marinero Atlántico am 30.12.04 - 20:45:15
Boar. Methoden-Overloading geht ja auch nicht.
@Mathias und @all: Das könnte auch für Scriptlibraries gelten. Aber anstatt mit if-thens, select-cases herumzugurken, ist es möglicherweise besser die Methoden/Funktionen einfach durchzunummerieren:

Code:
Agent
// Options
Option Public
Option Declare
// Declarations:
Public Class Person
Private DEFAULT_NAME As String
Private DEFAULT_AGE As Integer
Private name As String
Private age As Integer

' UNTERSCHIED zu Java: Nur 1 Constructor erlaubt
Public Sub New ()
Print "Constructor aufgerufen"
DEFAULT_NAME = "No Name"
DEFAULT_AGE = -1
End Sub

' Method-overloading funktioniert auch nicht :-(
Public Function setData () As String
Print "Methode setData() aufgerufen"
Me.name = DEFAULT_NAME
Me.age = DEFAULT_AGE
'setData = "setData verändert Properties dieses Objekts. name=" & Me.name & " age=" & Me.age
setData = "setData hat delegiert:" & setData1(DEFAULT_NAME, DEFAULT_AGE)
End Function

'Method overloading funktioniert nicht :-(. setData(sName As STring, sAge as Integer) ist verboten. Deshalb setData1
Public Function setData1(sName As String, sAge As Integer) As String
Print "Methode setData1(sName As String, sAge As Integer) aufgerufen"
Me.name = sName
Me.age = sAge
setData1 = "setData1 verändert Properties dieses Objekts. name=" & Me.name & " age=" & Me.age
End Function



End Class
// Initialize
Sub Initialize
Dim aPerson As Person
Set aPerson = New Person()
Print aPerson.setData()
Print aPerson.setData1("Meier", 17)

End Sub


Titel: Re: [GOF Side Thread] OO in LS
Beitrag von: MartinG am 30.12.04 - 20:47:15
Zitat
You might be a geek if ...... You have ever (or probably often) thought, "So many languages and technologies...so little time"   

Wooooh - absolut phantastisch ausgedrückt, so was gibt die dt. Sprache einfach kaum her.


Titel: Re: [GOF Side Thread] OO in LS
Beitrag von: TMC am 30.12.04 - 20:49:52
Zitat
You might be a geek if ...... You have ever (or probably often) thought, "So many languages and technologies...so little time"   

Wooooh - absolut phantastisch ausgedrückt, so was gibt die dt. Sprache einfach kaum her.

Und von mir noch gekürzt, sollte eigentlich eine Scherz-Top-Ten sein - aber ich befand diesen Punkt als Tatsache  ;D

Hier noch der Link für die Interessierten:
http://joelitton.net/A559B2/home.nsf/plinks/DOMT-67WJNU


Titel: Re: [GOF Side Thread] OO in LS
Beitrag von: Semeaphoros am 30.12.04 - 20:57:48
Na, Axel, sagen wirs so, Overloading geht nur mit sehr starken Restrictionen. Es macht einem das Leben schon nicht einfach ......


Titel: Re: [GOF Side Thread] OO in LS
Beitrag von: TMC am 30.12.04 - 21:14:31
Ich glaube grundsätzlich gehen die meisten ND-Entwickler einfach anders an Fragestellungen heran.

Z.B. in Java ist es selbstverständlich, Klassen zu schreiben. Nein, nicht nur in Java, sondern in jeder voll objektorientieren Sprache.
In LS - so meine Erfahrung - programmieren die meisten procedure-mäßig (mir fehlt gerade das deutsche Wort dafür). Nur in Ausnahmefällen werden Klassen verwendet. Es gibt da natürlich auch Ausnahmen, aber ich denke im Regelfall ist das so.
Ein Hauptgrund ist wohl, dass LS dies auch zulässt und die IDE nicht auf OO ausgerichtet ist (fehlender Objekt-Browser etc.). Und weil man das halt so gewohnt ist (Faulheit) Und natürlich Unkenntnis von OO.

Ich habe schon oft Code gesehen, welcher ideal in einer Klasse wäre, aber stattdessen wurde einfach
eine Script-Lib erzeugt, die Methods (Functions/Subs) reinkopiert und die "MemberVariablen" halt
global gedimmt. Geht sicherlich auch so. Sowas in eine Klasse umzuschreiben, bedeutet auch erstmal tierischen
Aufwand, da man erstmal alles verwerfen muss und von neu auf aufbauen. Und erst dann die ein- oder andere
Method übernehmen. Thomas V. hatte mich ja mal beim LS-Klassen-Thread "ertappt" wie ich einfach sozusagen als Wrapper über Functions/Subs eine Klasse gemacht habe.  ;D Das war natürlich eine Themaverfehlung und Thomas' Hinweise darauf waren sehr hilfreich.



Titel: Re: [GOF Side Thread] OO in LS
Beitrag von: Marinero Atlántico am 30.12.04 - 21:33:29
OO kann imnsho wirklich dazu dienen code übersichtlicher und leichter änderbar zu machen.
Ich hab z.Zt. Change Projekte zu vielbenutzten Notes Anwendungen (1 sehr groß, die andere klein).
In beiden werden Lotus AdOn Produkte intensiv genutzt (DWF, LEI, L(I)SA). Diese stehen mir in vielerlei Hinsicht mehr im Weg als dass sie eine rasche Anpassung der Anwendungen an veränderte Requirements erleichtern würden.
Vielfach wurden diese Produkte einfach nur so ausgewählt, weil da so sexy Enterprise auf der Packung stand. Ohne dass im Vorfeld wirklich analysiert wurde, inwieweit und wo genau das Zeugs konkret hilft, den Prozess der Anpassung der Anwendung an sich sowieso ständig ändernde Requirements agiler zu gestalten.
Ich glaub, dass diese Branche lernfähig ist. Ich glaub, dass die GoF Pattern an und für sich sowie OO allgemein in die richtige Richtung weisen.
Hier gibts Navigatoren, die mit Hotspots über ein Background-Gif funktionieren. Wenn man da einen neuen Knopp einfügen will, muss man 5 Navigatoren ändern (weil es für jeden Knopf ein anderes Gif gibt, obwohl es für den Anwender wie der gleiche Navigator aussieht).
Wenn die Kundin plötzlich 2-zeilige Beschriftung auf den Knöpfen haben will, muß ich ca. 28 Navigatoren + Hintergrund-gifs ändern, 28x7 Hotspots setzen und lerne nebenbei noch Dinge mit Grafikprogrammen, die mich gar nicht so wahnsinnig interessieren (keine Übertreibung).
Es geht für mich nicht so um OO oder GoF, sondern vielmehr um die Fragestellungen, die die Motivation dieses Zeugs ausmachen. Und die Lösungen, die diese anbieten.

Gruß Axel


Titel: Re: [GOF Side Thread] OO in LS
Beitrag von: Marinero Atlántico am 30.12.04 - 21:47:44
... und jene brilliant geniuses, die mit einem gewaltigen Aufwand brilliant aussehende dhtml, javaScript, css und was weiss ich Web Frontends für im Grunde noch nicht mal schlecht durchdachte Notes CRM Anwendungen gebastelt haben und deren deutsche Vertreter meinten, dass Java "erst so in 8 Jahren aktuell wäre" (vor 2.5 Jahren) und deren Mutter dann 1 Jahr später ganz laut Websphere schrie und das ganze Zeugs war nicht leicht anpassbar (subjektiver Eindruck).
Die Leute stehen in der Disko und die bunten Lampen drehen sich aber darum geht es gar nicht. Aktienkurs 0.16 Euro.
Es ist auch völlig egal, ob die jetzt Websphere, LotusNotes oder Linux schreien, weil die sich sowieso irgendwann von jeder realen Ökonomie abgekoppelt haben.
OO ist aber Ökonomie und nicht irgendeine obskure Wissenschaft.



Titel: Re: [GOF Side Thread] OO in LS
Beitrag von: Marinero Atlántico am 30.12.04 - 22:59:23
Hier ist noch eine Klasse mit einer Menge Constructor overloading und "constructor-chaining" in Java -> Ein Construktor ruft den nächsten auf.
Das gleiche geht in Java auch mit "normalen" Methoden.


Titel: Re: [GOF Side Thread] OO in LS
Beitrag von: koehlerbv am 30.12.04 - 23:40:55
Axel, bleib' doch bitte mal beim Thema !
Schreib' die Theorie (sehr wertvoll), schreib' das praktische in LS, und zeige DANN, wie toll das alles mit Java wäre (wenn die memory leaks nicht wären  ;D )

Bernhard

PS: GOF DP kann nicht nur auf Java beschränkt sein - das gilt sehr unabhängig.


Titel: Re: [GOF Side Thread] OO in LS
Beitrag von: Semeaphoros am 30.12.04 - 23:47:19
Bernhard, ich hab ja vielleicht nur eine halbe Stimme zu dieser Frage, aber lass doch Axel in seinem Tempo und Stil laufen.


Titel: Re: [GOF Side Thread] OO in LS
Beitrag von: koehlerbv am 30.12.04 - 23:54:49
Jo, mach' ich, Jens. Gerade diesmal würde ich mir aber wünschen, das dabei etwas brauchbares herauskommt. Gerade sind wir aber doch wieder bei "Java-heute-das-morgen-jenes" ...

Bernhard


Titel: Re: [GOF Side Thread] OO in LS
Beitrag von: Semeaphoros am 31.12.04 - 00:02:47
Gerade diesmal würde ich mir aber wünschen, das dabei etwas brauchbares herauskommt.

Ich auch ....


Titel: Re: [GOF Side Thread] OO in LS
Beitrag von: animate am 31.12.04 - 12:24:50
Zitat
Gerade diesmal würde ich mir aber wünschen, das dabei etwas brauchbares herauskommt.
Zitat
Ich auch ....

Was wäre denn für euch was brauchbares?


Titel: Re: [GOF Side Thread] OO in LS
Beitrag von: koehlerbv am 31.12.04 - 13:13:12
Ich würde mir einen Bezug von erläuterten DPs mit praktischer Auswirkung / Umsetzung mit LS sehr interessieren - die Vertiefung der Theorie würde das m.E. stark erleichtern.

Bernhard


Titel: Re: [GOF Side Thread] OO in LS
Beitrag von: Marinero Atlántico am 02.01.05 - 11:56:40
wie toll das alles mit Java wäre (wenn die memory leaks nicht wären  ;D )
Auf welche memory leaks beziehst du dich? Die Probleme im Kontext mit LS2J haben null mit Java zu tun sondern mit dem LS2J Framework-Code von Iris.
Das besser-oder-schlechter Thema bringt ihr immer rein. Ich habe lediglich einen sachlichen Vergleich gezogen und der ist imho noch nicht mal schlecht.

Da ich in OO wesentlich mehr Erfahrungen mit Java als mit LotusScript habe und ich bezüglich GoF neben dem Originalbuch von 1994 oder 95 stärker die entsprechende Java Literatur rezipiert habe, ist das normal, dass ich Vergleiche ziehe.
Die GoF Pattern sind nicht Kochrezepte für "richtiges programmieren", sondern mehr so Verdichtungen von Ideen wie man flexibel OO programmiert. Völlig normal, dass ich mir erst einmal die OO-Features von LotusScript anschaue und die mit dem Vergleiche was ich besser kenne.
In jedem Java Buch zu GoF werden auch erst einmal die OO Features von Java analysiert und auch aufgezeigt, wo genau Schwächen sind (z.B. fehlende Mehrfachvererbung).
Die Schwächen haben konkrete Auswirkungen auf die Umsetzungen der Pattern.

Schwächen zu benennen ist auch keine anti-Lotus/pro-Java Propaganda sondern völlig normal. Schliesslich lese ich ja z.B. auch Rod Johnsons fundierte und massive Angriffe gegen J2EE mit großem Interesse.

Ob etwas herauskommt ist Ergebnis der Diskussion. Für den einzelnen mag die Bewertung auch unterschiedlich sein.

Gruß Axel


Titel: Re: [GOF Side Thread] OO in LS
Beitrag von: Marinero Atlántico am 02.01.05 - 12:09:41
Eine weitere Schwäche von OO in LS ist imho, dass das LS-Exception Handling nicht so gut zu OO passt.
Ein Merkmal von OO Methoden im Vergleich von strukturalen Routinen ist, dass sie weniger Zeilen enthalten. Methoden sind kurz.
Dafür gibt es für die gleiche Aufgabe mehr Methoden als Subroutinen.
Objekte kappseln Daten/Verhalten und kommunizieren miteinander. Ein Objekt hält ein anderes Objekt, dass wiederum ein weiteres aufruft. Etc. Auch wenn sich Bernhard jetzt aufregt. Aber es ist wohl eine Tatsache, dass bei einem OO Design die Methoden kürzer sind und pro Feature/Use Case mehr Methoden aufgerufen werden als bei einem Programm, dass unter der Massgabe von funktionaler Dekompisition prozedural programmiert ist.
Nun haben C++ Methoden die Möglichkeiten über das Schlüsselwort throws die Exception Information an die aufrufende Methode weiterzureichen. Dies fehlt in LS OO ein bischen. Sobald ich Exception Handling ernst nehme, muss ich in eine Menge kleiner Hilfsmethoden Exception Code schreiben. Mit throws kann ich das besser zentralisieren.

Ok. In Zukunft beziehe ich sämtliche Vergleiche mit anderen Programmiersprachen auf C++/C#/VB.NET und Python, obwohl ich mich damit nicht so gut auskenne.  ;D

Gruß Axel


Titel: Re: [GOF Side Thread] OO in LS
Beitrag von: TMC am 02.01.05 - 13:12:12
Das besser-oder-schlechter Thema bringt ihr immer rein. Ich habe lediglich einen sachlichen Vergleich gezogen und der ist imho noch nicht mal schlecht.

Also ich finde die sachlichen Vergleiche sehr interessant, danke dafür.
Matthias


Titel: Re: [GOF Side Thread] OO in LS
Beitrag von: Marinero Atlántico am 02.01.05 - 13:24:28
und jetzt nochmal zu den complainers:
1. Ich mache mir diese Arbeit neben einer normalen Tätigkeit. Ich bin schon seit einiger Zeit ein ca. 85% ausgelasteter Consultant. Mit ausgelastet meine ich, dass die Kostenuhr eines Kunden tickt. Billable. Diese 85% schliessen nicht ein:
- interne Veranstaltungen innerhalb von IMG
- extra Zeit, wenn ich Mist in Projekten baue, die nicht dem Kunden angelastet werden können
- Selbststudium
- Zertifizierungen
- Administrativa 
2. Mein Hauptfokus im Selbststudien neben der Arbeit ist stärker auf Java5, Websphere, spring, hibernate, tapestry, Java-Portals, RDBMS und .NET. Ein Herr Bernhard Köhler mag das für nicht zielführend halten. Besonders interessieren tut mich das ehrlichgesagt nicht.   
3. Das so umzusetzen wie ich mir das vorstelle ist eine Menge z.T. sehr langweiliger Arbeit.
4. Ich werde hierfür nicht bezahlt.
5. Ich habe meine eigenen Motivationen, die für mich höchste prio habe. Wenn ich es für sinnvoll halte, erst einmal die OO-Features von LS mit Java zu vergleichen, mache ich das.

Gruß Axel
5.


Titel: Re: [GOF Side Thread] OO in LS
Beitrag von: koehlerbv am 02.01.05 - 13:28:40
Auch wenn sich Bernhard jetzt aufregt. Aber es ist wohl eine Tatsache, dass bei einem OO Design die Methoden kürzer sind und pro Feature/Use Case mehr Methoden aufgerufen werden als bei einem Programm, dass unter der Massgabe von funktionaler Dekompisition prozedural programmiert ist.

Ich glaube, Du missverstehst mich zu 100%, Axel.

Bernhard


Titel: Re: [GOF Side Thread] OO in LS
Beitrag von: Marinero Atlántico am 02.01.05 - 14:36:40
... ich hab eine leichte Befürchtung, dass ich durch die GoF Pattern eher Leute davon abhalte, in LotusScript Klassen zu schreiben. Einfach weil es ziemlich schwierig sein wird, OO Anfänger davon zu überzeugen, dass das eigentlich leichter ist als es zunächst aussieht.
Und nicht alles muß in OO pattern sein. Wenn man für bestimmte Aufgaben mega-Flexibilität nicht braucht, können sie ein Design auch überkomplizieren. Das ist eben ein Abwägen.
Deshalb stecke ich nun ein bischen Arbeit in einfache Klassen, die so etwas wie eine Art Konsole auf Notes-Logging Basis erstellen und die ich für die Beispiele dann benutze.

Glaub nun, dass es für Lotus Entwickler sinnvoll ist so vorzugehen:
Bestimmte festumrissende, typische Lotus Aufgaben in eine Klasse zu packen.
Mein (noch nicht fertiger) code kappselt die folgenden Aufgaben:
- NotesLogging (Alog4.ntf).
- Konfigurationsdokument (statt Profile-Dokument, die ich nicht mag).
Für beides gibt es eine einfache Klasse und NotesLogging benutzt die Konfigurations-Dokument Klasse.

Das werden auch keine endgültigen super duper Frameworkklassen sein, sondern eher einfach. Wer will, kann die dann erweitern.
In gewisser Weise ist das ein Kontrapunkt zu den Pattern, der zeigen soll, dass nicht alles in OO Pattern sein muss. Es gibt aber Bereiche, wo eine hohe Flexibilität völlig Sinn macht und dafür sind dann die Pattern da. Zu erkennen, wo man Flexibilität braucht, ist natürlich ein Lernprozeß.
Imho wird das Thema OO oft immer so gesehen, dass man da am Anfang 120% wissen muß, was hinterher rauskommen soll. So ist das nicht unbedingt. Man plant vielleicht von Hause aus ein bischen mehr als mit strukturaler Programmierung aber nicht zu viel.
Zum Bleistift unterstützt die NotesLog-Klasse aus der Notes-LS-API Logging in ein File/Mail oder Severity/Typ_von_Error_aber_nur_für_serverseitige_Agenten.
Meine Klasse behandelt erstmal nur Logging in eine Datenbank. Sonst wäre es overkill. In der Praxis muss auch zum Bleistift eine Klasse_für_den_Zugriff_auf_Konfigurationsdokumente/Felder nicht direkt von Anfang an die in Stein gemeisselte Wahrheit über den Zugriff auf Konfigurationsdaten in Notes darstellen.

UND: Bereits das simple Strategy-Pattern kann man z.B. ohne Vererbung nicht richtig erklären. Ich glaub das vielen Leuten hier alle Phänomene rund um Vererbung nicht klar sind.
z.B. Was ist overriding? Inwieweit verhalten sich Konstruktoren (sub new) anders als Methoden? Was genau bewirken access modifier wie private/public? Was heisst eigentlich genau Interface und gibt es das überhaupt in LS?, etc. pp.   
Das sind dann ein paar Sachen auf der reinen Sprachebene. Nicht besonders viele, aber sie sind da und relativ einsichtig, wenn man es sich einmal unter Anleitung angeschaut hat.
Vielleicht mögen die entsprechenden Informationen für den Anfänger zunächst endlos viel vorkommen. Sie sind es aber definitiv nicht.

Lohnen tut sich der Aufwand imho schon. In Java/.NET, PHP5 etc. ist ein deutlicher Anstieg des Einbaus von OO features in gängige Programmiersprachen zu erkennen. Auch unter Domino Entwicklern ist ein ansteigendes Interesse an dem Schlüsselwort class zu erkennen. Schliesslich gibt es das schon seit 1998 und vielleicht seit Beginn von LotusScript.
Auf jeden Fall kann man dieses Wissen auch auf andere Programmiersprachen anwenden. Vererbung verhält sich unter C# sehr sehr ähnlich wie in LotusScript. 

Gruß Axel


Titel: Re: [GOF Side Thread] OO in LS
Beitrag von: animate am 02.01.05 - 20:20:06
3. Das so umzusetzen wie ich mir das vorstelle ist eine Menge z.T. sehr langweiliger Arbeit.

hehe, ich habs dir ja gesagt ;D


Titel: Re: [GOF Side Thread] OO in LS
Beitrag von: Semeaphoros am 02.01.05 - 20:38:55
in jedem Falle hochinteressant


Titel: Damien Katz zu GoF - Design Patterns ( zynisch )
Beitrag von: eknori am 01.08.05 - 19:53:12
http://damienkatz.net/2005/07/design_patterns.html


Titel: Oh boy
Beitrag von: flaite am 01.08.05 - 23:41:51
Das schöne wenn man Gurus wie Damien Katz hat ist, dass man sich einfach mit manchen Dingen nicht mehr auseinanderzusetzen braucht  8)
Was entwickelt dieses Talent gerade, Ulrich? Immer noch Couch DB  ???  ;D Zumindest einer der Pattern Autoren Eclipse. Wessen Software wird von mehr Entwicklern benutzt? Aber vermutlich sind die alle auf dem falschen Dampfer und sollten den brillianten Werke von Damien Katz benutzen.
 
Natürlich besteht der Job nicht nur aus Pattern. Und du glaubst nicht wie sehr ich diese Aussage angesichts gewisser Haltungen in meiner weiteren Umgebung unterschreibe. Ich leide defitiv unter Personen, für die Softwareentwicklung nur aus Pattern besteht.

Aber: Sie können aber das Verständnis für eine Menge an Programmieraufgaben erleichtern. Sie machen ausserdem die Diskussion über Designs von Anwendungen einfacher. Ich sehe auch Potential in der Code Generierung unterstützt durch so Zeug wie xDoclet oder Java5 Annotations. Auch hier helfen Patterns sehr.
Die Rolle, die jeder Design Patterns in seiner Entwicklungsarbeit einräumt, bleibt jedem selbst überlassen. Nur darüber lachen kann ich nicht und will ich auch gar nicht.

Wir brauchen effizientere und stabilere Wege um Projekte durchzuführen oder Produkte zu programmieren. Es ist nicht 1986 und der PC ist gerade erfunden worden...

Viele verdiente Leute aus der Domino Community haben diese Aussage in den Kommentaren seines Blogs mehr als relativiert. Sie scheinen sich mit dem Thema beschäftigt zu haben...

Btw. halte ich das Buch als solches auch für "poorly written".

Zitat
Feeding them the idea that even in Domino they can actually learn something new via patterns helps break the cycle of "dense though/bad code"..
:-)
(Kommentar von Wild Bill aus den Kommentaren).
So etwas ähnliches hat mich übrigens überhaupt zu Design Patterns geführt. Schlaue Produktentwickler mit internationalen Treffen und "genialen" Ideen und ich hab in der Zeit mit  0 (besser: -3) Vertriebsunterstützung Projekte für wiederkehrende, mit echtem Geld bezahlende Kunden gemacht. Und ich dachte mir, was die da so wichtig schwafelten, dass kann gar nicht sein. Der Unterschied ist, dass ihr Gerede rein intern war. Die GoF stellten ihre Patterns der Welt zur Kritik hin und sie schufen ausserdem eine Sprache, um über Design überhaupt effizient zu reden. Dies alles völlig in synch mit der Forderung nach intersubjektiver Überprüfbarkeit als Maßstab für rationalen Gehalt von Aussagen durch Poppers Kritischen Rationalismus (so sehe ich es).

Ausserdem bin ich ein großer Freund von Refactorings. Dh. erstmal ein nicht so tolles Design machen und dann schrittweise verbessern (wo sinnvoll). Und ich bin bestimmt um den Faktor 1.4 mal kritischer gegenüber Objekt Orientierter Analyse eingestellt als
(Thomas Völkl + Jens Augustiny) / 2
OOD macht aber imho heftig Sinn an vielen Stellen.

Und natürlich werden Patterns overhyped. Aber machen wir das nicht alle mit unseren kleinen Ideen?

Vorschlag: Trete doch einfach seinem Couch-Projekt als openSoursler bei.  :)
Ich freue mich über Gesprächspartner bezüglich UnitTesting  ;)
http://damienkatz.net/2005/08/c_unit_testing.html

(mal schauen was ich noch so auf diesem blog finde. LoL).

... geh jetzt noch ein bischen in dem Buch über Tesujis lesen. In 4000 Jahre alten chinesisch-tibetanisch-koreanisch-japanischen-siberiakischen Brettspielen gibt es auch so was wie Patterns an mehreren Stellen und gerade in diesem Tesuji-Ding muß ich besser werden. Go ist in vielen Dingen very pattern. Aus verschiedenen Gründen an vielen Stellen näher an der Idee von Design Patterns als Schach. A solution in a context. Z.B. sind aber auch Schacheröffnungen (sizilianisch) in gewisser Weise Pattern. Eine Sequenz von für Schwarz und Weiss jeweils optimalen Zügen.

... vielleicht sind Pattern etwas ganz natürliches.

Axel


Titel: Re: [GOF Side Thread] OO in LS
Beitrag von: flaite am 02.08.05 - 23:10:58
und dieser Hang alles, womit du keine Lust hast dich zu beschäftigen als obertheoretischen Mumpitz darzustellen. Da lache ich noch nicht mal mehr drüber. Es ist einfach unter deinem sonstigen Niveau. Ich kann z.B. auch kein .NET oder Ruby oder funktionale Programmiersprachen. Sage ich deshalb, dass die alle blöd sind?
Java war in den letzten 5 Jahren in vielerlei Hinsicht interessant. Es erfordert eine Menge Arbeit und v.a. muß man am Anfang zugeben, dass man nichts weiss. Diese Neugierde und diese Bereitschaft fehlt mir hier oft (ausser einige Ausnahmen).
Ansonsten ist das ein gutes Notes-Programmierforum.
Lotus geht auf den Java-Weg. Und dieses Java halte ich auch nicht für erfolgversprechend. Meine Javawelt ist aber ganz anders.
Z.B. das halte ich für interessant: http://saloon.javaranch.com/cgi-bin/ubb/ultimatebb.cgi?ubb=get_topic&f=42&t=000574
Und die Lust mich hier zu rechtfertigen, habe ich schon laaaannnnge verloren.  ;D