Besserer Ausdruck für Verschachtelter Aufruf

Alles, was nicht direkt mit Python-Problemen zu tun hat. Dies ist auch der perfekte Platz für Jobangebote.
Antworten
Benutzeravatar
Sr4l
User
Beiträge: 1091
Registriert: Donnerstag 28. Dezember 2006, 20:02
Wohnort: Kassel
Kontaktdaten:

Ich habe mal eine simple Frage, bzw würde ich gerne eure Meinung hören wie man etwas formulieren sollte.
  • Wie beschreibe ich das verhalten von dem Aufruf A()? Eine Rekursion ist es nicht, weil es sich nicht selbst aufruft?!

    Wie nenne ich das? Verschachtelter Aufruf? Verkettung? Gibt es bessere Namen die man in der Literatur verwendet?

    Wie nenne ich das Gegenteil X()+Y()+Z()?
Danke.

Code: Alles auswählen

def A():
    return 1+B()
    
def B():
    return 2+C()

def C():
    return 3

def X():
    return 1

def Y():
    return 2

def Z():
    return 3

print A()

x = X()
y = Y()
z = Z()

print x+y+z
BlackJack

@niederrheiner: Ich würde es verschachtelter Aufruf nennen. Oder das sich Funktion `A()` (direkt) auf Funktion `B()` abstützt.

Was *ist* das „Gegenteil von X()+Y()+Z()“? Ich kann mir darunter nichts vorstellen.
Benutzeravatar
Sr4l
User
Beiträge: 1091
Registriert: Donnerstag 28. Dezember 2006, 20:02
Wohnort: Kassel
Kontaktdaten:

BlackJack hat geschrieben:@niederrheiner:
:D
BlackJack hat geschrieben:Ich würde es verschachtelter Aufruf nennen. Oder das sich Funktion `A()` (direkt) auf Funktion `B()` abstützt.
Danke.
BlackJack hat geschrieben:Was *ist* das „Gegenteil von X()+Y()+Z()“? Ich kann mir darunter nichts vorstellen.
Das habe ich falsch formuliert. Es sollte was ist das Gegenteil von A(). Also ein nicht verschachtelter Aufruf. Für den Fall das es für so verschaltete Aufrufe einen "Fachbegriff" gibt.
BlackJack

Sr4l hat geschrieben:
BlackJack hat geschrieben:@niederrheiner:
:D
:oops:

Also einen Begriff hätte ich dafür nicht parat. Ausser vielleicht „besser testbar“, denn genau aus dem Grund sollte man das erste Aufrufmuster nach Möglichkeit vermeiden, weil man immer nur diese ganze Aufrufhierarchie testen kann, aber nicht die drei Aufrufe isoliert. Das wäre nur möglich wenn die Funktion ebenfalls als Argument übergeben würde. Der Stil ist in Python aber nicht üblich, das ist aber etwas das man bei JavaScript häufig antrifft.
Dav1d
User
Beiträge: 1437
Registriert: Donnerstag 30. Juli 2009, 12:03
Kontaktdaten:

BlackJack hat geschrieben:Also einen Begriff hätte ich dafür nicht parat. Ausser vielleicht „besser testbar“, denn genau aus dem Grund sollte man das erste Aufrufmuster nach Möglichkeit vermeiden, weil man immer nur diese ganze Aufrufhierarchie testen kann, aber nicht die drei Aufrufe isoliert. Das wäre nur möglich wenn die Funktion ebenfalls als Argument übergeben würde. Der Stil ist in Python aber nicht üblich, das ist aber etwas das man bei JavaScript häufig antrifft.
Das geht schon als Whitebox-Test, üblicherweise mit einem Mocking-Framework, z.B. Mockito unter Java oder iirc hat Python 3 auch ein Mocking-Framework in der Std.Lib.
the more they change the more they stay the same
BlackJack

