Zum einen macht es Sinn, Methoden einen sprechenden Namen zu geben. Der Methodenname muss dabei beschreiben was die Methode macht, und es tunlichst vermeiden funktionalitäten zu verstecken.
Beispiel:
class Items : IItems<IItem> {
/* Manipulator -> Verb */
void Remove(IItem item) {...
/* Builder -> Noun */
Item Item(ISelector selector) {...
/* A code smell -> does too many things */
Item ChangeDeliveryDateAndSaveItem(IItem source) {...
}
Den Gedanken im Kopf, passiert es, das Methoden sehr lange Namen bekommen können. Wenn man nun als Entwickler in der Situation ist und das bemerkt, fängt man an zu überlegen, wie man ihn kürzen kann.
Manchmal löst man das Problem durch bessere Namensgebung, aber oftmals liegt das Problem nicht im Methodennamen, sondern in der Klasse selbst. Muss man mehrere funktionalitäten Beschreiben, ist es vermutlich die Klasse die zu viele Dinge tut. Im Beispiel oben, führt das zu mehreren Problemen:
1. IItems wird um methoden immer weiter erweitert und damit erschwert sich deutlich der Zukünftige testaufwand der Klasse.
2. Die Anpassungen an IItems sind spezifisch für den Fall, und eine Wiederverwendung ist immer unwahscheinlicher um so mehr Methoden enthalten sind. Im schlimmsten Fall führt es dazu, dass das Interface mit vielen NotImplementedExceptions genutzt wird.
3. Wird die Klasse bzw. das Interface um weitere Methoden erweitert, so leidet auch die Wartbarkeit.
Oftmals sind es Methoden mit Rückgaben, die erklären was verändert wird und was zurückgegeben wird.
Hier auch mit alternativen:
String StringWithRemovedCarriageReturnAndLineFeeds() {...
/* Alternative I */
new ModifiableString().RemoveAll(„\r\n”)
/* Alternative II */
new ClearedString {
public ClearedString(
string source,
string valueToRemove
) { ...