Hiho!

Nur eine winzige Frage von mir heute abend

Nehmen wir an, es existiert eine Klasse...

...und diese Klasse bekommt einen Nachfolger - und der soll seine Objekteigenschaft nicht published zur Schau stellen. Ich hab das Problem im moment so gelöst:

Kompilieren tut der Code, aber da nirgendwo in der Unit in "Jugendfrei" geschrieben, oder daraus gelesen wird (der Zugriff innerhalb des Objektes erfolgt halt direkt auf FJugendfrei), gibts 'ne Compilermeldung. Symbol deklariert, aber nie verwendet...
Muss ich mit der Warnung leben, oder kann ich die beseitigen?

Jugendfrei ist doch das genaue Gegenteil von Freizügig ^^

und was du vorhast, würde ich nicht machen. Du verletzt da ein Prinzip der OOP, dessen Name ich grad nicht kenne ;D

Im Grunde aber sagt es, dass jede Unterklasse nach außen hin wie die Oberklasse aussehen soll. Und da kann man dann nicht einfach die Property in der Sichtbarkeit reduzieren.

Ich würde es daher umgekehrt machen:

D.h. die Oberklasse hat die schlimme Property selbst protected, sodass man von außen nicht dran kommt. Und erst die Unterklassen machen die Property dann einem größeren Publikum zugänglich.

Grüße,
~ Frase

_________________
"Für kein Tier wird so viel gearbeitet wie für die Katz'."

Mist, ich wusste, ich hätte was verdreht

Ja, ich hab mir gedacht, dass das nicht gerade OOP ist...aber es war einfach irgendwie naheliegender, da ich von der Klasse, die bei dir der Vorgänger ist nur genau zweimal ableiten würde - einmal zu der Klasse, in der ich die Eigenschaften "verstecken" will, und einmal zur Basisklasse so ziemlich aller anderen Objekte, die ich brauche...

Aber gut, dann werd ich mich wohl die Tage mal hinsetzen und das andersrum realisieren...im Moment bin ich eh damit beschäftigt, dafür zu Sorgen, dass ich ein Ergebnis zu Gesicht bekomme...könnte sein, dass ich heut Abend doch noch ne Frage stell

Das geht auch nicht.

Eigentlich müssten da Fehler oder Warnungen kommen.

Du kansnt die Sichtbarkeit nicht reduzieren. Bestenfalls fügst du eine neue Eigenschaft hinzu, welche genauso heißt, aber geringere Sichtbarkeit hat. Aber die alte Eigenschaft müsste dann zusätzlich noch da sein.

_________________
Blog: kevin-fleischer.de und fbaingermany.com

Normalerweise definiert man in der Basisklasse die Propertys die man später in abgeleiteten Klassen entweder braucht oder eben nicht braucht eben als protected. Damit sind sie zwar nicht ganz weg, können aber erstmal nicht benutzt werden. (Bis sie eben in einer abgeleiteten Klasse public werden).

//edit
in der VCL werden solche Basisklassen z.B. mit "Custom" gekennzeichnet (TCustomEdit etc)

_________________
Bringe einen Menschen zum grübeln, dann kannst du heimlich seinen Reis essen.
(Koreanisches Sprichwort)

Ich weiß jetzt nicht, ob Delphi/Pascal hier anders ist.
Aber eigentlich ist es doch so:

private="nur diese eine Klasse kann es sehen/nutzen",
protected = "Für alle versteckt außer den Klassen die davon abgeleitet sind",
public = "Free 4 all"

_________________
Blog: kevin-fleischer.de und fbaingermany.com

Nein das ist in Delphi genau so, worauf willst du hinaus?*

*) Naja es ist in Delphi leider nicht so, weil auch private und protected deklarierte Sachen zugreifbar sind solange man in der selben Unit ist (was meistens auch noch der Fall ist), deshlab gibts hier noch strict private. Aber das ist ne Spitzfindgkeit und man sollte auf private Sachen daher nicht zugreifen)

_________________
Bringe einen Menschen zum grübeln, dann kannst du heimlich seinen Reis essen.
(Koreanisches Sprichwort)