@Dav1d: Ich ging dabei von Tests aus, die ohne ”Magie” auskommen in dem man ”Innereien” durch Mock-Objekte ersetzt. Mit dem Argument ist am Ende fast jeder Code testbar. ;-)
Benutzeravatar
Sr4l
User
Beiträge: 1091
Registriert: Donnerstag 28. Dezember 2006, 20:02
Wohnort: Kassel
Kontaktdaten:

BlackJack hat geschrieben:Ausser vielleicht „besser testbar“, denn genau aus dem Grund sollte man das erste Aufrufmuster nach Möglichkeit vermeiden, weil man immer nur diese ganze Aufrufhierarchie testen kann, aber nicht die drei Aufrufe isoliert. Das wäre nur möglich wenn die Funktion ebenfalls als Argument übergeben würde. Der Stil ist in Python aber nicht üblich, das ist aber etwas das man bei JavaScript häufig antrifft.
Danke.

Genau deshalb suche ich einen Begriff damit ich Variante A() ablehne kann. Mir geht es nicht direkt um Code, ich habe eine Kommunikation über mehrer Maschinen und diese brauchen für die Antwort etwas Zeit. Bei einer solchen Verkettung bekomme ich erst eine Rückmeldung wenn die Nachrichten am Ende angekommen sind und die Antworten wieder zurücklaufen.

In einer solchen Struktur auf Fehler zu regieren ist nicht gerade einfach, es ist schwer zu testen, und anstatt mehrer kleiner Teilerfolge oder -fehlschläge, bekomme ich am Ende eine Antwort wie weit meine Kette gekommen ist. Und kann dann nach mehreren Sekunden / Minuten sagen Tada fertig oder bei Schritt 4 gab es ein Problem das nicht behoben werden konnte. Ich fahre als blind.
Sirius3
User
Beiträge: 17711
Registriert: Sonntag 21. Oktober 2012, 17:20

@Sr4l: dafür gibt es aber keinen Begriff. Es ist ganz normal, dass Funktionen andere Funktionen aufrufen. Man sollte halt nur nicht unsinnig verschachteln. Die beiden Begriffe ist also unsinnig Verschachtelt und sinnvoll Verschachtelt.
Was das Beispiel jetzt mit verteilten Rechnungen zu tun hat, ist mir unklar. Ein entfernter Aufruf unterscheidet sich von einem lokalen von außen betrachtet nicht. Es können zusätzliche Ausnahmen ausgelöst werden, wie Timeout oder NichtErreichbar. Und so findet man auch die Stelle, an der ein Problem auftritt. Man schaut sich einfach den Traceback der auftretenden Exception an.
Dav1d
User
Beiträge: 1437
Registriert: Donnerstag 30. Juli 2009, 12:03
Kontaktdaten:

BlackJack hat geschrieben:@Dav1d: Ich ging dabei von Tests aus, die ohne ”Magie” auskommen in dem man ”Innereien” durch Mock-Objekte ersetzt. Mit dem Argument ist am Ende fast jeder Code testbar. ;-)
Oder man machts wie in Java und übertreibt unsinnig mit Inversion of Control (wobei Dependency Injection wohl der bessere Name ist) und macht einen "newDateService" der dann so aussieht:

[codebox=java file=Unbenannt.java]
interface INewDateService
{
Date newDate();
}

class NewDateService implements INewDateService
{
@Override
public Date newDate()
{
return new Date();
}
}
[/code]

Und injected den dann überall :twisted:

oder man patcht den ClassLoader mit PowerMockito

Ontopic: Ich war lange Zeit der Meinung dieses übertriebene "magische" Whitebox-Testing ziemlich sinnlos ist, musste aber in letzter Zeit feststellen dass es extrem praktisch sein kann. Selbst sehr komplexe Code-Teile, die über mehrere Ebenen verteilt sind, kann man durch Whitebox-Testing sehr effektiv testen. Man mockt sich einfach alles externe weg und testet nun wirklich nur was der Code macht, macht man das für alle Dependencies der Funktion hat man sehr einfach sehr viele Fälle abgedeckt. Wobei das in Python (meiner Erfahrung nach) eher unüblich ist.
the more they change the more they stay the same
Antworten