Private Methoden selber Basteln

Original von zermelo
Also hier ist mal ein kurzes Beispiel, wie ich das mit dem Pimpl gemeint habe, vielleicht ist dann klarer, dass es vorteilhaft sein kann.

C-Quellcode

1. /* vim: set ft=objc */
2. #include <Cocoa/Cocoa.h>
4. /************************* Versteckter Teil **/
5. @interface Foo_intern : NSObject {
6. }
7. - (int) secret;
8. - (int) number;
9. @end
11. @implementation Foo_intern
12. /* "secret" ist eine echt private Methode, die
13. * von aussen nicht verwendbar sein soll */
14. - (int) secret {
15. return 222;
16. }
17. /* "number" ist eine oeffentliche methode */
18. - (int) number {
19. return [self secret]*3;
20. }
21. @end
23. /************************* Oeffentlicher Teil **/
24. /* Im oeffentlichen header is kein hinweis
25. * auf Foo_intern noetig! */
26. @interface Foo : NSObject {
27. @private
28. id p_;
29. }
30. - (id) init;
31. @end
33. /* in der implementierung kann man einen
34. * header von Foo_intern einbinden, das hier
35. * bekommt ja auch niemand zu sehen */
36. @implementation Foo
37. - (id) init {
38. self = [super init];
39. if(self) {
40. /* interne instanz anlegen */
41. p_ = [[Foo_intern alloc] init];
42. }
43. return self;
44. }
45. /* oeffentliche methoden reichen einfach
46. * nur weiter */
47. - (int) number {
48. return [p_ number];
49. }
50. /* "private" methoden fehlen! */
51. @end
53. /************************* Benutzung **/
54. int main(int argc, char* argv[]) {
55. NSAutoreleasePool *pool = [[NSAutoreleasePool alloc] init];
57. Foo *f = [[Foo alloc] init];
58. NSLog(@"%d\n", [f number]); ///< Wunderbar
59. NSLog(@"%d\n", [f secret]); ///< Funktioniert nicht, crash!
61. [pool drain];
62. return 0;
63. }

Alles anzeigen

Geht bestimmt noch eleganter, ist ja aber auch nur zu illustrationszwecken.

Original von gritsch

Quellcode

1. NSLog(@"%d\n", [[[Foo alloc] init] number]); ///< Wunderbar
2. NSLog(@"%d\n", [[[NSClassFromString(@"Foo_intern") allc] init] secret]); ///< Wunderbar - kein crash ;-)

Original von johannesauer
ich denke es geht einfach drarum, dass verhindert werden sollte, dass man versehentlich falsche Dinge tut. Und genau das finde ich nicht optimal gelöst...aber was solls, nichts ist Perfekt.

Original von zermelo

Original von gritsch

Quellcode

1. NSLog(@"%d\n", [[[Foo alloc] init] number]); ///< Wunderbar
2. NSLog(@"%d\n", [[[NSClassFromString(@"Foo_intern") allc] init] secret]); ///< Wunderbar - kein crash ;-)

Dafür musst du aber wissen, dass es "Foo_intern" gibt, sowie eine Methode namens "secret". Das findest Du natürlich mit class-dump etc. heraus - aber der Durchschnittsnutzer kann nicht "versehentlich" eine private Methode aufrufen.
Üblicherweise sollte man ohnehin selten (überhaupt nicht?) Methoden haben, die nicht vom Zustand des Objektes abhängen. Entsprechend müsste jemand mit bösen Absichten anhand eines class-dumps den ganzen Wrapper nachimplementieren, dann jedoch mitsamt der "privaten" Methoden.

Original von johannesauer
Hi,

ich denke es geht einfach drarum, dass verhindert werden sollte, dass man versehentlich falsche Dinge tut. Und genau das finde ich nicht optimal gelöst...aber was solls, nichts ist Perfekt.

Gruss,
Johannes

Original von johannesauer
Hey da fällt mir beim Thema Kennzeichnen gleich noch was anderes ein. Ist bei euch das #pragma seit Xcode 3.2 auch buggy? Bei mir macht der in der oberen Leiste nur Strunz...

Original von johannesauer
ja, bei 3.1 ging es auch noch bei mir, ist dann wohl n bug

Original von johannesauer
Wie schaut das denn bei anderen Sprachen aus? Mich wundert es, das es das nicht wirklich gibt...die Lösung von Apple über extensions ist ja auch nicht optimal...aber wie gesagt, von der Runtime hab ich keine Ahnung.

Der Grund, warum das nicht geht, ist, dass das ein Seiteneffekt wäre. Der Aufrufer gehört nicht zum Kontext, in dem die Methode läuft.

Hätte das denn negative Auswirkungen?

Original von johannesauer
Hi,

der Anwendungsfall ist kein Spezieller, also kein Framework, ich würde einfach gerne den Zugriff einschränken. Dadurch könnte man einfach solidere Programme schreiben. Man kann natürlich gegenargumentieren und sagen, solange man nicht auf "private" methoden von aussen zugreift, reicht es, diese zu kennzeichnen. Aber das ist kein schöner Ansatz...mir ist einfach konzeptionell nicht klar, warum es geschützte Members gibt, aber keinen geschützten Methoden. Hat da jemand eine Begründung? Ist das konzeptionell so gewollt oder einfach eine Schwäche von Obj-C? Oder würde man sich andere Probleme einhandeln (schlechte Laufzeit, usw)?

Gruss,
Johannes

Original von zermelo

Original von gritsch

Quellcode

1. NSLog(@"%d\n", [[[Foo alloc] init] number]); ///< Wunderbar
2. NSLog(@"%d\n", [[[NSClassFromString(@"Foo_intern") allc] init] secret]); ///< Wunderbar - kein crash ;-)

Dafür musst du aber wissen, dass es "Foo_intern" gibt, sowie eine Methode namens "secret". Das findest Du natürlich mit class-dump etc. heraus - aber der Durchschnittsnutzer kann nicht "versehentlich" eine private Methode aufrufen.
Üblicherweise sollte man ohnehin selten (überhaupt nicht?) Methoden haben, die nicht vom Zustand des Objektes abhängen. Entsprechend müsste jemand mit bösen Absichten anhand eines class-dumps den ganzen Wrapper nachimplementieren, dann jedoch mitsamt der "privaten" Methoden.

Original von johannesauer

ann definiere doch einfach eine Kategorie mit den Methoden in der Implementierungsdatei. Bei der Datenkapselung geht es nicht um hundertprozentig sicheres Verstecken der Daten. Es darum, klare Schnittstellen nach Außen zu schaffen.

ja, so mache ich das auch. Das gibt dann wenigsten ein Warning...

Original von johannesauer
Hey da fällt mir beim Thema Kennzeichnen gleich noch was anderes ein. Ist bei euch das #pragma seit Xcode 3.2 auch buggy? Bei mir macht der in der oberen Leiste nur Strunz...