das man innerhalb einer Unit auf alles zugreifen kann finde ich in Delphi ziemlich doof. Ich arbeite trotzdem immer nach dem Prinzip wies gedacht ist, aber ich kennen von der Arbeit auch viele Leute, die das für ihre Code-Konstrukte missbrauchen. Das ist die sorte von Menschen, die eine Oberfläche nur durch Events programmieren und Variablen-Namen aus 2 Buchstaben bilden. Dazu kommt dann noch dass Polymorphie geächtet wird,. Es wird lieber mit riesiegen If-Verschachtelungen geprüft um welche Klasse es sich handelt, damit das Event mit dem richtigen Verhalten antwortet.

Das ist grausam! Ebenso gehört das Verstecken von Eigenschaften zu den sogenannten "Code-Smells", da ein Objekt in der OOP nur erweitert, aber nie eingeschränkt werden darf. Wie meine Vorredner schon sagten muss man sich an der Stelle überlegen, ob besagte Eigenschaft evtl. durch ein Interface an die Klasse vererbt wird, oder man die Klassenhierarchie in der betroffenen Klassenfamilie einmal überdenkt.

Vielleicht sind die oben beschriebenen Methoden ein einfacher und schneller Weg ein Programm lauffähig zu bekommen, aber für die Weiterentwicklung, Wiederverwendbarkeit und Überarbeitung ist es absolut ungeeignet solches vorgehen an den Tag zu legen und dezimiert die gewonnene Zeit in der Entwicklung durch das nötige Bugfixing um mindestens das 3-fache. Außerdem wird es schwer für außenstehende oder neue Entwickler den Code zu verstehen, wodurch wieder Einarbeitungszeit nötig wird.
Schreibt jemand solchen Code, weil er gar nicht möchte, dass ein andere Entwickler im gleichen Team seine Ansätze verfolgen kann, dann gehört dieser Mensch weniger in die Softwareentwicklung sondern eher in die Politik oder das Banken-Management.

_________________
Klar Soweit?

Sellmann, nichts für ungut, aber ich glaube diese "Brandrede" war jetzt etwas übertrieben
Ich geh mal davon aus, dass die meisten Leute hier im Forum sich deiner Bemerkungen durchaus bewußt sind, zumindest würde ich sie mal so einschätzen.
Von mir muss ich sagen, dass ich mit OOP noch nicht wirklich vertraut bin, ich programmiere zwar schon recht lang, aber die Vorzüge von Objektorientierung nutze ich eigentlich erst, seit ich mich auch mit OpenGL beschäftige, also noch nicht wirklich lang. Ich bin mit den Do's und Donot's also noch nicht wirklich vertraut - und außerdem Autodidakt, hab also nie Informatik studiert oder so...darum frag ich ja hier nach. Und als man mir dann sagte, um "wirklich" OOP zu bleiben müsste ich es andersrum realisieren, hab ich beschlossen dass so zu tun. Auch wenn das die eigentlich für dieses WE geplante Aktualisierung meines (angestaubten) Projektthreads um ein paar weitere Tage (oder Wochen, weil das dann wieder mit meinem Studium kollidiert) herrausschiebt...

[Nachtrag]
Mich interessiert jezze allerdings die Frage, wie 'ne Oberfläche mit reduziertem Bedarf an Events aussieht. Bei mir siehts im Moment so aus, dass wenn ein z.B. MouseDown auf die Form erfolgt, in der meine Oberfläche ihren Renderkontext hat, im OnMouseDown der Form dieses Event an nen GUI-Manager weiter gereicht wird...der findet dann anhand der Mauskoordinaten raus, ob und welches Element der Oberfläche getroffen wurde und ruft dessen OnMouseDown-Ereignis auf, wenn zu gewiesen.
Offen gestanden, verliere ich anhand so viel Weitergereiche von Events teilweise auch etwas den Überblick und bin längere Zeit beschäftigt, Fehler zu finden, wenn welche auftauchen. Wie macht mans also geschickter? Bei meinen Recherchen bin ich über Messages gestolpert, aber deren Verwendung ist mir im Moment noch schleierhaft. Hat da jemand nen Link zu nem Tutorial oder sowas?

Du könntest dir dazu mal die Patterns der "Gang of four" (siehe Wikipedia) anschauen.

Aber dein Vorgehen, entspricht dem dass ich in meiner GUI umgesetzt habe.

