![]() |
Private-Attribute wirklich sichtbar?
Ich bin es eigentlich aus anderen Sprachen gewohnt, dass ein Attribut, dass ich innerhalb einer Klasse als private deklariert habe, für andere Klassen nicht sichtbar ist. Jetzt bin ich doch eigentlich der Meinung, dass das ja nun etwas mit sauberer Kapselung blablabla zu tun hat.
Da war ich doch schon immer etwas irritiert, das in der Codevervollständigung meine als private deklarierten Attribute aus anderen Klassen auftauchten, was ich immer als Bug hingenommen und die entsprechenden Getter und Setter benutzt habe, um jetzt festzustellen, dass in Delphi als private deklarierte Attribute nicht wirklich private, sondern innerhalb einer Unit ziemlich public sind. Ist das wirklich so? Lässt Delphi wirklich so eine SCH***** zu oder sollte ich doch etwas Vertrauen zu den Borlandern haben und sie haben es inzwischen behoben (ich code aktuell noch mit D5 Enterprise). Bitte sagt mir, dass Delphi nicht so einen Scheiß zulässt und es nur ein Bug ist!?! Hoffungsvoll... Andi |
Re: Private-Attribute wirklich sichtbar?
Zitat:
Zweitens: Innerhalb einer Unit ist es laut OOP (nicht Delphi!) zulässig auf private Elemente anderer Klassen der gleichen Unit zuzugreifen. Damit handelt Delphi korrekt. Sollte es Dich jedoch beruhigen, so kannst Du ab Delphi 8 strict private (und strict protected) nutzen, um auch dieses zu verbieten. ...:cat:... |
Re: Private-Attribute wirklich sichtbar?
Delphi kennt das Friend - Konzept wie z.B. C++ nicht.
Dafür haben alle Klassen in der gleichen Unit eine Friend-Beziehung zueinander. Man hätte hier vielleicht ein neues Schlüsselwort (friend) einführen können. In der Praxis ist die Delphi Lösung aber meist ausreichend, da Klassen, die in der gleichen Unit liegen meist eine enge Beziehung haben und "Freunde" zueinander sind. |
Re: Private-Attribute wirklich sichtbar?
Das ist sicher kein bug, sondern vermutlich absicht. Das sichtbarkeits-konzept ist aber hauptsächlich für benutzer dieser unit oder komponente ausgelegt, die diese felder dann eben nicht sehen können. Und den programmierer einer unit ist es wohl grad noch zu zutrauen, das er mit seinen feldern keine schei*** baut.
Andererseits ist es manchmal auch extrem praktisch, wenn mehrere klassen zu einem system gehören und genau wissen was sie tun, dann spart man sich den umweg über die getter und setter. Wenn du es so schlimm findest, dann nimm delphi 8, da gibt es dann noch strict private. |
Re: Private-Attribute wirklich sichtbar?
@sakura
Das Wort SCH**** diente nur als Stilmittel; ich beschimpfe ausdrücklich niemanden. Pardon. Zitat:
@shmia Das Friends-Konzept IMHO ist auch nur ein Kompromiss an die Programmierbarkeit. Gib einem Programmierer die Chance zu schlusen und er wird sie doch irgendwann nutzen. Ich wünsche mit eigentlicht nur private ist private, nach dem Motto: Ein bisschen schwanger gibt es nicht. @maximov Würde gern umsteigen, kann ich mir aber nicht aussuchen, das D5 Enterprise hier leider Fact ist. Das mit strict private hört sich aber nach der Erfüllung meiner Wünsche an. @all Weitere Antworten muss ich leider auf Morgen verschieben. Gruß Andi |
Re: Private-Attribute wirklich sichtbar?
und protected hilft dir nicht?
|
Re: Private-Attribute wirklich sichtbar?
Zitat:
|
Re: Private-Attribute wirklich sichtbar?
Nuja damit hätte er zumindest die unsichtbarkeit in anderen klassen gewährleistet oder sehe ich das falsch ?Und ob er Kindklassen hat oder nicht, weiss ich net. Kenne aber auch nur wenige Beispiele wo ich Variablen in kindklassen absolut nicht haben will.
Aber egal...war ja nur so ne idee... |
Re: Private-Attribute wirklich sichtbar?
protected ist private + die Sichtbarkeit in Kindklassen :wink:
|
Re: Private-Attribute wirklich sichtbar?
jo habsch gerade auch nomma nachgelesen..
dachte zuerst nur in kindklassen... man lernt nie aus :oops: Naja delphi eh komisch in sachen oop, genauso wie VB auch (naja ok vb war schlimmer) |
Alle Zeitangaben in WEZ +1. Es ist jetzt 04:00 Uhr. |
Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024-2025 by Thomas Breitkreuz