Merkwürdiger Source Code? Kann mir das jemand erklären?

[negaH]

Das wird so sein

Aber betrachte es mal aus Sicht einer "Arbeitsorganisation" oder aus Sicht einer "Teamarbeit". Der Source soll nicht Selbstbefriedignung sein, also kein Selbstzweck sondern verfolgt eine klare Zielsetzung um ein Problem zu lösen. Jede zusätzliche und nicht notwendige Information in der Schnittstelle zum Source erhöht den Arbeitsaufand für diejenigen die diesen benutzen müssen. Also mehr an Dokumentation, mehr zum Lernen, weniger Zielorientierung, höhere Fehleranfälligkeit sprich Fehlbenutzungen weil die Schnittstelle verwaschen, also unklar ist. Das Geheimnis liegt in der Restriktion, man beschränkt sich auf notwendige Grundfunktionen, bekommt so eine Standardisierung hin und schwups wird die spätere Benutzung stark ökonomisiert. Das ist doch recht simpel einzusehen da wir als Menschen doch in allen Bereichen nach diesem Muster vorgehen, oder ?

PASCAL ist viel restriktiver als C zb. und exakt deshalb lieben wir es doch auch. Restriktiver heist eben nicht weniger Universalität sondern mehr, da eine sauber durchdachte Schnittstelle wie ein Baukastensystem viel variantenreicher sein wird.

Hm, sowas kann man eigentlich nur Auge in Auge diskutieren. Auf alle Fälle programmiere ich schon ziemlich lange professionell und meistens in Teams, ich kann nur aus meiner Erfahrung erzählen.

Gruß Hagen

[negaH]

Zitat:

Und nun gibt der Architekt den Leuten die die Interfaces implementieren sollen die implementierung der Properties vor. Mindestens 3 von den Entwicklern werden fluchen.

Viel schlimmer ;(

Da der Architekt unantastbar ist werden diese 3 garnichts sagen, ja sie fluchen im Bestfall jeder für sich, im schlechtesten Falle bilden sie eine versteckte Front gegen den Architekten. Aber konstruktiv wird es meistens nie. Auf alle Fälle sinkt die innere Motivation im Team. Denn die Hauptursachen für verwaschene Interfaces, für ellenlange Source mit wenig Nutzen sind

- Profilierungssucht
- Egosimus
- Selbstüberschätzung

Dabei habe ich die Erfahrung gemacht das gut durchdachte und einfach gehalten Schnittstellen das Gegenteil bewirken. Hat also der Architekt seine Aufbae gut gemacht so werden die Leute zusätzlich motiviert, sie machen weniger Fehler, man arbeitet effizienter und auch effektiver.

Mal ehrlich, wir alle arbeiten doch lieber mit Komponneten etc.pp. die exakt das machen was wir benötigen und das auch noch effizent und korrekt. Grausig sind doch die Kompenenten die tausende Properties haben die versprechen alles zu können und dann im Detail doch immer nur die Hälte ermöglichen.

Gruß Hagen

[Kedariodakon]

Hä

Die Propertys sind doch nur Show, die müssen doch im zu implementierenden Object gar nicht vorhanden sein...
Die sind nur fürs Interface...

Und dort werden sie eindeutig durch die Set-/Get-Funktionen festgelegt...
Nunja, jeder hat halt seine Meinung zu diesem Thema, wie dem auch sein, ich Egoist find sie praktisch

Bye Christian

[himitsu]

Zitat von negaH:

Na ist doch ein ideales Beipsiel !!
Du hast Liebe als Variable erst NACH procedure Kind deklariert, ergo wolltest du auch das procedure Kind keinen Zugriff darauf bekommen darf. Denn du willst ja Fehler vermeiden oder ? Du kompilierst es und stellst fest geht nicht, ups, darf Kind Liebe benutzen, nein? gut eine Fehler, ja? machtnichts schreiben wirs um

joo, es war ja nur weil da vorne wer meinte man habe auf alle lokalen Variablen Zugriff ... und dem ist ja nicht so ^^

[mandoki]

Uff.. da hab ich ja ne heisse Diskussion losgetreten.

Vielleicht sollte man den Titel umbenennen in:
Diskussion zum Thema: Nested Functions/Procedures

Ist auf jeden Fall sehr interessant und lehrreich, die verschiedenen Meinungen zum Thema.

Gruß mandoki

[negaH]

Zitat:

Die Propertys sind doch nur Show, die müssen doch im zu implementierenden Object gar nicht vorhanden sein...
Die sind nur fürs Interface...

Ja, und das ist ja gerade das Problem von dem ich rede. Die Getter/Setter Methode einer Property in einem Interface sind ebenso öffentlich sichtbar wie die Property selber. In einem Interface gelten 2 goldende Regeln

1.) alles ist öffentlich -> logisch ist ja ein abstraktes Modell so ein Interface
- keine differenzierte Sichtbarkeitsregeln, es gibt also kein private/protected/public etc.pp
- somit alles public