Eigentlich ist es gar nicht kompliziert dadurch, sondern eher strukturiert.
Du musst nur 2 Sachen sicherstellen bei dem von dir gebrachten Beispiel:

1. Du musst zuverlässig den Eventempfänger identifizieren können.
2. Du musst zuverlässig die Eventkette* auslösen/verarbeiten können die dann entsteht.

Der Rest ist lokale implementation am jeweiligen Objekt.

Eventkette benötigt man z.B. beim Klick da müssen so sachen wie onExit(altes Objekt), onEnter(neues Objekt), onClick(neues Objekt) gemacht werden.

_________________
Blog: kevin-fleischer.de und fbaingermany.com

Naja, aber es muss doch möglich werden, zumindest von der Form auf die ich rendere unabhängig zu werden, was diese Ereigniskette angeht. An irgendeinem Punkt muss Windows / das Betriebssystem doch der Form sagen "Hey, auf dich wurde geklickt", bevor die sagt "Lieber GUI-Manager, auf mich wurde geklickt". Da muss ich doch einhaken können, und die Benachrichtigung von Windows direkt an den GUI-Manager weiterleiten können....
Ich meine, das ist ja auch nicht im Sinne eines Entwicklers, der irgendjemand anderen an seinem Projekt teilhaben lassen will. Es wäre doch viel eleganter, wenn man sagen könnte "Du rufst TGUIManager.Create auf, nachdem du irgendwo nen Renderkontext erstellt hast und bist fertig!", statt "Du musst TGUIManager.Create aufrufen und danach die Ereignisse OnMouseMove, OnMouseDown, OnMouseUp, OnKeyPress, OnKeyDown und OnKeyUp der Komponente, auf der sich dein Renderkontext befindet an den GUI-Manager weiterleiten..." oder?

Naja du könntest deine TGUiManager von TWinControl ableiten. Dann müsste der Programmierer nur noch ne Komponente auf seine Form ziehen, und sicherstellen dass sie stets den Fokus hat. In der Komponente würde dann nicht die Events benutzt, sondern die entsprechenden Methoden überschrieben (z.B. MouseDown).

_________________
Bringe einen Menschen zum grübeln, dann kannst du heimlich seinen Reis essen.
(Koreanisches Sprichwort)

Das geht aber nicht anders. jedenfalls wenn du Plattformunabhängig arbeitest.

Sonst müsstest du WindowsAPI Zauberrei machen und an den WindowsMessages lauschen und dann auf die Reagieren die da kommen.

Hab ich noch nie gemacht. Keine Ahnung wie das geht. Aber unter Linux müsstest du das dann wieder umschreiben. Bzw. abhängig von der Oberfläche. Ich denke KDE, Gnome, XFCE etc. werden jeweils andere Nachrichtencodes verwenden.

Irgendwo ist nunmal der Übergang zum Betriebssystem.

_________________
Blog: kevin-fleischer.de und fbaingermany.com

Meep, Gnome, KDE & Co benutzen keine unterschiedlichen Nachrichtencodes. Die haben mit dem Kram garnix am Hut. Das ist Sache von Xorg und damit ziemlich standardisiert.
Dennoch würde ich keine Lösung implementieren, wo sich der GUIManager sofort alle Events krallt. Schließlich kann es sein, dass du bspw. Mausbewegungen noch für andere Dinge brauchst, Spielfigur z.B..

Die Lösung, dass man dem GUIManager die Events recht selektiv zukommen lässt, ist denke ich garnicht so schlecht.

greetings

_________________
If you find any deadlinks, please send me a notification – Wenn du tote Links findest, sende mir eine Benachrichtigung.
current projects: ManiacLab; aioxmpp
zombofant network • my photostream
„Writing code is like writing poetry“ - source unknown

„Give a man a fish, and you feed him for a day. Teach a man to fish and you feed him for a lifetime. “ ~ A Chinese Proverb

Hach...irgendwie unzufriedenstellend, aber das mit der Plattformunabhängigkeit ist antürlich irgendwo schon ein Argument.
Jetzt würde mich aber schon noch interessieren, wie die "Eventkatastrophe" aussehen würde, über die Sellmann sich aufgeregt hat ^^
P.S.: Irgendwie hab ich das Gefühl, machen immer eine Entwicklung durch, während der der Inhalt zunehmend von der Überschrift abweicht.