Welche Vorteile bieten abstrakte Verträge?

Ich habe ähnliche Fragen gesehen, aber keine beantwortet, warum Menschen abstrakte Verträge verwenden . Ich komme aus einem Nicht-OOP-JavaScript-Hintergrund, daher habe ich einige Probleme, diese Dinge zu verstehen.

Aus den Dokumenten :

pragma solidity ^0.4.0;
contract Feline {
    function utterance() public returns (bytes32);
}
contract Cat is Feline {
    function utterance() public returns (bytes32) { return "miaow"; }
}

Welchen Vorteil hat es Felineüberhaupt, hier zu definieren? Der einzige Vorteil, den ich mir vorstellen kann, ist, wenn Sie viele verschiedene Arten von felineVerträgen haben und sicherstellen möchten, dass sie alle enthalten sind, utterance()denke ich? Aber solche Situationen kann ich mir wirklich nicht vorstellen...

Gibt es Vorteile, die ich nicht sehe? Aus meinem Hintergrund kommend, möchten Sie solche Dinge vermeiden, wo Sie nur eine Banane wollen, aber einen Gorilla bekommen, der sie hält, zusammen mit dem gesamten Dschungel ...

PS: Die Frage ist nicht der Unterschied zwischen Schnittstellen und abstrakten Verträgen.

Antworten (2)

Sie müssen keinen Vertrag erstellen und abstrahieren, um eine Implementierung durchzuführen. Solidity ist keine starke OOP-Sprache, auch wenn etwas von OOP abgeleitet ist (Schnittstelle, Vererbung, abstrakte Verträge).

Diese abstrakten Verträge geben Ihnen also eine weitere Abstraktionsebene, und der Hauptgrund für ihre Verwendung besteht darin, sicherzustellen, dass derjenige, der den Vertrag implementiert, seiner Definition folgt (wie Sie in Ihrem Beitrag beschrieben haben) und den untergeordneten Verträgen gemeinsame Funktionalitäten bietet.

Auf Stackoverflow finden Sie zahlreiche Beiträge, die die Vorteile beschreiben. Hier und hier zum Beispiel.

Aus einem dieser Beiträge:

Abstrakte Klassen eignen sich gut, wenn Sie Ihren Kindern Implementierungsdetails zur Verfügung stellen möchten, aber nicht zulassen möchten, dass eine Instanz Ihrer Klasse direkt instanziiert wird (wodurch Sie eine Klasse teilweise definieren können).
Abstrakte Methoden sind genauso nützlich wie das Definieren von Methoden in einer Schnittstelle. Auf diese Weise kann der Designer der Abstract-Klasse sagen: "Jedes Kind von mir MUSS diese Methode implementieren".

Cool! Stackoverflow habe ich nicht überprüft! Was meinen Sie mit „sicher sein, wer den Vertrag ausführt“ Wie/warum würde jemand versuchen, meinen Vertrag umzusetzen?
Ist nicht jemand anderes als du. Wenn Sie verschiedene haben, Felinesmöchten Sie, dass sie der gleichen Struktur folgen. Dann definieren Sie den abstrakten Vertrag und alle Ihre untergeordneten Verträge werden ihm folgen. Es gibt Fälle, in denen ein abstrakter Vertrag de facto ein Standardvertrag sein kann (siehe ERC20-Token), aber das ist eine andere Geschichte ( theethereum.wiki/w/index.php/ERC20_Token_Standard ) .
Update 2020: Es gibt ein neues Abstract- Schlüsselwort, das bei der Definition eines Abstracts vor die Vertragsdefinition gesetzt werden kann.

„Wenn ein Vertrag von einem abstrakten Vertrag erbt und nicht alle nicht implementierten Funktionen durch Überschreiben implementiert“ aus solidity docs. Stellen Sie also bei einem abstrakten Vertrag sicher, dass Ihr untergeordneter Vertrag Funktionen des Basisvertrags implementiert. https://docs.soliditylang.org/en/v0.6.2/contracts.html#abstract-contracts