2.) ein Interface sollte niemals Aussagen über die reale Implementierung treffen -> also vollständig abstrakt
- ein Interface kann durch verschiedene impelementierende Klassen benutzt werden
- ein Interface kann sogar über mehrere Klassen implementiert werden, dh. gleich mehrere Klassen stellen die reale Impelementierung des Interfaces dar
- die reale Implementierung eines Interfaces kann durch den Implementor weiter delegiert werden
- die Lebenszeit der implementierenden Klassen eines Interfaces ist undefiniert, großer Unterschied zu Klassen
- ein Interfaces muß garnicht durch eine Klasse implementiert werden, es geht auch procedural oder sonstwie, eben weil das Interface keinerlei Aussagen trifft was, wann, wo, wie und womit real implementiert ist
- ein Interface kann nur eine Teilmenge der Funktionalität einer komplexen Klasse exportieren, also Reduktion der verfügbaren Funktionalität einer Klasse nach aussen und das sogar noch auf eine Art&Weise das man eben nicht wissen kann wie es impelmentiert wurde, also abstrakt. Das heist man kann über Interfaces quasi zu einer bestehenden Klassenhierarchie eine komplett umstrukturierte und unabhängige Parallel-Hierarchie aufbauen, einfach nur durch reine Deklarationen. So gesehen sind Interfaces sowas wie ein Translator von Denkmodellen, sie translieren von einem Denkmodell einer Klassenstruktur in Programmierspache A in ein komplett anderes Denkmodell in Sprache B. Und das war die Ursache dafür das es überhaupt Interfaces heutzutage gibt.

Das alles sind ja gerade die Vorteile der Interfaces.
Man kann sich diese verbauen wenn man dieses gute Konzept aufweicht, eben bei Properties in Interfaces.
Getter/Setter Methoden einer Property gehören zur Klasse der implementierenden Methoden, sie sind nicht abstrakt noch losgelösst sondern implementieren konkret die Funktionalität zu einer deklarierten Property, ergo sie exportieren Delphitypische Sprachkonstrukte. Damit widersprechen sie dem Konzept der vollkommenen Abstraktion die Interfaces erreichen sollen.

Klar soweit ?

Gruß Hagen

[negaH]

Zitat:

joo, es war ja nur weil da vorne wer meinte man habe auf alle lokalen Variablen Zugriff ... und dem ist ja nicht so ^^

Ich weis es ist aber ein gutes Beispiel an dem man zeigen kann was "Sichtbarkeit" bedeutet und wie man es als Instrument für besseren Sourcecode aktiv einsetzt. Man deklariert also nur diejenigen Variablen vor einer Funktion die diese auch nutzen darf. So verhindert man planmäßig Fehler.

Und um "Sichtbarkeit" als Instrument für guten Sourcecode gehts hier in der Diskussion:

Sichtbarkeit bei:

- Funktionen, sprich "nested Functions" als die am unsichtbarsten modularen Konsrukte der MP
- Interfaces und die Sichtbarkeit von nicht abstrakten Getter/Setter Methoden durch die Verwendung von Proprties in der OOP

Gruß hagen

[negaH]

Wenn ich die Properties bei Interfaces entwickeln sollte dann so:

Delphi-Quellcode:

type
  IMyInterface = interface
    function XYZ: HResult;

    property Name: INameProperty; 
  end;

  INameProperty = interface(IAbstractProperty)
    function Getter: Variant; default;
    function Setter(Variant); default;
  end;

Dh. im IMyInterface wird keinerlei Aussage darüber getroffen wie die Property Name real zu implementieren ist. Es seht nur der Typ der Property drinnen und selbst dieser könnte abstrakt sein, sprich Variant.

Das implementieren Property Interface könnte nun separat impelemntiert werden oder auch gleich von der selben Klasse die auch IMyInterface impleentiert. Auf alle Fälle ist alles abstrakt deklariert im Interface und um Abstraktion geht ja dabei.

Es gibt aber schon andere Wege über TypeLibs, dispatchable Interfaces IDispatch und den ganzen Kram. Damit versucht man im Grunde exakt das zu machen. Dh. es gibt schon klare Standards wie man eine Property über dispid und TypeLibs in ein Interface deklariert. Das unterscheidet sich natürlich vom Delphi Property Konzept.

Gruß Hagen