Funktionen vereinen -> Fachbegriff?

[Nightmare85]

Hallo,

meine Frage ist eher allgemein und bezieht sich daher nicht auf eine spezielle Programmiersprache.
Der Code unten ist als "Pseudocode" zu interpretieren.

Wenn ich beispielsweise 2 Schaltflächen erstelle und beim Klicken logischerweise eine Funktionalität haben möchte,
mache ich es so, dass ich mehrere Funktionen zu einer vereine und diese den Buttons zuweise.
Beispiel:

Button1:
Zahl_Inkrementieren("l")

Button2:
Zahl_Inkrementieren("r")

Zahl_Inkrementieren(position)
{
  Funktion_1()
  Funktion_2()
  Funktion_3(position)
}
Funktion_1()
{
  ...
}
Funktion_2()
{
  ...
}
Funktion_3(position)
{
  ...
}

Ich könnte die Funktion Zahl_Inkrementieren natürlich weglassen und direkt die 3 Funktionen den Buttons zuweisen.
Allerdings sagt mir mein Bauchgefühl, dass das Zusammenfassen meist übersichtlicher ist.

Gibt es für diese Zusammenfassung einen Fachbegriff?
Die Funktion Zahl_Inkrementieren macht selber eigentlich nichts, außer die 3 Funktionen aufzurufen,
die die eigentliche Arbeit tun.

Und ist diese Art der Programmierung überhaupt empfehlenswert?
(Bin selbst eher Anfänger und lege daher besonders viel wert auf Übersichtlichkeit.)

Grüße

 

[Zonk91]

Ich finde es, so wie du es gemacht hast durchaus sinnvoll. Durch das Auslagern von Logik in Funktionen bringst du noch etwas mehr Semantik in den Code(gutes Naming vorrausgesetzt). Außerdem sind die einzelnen Funktionen als kleinere Einheit besser testbar und vermeidet Codeduplizierung.

Ob es für "Zusammenfassung" einen Fachbegriff gibt, weiß ich nicht. So eine Änderung würde ich klassisch als Refactoring bezeichnen.

 

[new Account()]

Allerdings sagt mir mein Bauchgefühl, dass das Zusammenfassen meist übersichtlicher ist.

Gibt es für diese Zusammenfassung einen Fachbegriff?

Funktionskomposition

 

[RalphS]

Wie man's nennt ist imo eigentlich relativ egal... wichtig ist nur, daß man einen Ansatz hat.

Oberstes Credo: Wenn man Code kopiert, macht man etwas falsch.

<== Das kann man leider nicht oft genug betonen, weil man ständig Verstöße dagegen sieht.

Was bleibt sind Empfehlungen fürs Refactoring, sprich den Entwurf von Funktionsobjekten, und, obwohl dies ja prinzipiell ausgeschlossen wurde, auch eine Ausrichtung auf die ART der Programmierung. Unabhängig von PS gibt es ja noch den funktionalen Ansatz, den imperativen Ansatz, den prozeduralen Ansatz und den objektorientierten Ansatz (unter anderen).

Wichtig fürs Refactoring ist imo zuallererst, daß man atomisch vorgeht: Eine Funktion tut eine Sache.
Beispiel: Ich drücke den Knopf, das Dokument soll gespeichert und geschlossen werden. Das sind zwei Aktionen. Es gibt also eine Funktion Save und eine Funktion Close, und unter der Annahme, daß es die Funktion SaveAndClose auch gibt, steht dort nichts drin außer dem Aufruf dieser beiden Funktionen.

Nicht atomisches Vorgehen heißt, daß man zB eine Funktion Save hat und eine Funktion SaveandClose, und dann hat man die Wahl zwischen Pest wie "ich kopiere den Inhalt von Save nach SaveAndClose" (und mache was grundlegend falsch) und Cholera wie "also eigentlich will ich das Dokument nur schließen, aber nicht speichern.... kann ich aber irgendwie nicht, weil Close nur in Verbindung mit Save implementiert ist".


Für das oben angeführte Szenario ist wohl was Objektorientiertes ideal, da man dort mit Ereignissen arbeiten kann. Was dazu führt, daß man sich seine Funktionen (hier: Methoden) weiter verschlanken kann.

Pseudomäßig gibt es immer einen Handler mit der Signatur void Handler(object sender, eventargs e) was durchaus auch genauer spezifiziert sein kann, je nach Art der möglichen Ereignisse.

Also hat man einen Button. Der hat ein Ereignis Klick. Dem weist man eine Methode mit o.g. Signatur zu, die man natürlich vorher erst gebaut haben muß.

IN dieser Methode hat man dann (ggfs per Cast) im ersten Parameter (hier: sender) die auslösende Instanz. Sprich, den exakten Button, der da gedrückt wurde. Wenn man dem dann im Quellcode eine eindeutige Kennung (ID) gegeben hatte, kann man darüber prüfen, welcher Knopf denn gedrückt wurde. Und der zweite Parameter (hier: eventargs) kann verwendet werden um rauszukriegen exakt was passiert ist. Bei Klick kann man ja noch zwischen Links und Rechts und Doppelklick unterscheiden. Oder es war eine andere als die beiden Standard-Maustasten. Dann kann man dafür sorgen, daß mit Linksklick der Button aktiviert wird, mit Rechtsklick auf denselben Button aber ein Kontextmenü mit weiteren Optionen angezeigt wird.

Natürlich muß man auch ein bissel gucken, was praktikabel ist und wo es zuviel wird. Für das Beispiel Inkrement oben kann man funktional drei Blöcke ausmachen: A, Wert holen; B, Wert bearbeiten; und C, Wert zurückschreiben. Das wären also intuitiv drei Funktionale. Bringt nur nix, wenn jedes Funktional aus fünf Zeichen besteht und sich das auch nie ändern wird - dann hätte eine Funktion gereicht.
Hat man aber zB den beliebten Taschenrechner mit X vielen Knöpfen, dann wird es irgendwann durchaus sinnvoll, dedizierte Get und Set Funktionen zu haben (nenn ich mal so). Dann kann man die nämlich zentral verwalten. Buttons kennen nur Text und bei vielen Buttons in einem Taschenrechner müßte ich sonst so oft wie es Buttons gibt immer denselben Code kopieren für "versuche aus dem Text irgendwie eine Zahl herauszulesen". Code kopieren => schlecht, also eine Methode die das für mich macht. Dasselbe andersherum insbesondere dann, wenn die Programmiersprache mich nicht "Zahl" an "String" zuweisen läßt => das wäre meine "Set" Methode, die das konvertiert und dann an die richtige Stelle schreibt.