Get Blogged by JoKi

"The only frontiers are in your mind"
28 | 04 | 2017
Navigation
Syndication
Latest Tweets

Most Read Articles
Article Time Line
About me
Family guy, geek, entrepreneur, software craftsman: Visual FoxPro, C#, SQL Server, MySQL, Linux consultant, conference speaker

Certificates & Awards

Microsoft Certified Professional

Microsoft Specialist - Programming in HTML5 with JavaScript and CSS3 Specialist

Get in touch

Sharing is caring

Recent books


Sponsoring
If you like the information on these pages, your support is highly appreciated.
Thank you very much!
Affiliates

 

Spacer for layout formatting

Kommentar zu 'Parameterobjekte'

User Rating:☆☆☆☆☆ / 0
PoorBest 
Development 25 August 2006 - 

Grundlage für diesen Beitrag liefert der Blogeintrag von Olaf Doschke:

[url=http://blog.dfpug.de/?dnr=2212&id=48]Parameterobjekte[/url] vom 10.06.2006

hier der vollständige Kommentar zu seinem Artikel und meiner 'Weltansicht' zu diesem Sachverhalt:

Hallo Olaf,

ich finde, dass es ein guter Artikel ist.
Wir nutzen das Konzept von Parameter-/Transferobjekten bereits seit Jahren. Dein Ansatz mit den semikolon-separierten Werten (SSV) finde ich soweit auch gut. Bleibt nur die folgende Frage: Wieso Semikolon und nicht Kommata?

Eine weitere Frage, oder besser gesagt ein konzeptioneller Gedankengang, geht dahin, dass ich mich frage, wieso der Aufbau der Klasse in den Aufruf der Funktion per Parameter zu erfolgen hat. Der Hintergrund dabei ist, dass man innerhalb eines Projektes eigentlich eine definierte Anzahl von Transferobjekten besitzt, welche auch eine konstante Schnittstelle besitzen sollten. Mein Problem mit deiner Objektdeklaration beim Aufruf geht in die Richtung der Wartbarkeit des Codes. Vom Ansatz her hätte ich das Interface der Funktion in etwa so aufgebaut:

[code]Function CreateParameterObject(tcToken As String, tcProperties As String, tcTypes As String, tcValues As String) As Object[/code]

Über die Namensgebung brauchen nicht zu sprechen... Bei mir würde die Funktion 'GetParameter()' lauten. Die Idee für den Token zielt dahin, dass ich nun innerhalb der Case-Anweisungen ebenfalls eine Art Factory Design Pattern nutzen kann, welches Zugriff auf fertigdefinierte Klassendefinitionen ermöglicht. Diese könnten etwa in einer MetaTabelle(cToken, cProperties, cTypes, cValues) hinterlegt sein. Damit verbessert sich meiner Ansicht nach die Lesbarkeit und vereinfacht sich die Codepflege. Durch die Verwendung von Konstanten kann sich der Informationsgehalt weiter erhöhen. Hier mal ein wenig Beispielcode:

[code]Local loPosition
m.loPosition = CreateParameterObject("Position")
m.loPosition.Left = 100
m.loPosition.Top = 120[/code]

Die weiteren Konstellationen sind identisch mit deinem aktuellen Entwurf, sofern der erste Parameter leer bleibt. Also, etwa so:

[code]lo = CreateParameterObject("","iX;iY","I;I","20;100")
? lo.iX, lo.iY[/code]

Eine Kombination wäre sicherlich auch denkbar:

[code]#Define PARAMETER_POSITION  "Position"
lo = CreateParameterObject(PARAMETER_POSITION,"","","20;100")
? lo.iX, lo.iY[/code]

In diesem Fall stammen die Informationen zu Eigenschaften und deren Typ aus der Tokenbeschreibung.

Hm, was mir noch aufgefallen ist... Was spricht gegen den Fall 'Pcount() == 0'? In dieser Situation verweigert deine gezeigte Implementierung die Rückgabe eines Empty-Objekts, dass übrigens bereits erzeugt wurde...
So, jetzt bin ich doch bei der genaueren Betrachtung deines Codes und ziemlich neugierig, ob deiner Entscheidungsgrundlagen. Es ist nämlich sehr interessant darüber zu philosophieren. In deiner Routine nutzt du drei Arrays zur Abbildung der drei Stringparameter in Kombination mit dem Alines()-Statements. Die Möglichkeit zur Definition des Delimiters in Alines() ist wirklich sehr praktisch. Dennoch würde ich in diesem Fall auf die Konvertierung von String nach Array verzichten und direkt mit den vorhandenen VFP-Funktionen GetWordCount() und GetWordNum() arbeiten:

[code]For lnIndex = 1 To GetWordCount(tcProperties, ";")
AddProperty(loObject, GetWordNum(tcProperties, lnIndex, ";"))
EndFor[/code]

Es ist reine Neugierde, wieso du mit Arrays arbeitest. Interessiert mich wirklich sehr. Ich denke, dass ich mal beide Varianten auf Performance (Anzahl der Durchläufe in konstanter Zeitspanne) prüfen werde.


Bis denne, JoKi


blog comments powered by Disqus
 
Spacer for layout formatting