He visto preguntas similares, pero ninguna responde por qué las personas usan contratos abstractos . Vengo de un entorno de JavaScript que no es OOP, por lo que tengo algunos problemas para entender estas cosas.
De los documentos :
pragma solidity ^0.4.0;
contract Feline {
function utterance() public returns (bytes32);
}
contract Cat is Feline {
function utterance() public returns (bytes32) { return "miaow"; }
}
¿ Cuál es el beneficio de definir Felineaquí en primer lugar? El único beneficio en el que puedo pensar es si tiene muchos tipos diferentes de felinecontratos y quiere asegurarse de que todos incluyan, utterance()supongo. Pero realmente no puedo pensar en tales situaciones...
¿Hay beneficios que no estoy viendo? Viniendo de mi entorno, querrás evitar cosas como esta, donde solo quieres un plátano pero un gorila lo sostiene, junto con toda la jungla ...
PD: La cuestión no es la diferencia entre interfaces y contratos abstractos.
No está obligado a crear un contrato abstracto para realizar una implementación. Solidity no es un lenguaje fuertemente OOP, incluso si algo se deriva de OOP (interfaz, herencia, contratos abstractos).
Entonces, dichos contratos abstractos le darán otro nivel de abstracción y la razón principal para usarlo es asegurarse de que quien implemente el contrato seguirá su definición (como describió en su publicación) y proporcionará funcionalidades comunes a los contratos secundarios.
Puede encontrar muchas publicaciones en stackoverflow que describirán los beneficios. Aquí y aquí por ejemplo.
De una de esas publicaciones:
Las clases abstractas son una buena opción si desea proporcionar detalles de implementación a sus hijos, pero no desea permitir que se cree una instancia de una instancia de su clase directamente (lo que le permite definir parcialmente una clase).
Los métodos abstractos son útiles de la misma manera que lo es definir métodos en una interfaz. Es una forma en que el diseñador de la clase Abstracta dice "cualquier hijo mío DEBE implementar este método".
"Si un contrato hereda de un contrato abstracto y no implementa todas las funciones no implementadas mediante la anulación" de los documentos de solidez. Entonces, un contrato abstracto asegúrese de que su contrato secundario implemente las funciones del contrato base. https://docs.soliditylang.org/en/v0.6.2/contracts.html#abstract-contratos
mesqueeb
mirg
Felinesquieres que sigan la misma estructura. Luego, define el contrato abstracto y todos sus contratos secundarios lo seguirán. Hay casos en los que un contrato abstracto puede ser un estándar de facto (mira el token ERC20), pero esa es otra historia ( theethereum.wiki/w/index.php/ERC20_Token_Standard )Pablo Razvan Berg