zerm schrieb:
Amin Negm-Awad schrieb:
Es geht aber nicht darum, dass du einmal -aendereTitelUndStarteBerechnung hast und einmal aendereTitelOderMachFooUndStarteBerechnung, also verschiedene Tätgkeiten. Das würde ich auch in zwei Methoden packen.
Es geht darum, dass ich immer eine Berechnung starte, jedoch den Wert woanders her erhalte. Das wäre also in etwa: -macheBerechnungUndNehmeTitel und -macheBerechnungUndNehmeStringValue. Und da siehst du schon, dass die Tätigkeit (macheBerechnung) den Schwerpunkt bildet und die verschiedenen Quellen unnatürlich sind. (Weil Berechnungen nur selten davon abhängen, woher du deine Parameter nimmst.) Du wirst deinem Buchhalter ja auch nicht eine neue Ausbildung spendieren, weil er einmal die Zahlen bei dem Vertrieb und ein anderes mal bei der Produktion abfragen muss.
Ein gutes Argument. Aber in diesem Fall:
Ich bin gewöhnt, prinzipiell zu kapseln. Das heisst, wenn meine Berechnung nur ein String bekommt, soll sie gar nicht wissen, wo der herkommt. Optimal wäre, wenn die Klasse gar nicht weiss, was ein NSButton überhaupt ist. Muss sie ja auch nicht.
Hier könnte man dann meinetwegen eine Kategorie einfügen, die diese Klasse auf Titel von Buttons erweitert. Und eine, die auf sonstwas erweitert.
Also zunächst einmal scheint mir hier wieder ein Anwendungsfall konstruiert zu werden, der überhaupt keinen Sinn ergibt.
Warum sollte ich mittels eines Buttons eine Berechnung durchführen und dafür seinen Titel nutzen wollen?
Nicht einmal der Taschenrechner berechnet beim Drücken auf [1] irgend etwas. Und wenn ich auf [+] drücke, passiert auch erst mal nix. Wenn ich dann nach einer weiteren Ziffernfolge auf [-] drücke, wird addiert...
Ja, natürlich kann man dann folgendes tun:
C-Quellcode
- -(IBAction)berechneMitOperation:(id)sender
- {
- [[self mutableOperationsArray] addOperationMatchingString:[sender title]];
- if([[self mutableOperationsArray] count] > 1)
- {
- // Voll die Berechnung mit der beim letzten Methodenaufruf gespeicherten Rechenoperation
- [[self mutableOperationsArray] removeObjectAtIndex:0];
- }
- }
Diese Methode werde ich aber niemalsnienicht aufrufen, wenn ich meine zu berechnende Formel einfach in ein Textfeld eintippe...
Wann immer ich selbst und höchstpersönlich etwas mit meinen Objekten tue, also einen genauen Überblick über meine Arbeit habe, solange nutzt mir der ganze Kram nix.
Interessant und hilfreich wird es erst dann, wenn ich keine Kontrolle mehr über die übergebenen Objekte habe. Zum Beispiel, wenn ich Objekte aus einer Sammlung bekomme, die Objekte unterschiedlichen Typs aufnimmt.
Nehmen wir beispielsweise eine eigene Implementierung im Stile der iTunes Bibliothek.
Ich habe irgendwo in dem ArrayController der Datasource ein Objekt markiert und möchte dieses abspielen.
C-Quellcode
- //Musike reagiert hier auf -playFromStartPosition:enableFade:
- // Filmchen reagiert hier auf -playFromStartPosition:enableFullscreenMode:
- // PDF reagiert hier auf -open
- // Dynamisch typisiert
- -(IBAction)playSelectedItem:(id)sender
- {
- id item = [dataSourceDelegate selectedObject];
- if([item respondsToSelector:@selector( playFromStartPosition:enableFade: )])
- {
- [item playFromStartPosition:0.00 enableFade:YES];
- }
- if([item respondsToSelector:@selector( playFromStartPosition:enableFullscreenMode: )])
- {
- // Später starten, ist immer ein doofes Intro vorgeschaltet. ;)
- [item playFromStartPosition:3.5 enableFullscreenMode:NO];
- }
- if([item respondsToSelector:@selector( open )])
- {
- [item open];
- }
- }
Wie das jetzt mit statischer Typisierung aussehen soll weiß ich gar nicht so genau... Vermutlich irgendwie so in der Art:
C-Quellcode
- -(IBAction)performWithItem:(id)sender
- {
- RootItem* item = [dataSourceDelegate selectedObject];
- if([item isKindOfClass:[MusicItem class]]) {
- [(MusicItem*)item playFromStartPosition:0.00 enableFade:YES];
- }
- if([item isKindOfClass:[MovieItem class]]) {
- // Später starten, ist immer ein doofes Intro vorgeschaltet. ;)
- [(MovieItem*)item playFromStartPosition:3.5 enableFullscreenMode:NO];
- }
- if([item isKindOfClass:[PDFItem class]]) {
- [(PDFItem*)item open];
- }
- }
Packen wir jetzt noch ein ImageItem mit Methode -open hinzu, brauchst du bei der dynamischen Variante mit id wie schon erwähnt nix tun, die statische Variante musst du erweitern. Packst du hingegen noch ein BookItem mit der Methode -read dazu, musst du wieder beide Varianten anpassen.
Im zweiten Beispiel weiß deine Methode immer, mit wem sie es zu tun hat. Im ersten Beispiel hingegen nicht. Da weiß sie nur, mit welcher Nachricht das Objekt etwas anfangen kann
Wie würdest du das 'starr' typisieren wollen, vor Allem in Hinblick auf die Kapselung?
Meiner Meinung nach ist das erste Bibliothekenbeispiel schon sehr gut gekapselt.
«Applejack» "Don't you use your fancy mathematics to muddle the issue!"
Iä-86! Iä-64! Awavauatsh fthagn!
Iä-86! Iä-64! Awavauatsh fthagn!
kmr schrieb:
Ach, Du bist auch so ein leichtgläubiger Zeitgenosse, der alles glaubt, was irgendwelche Typen vor sich hin brabbeln. :-P
an.
