Então estou a analisar este padrão Solidity onde define uma biblioteca personalizada chamada GoonLib com uma função add para lidar com operações uint256. Depois cria um tipo personalizado NumberoGoono (basicamente um wrapper de uint256) e associa a biblioteca a ele usando a palavra-chave 'using'.
A questão é, você inicializa uma variável de estado interna _number com um valor de 1, depois chama _number.add(5) para executar a função da biblioteca. É uma forma limpa de estender a funcionalidade do tipo sem sobrecarregar a lógica do contrato principal.
Mas honestamente—por que razão estruturá-lo desta forma? Quero dizer, o padrão funciona para operações complexas onde quer manter as coisas modulares. Se estiver a fazer cálculos em lote ou cálculos matemáticos sofisticados, anexar bibliotecas a tipos personalizados mantém o seu código organizado. Para somas simples, no entanto? Parece exagero. Depende do que está realmente a construir.
Ver original
Esta página pode conter conteúdos de terceiros, que são fornecidos apenas para fins informativos (sem representações/garantias) e não devem ser considerados como uma aprovação dos seus pontos de vista pela Gate, nem como aconselhamento financeiro ou profissional. Consulte a Declaração de exoneração de responsabilidade para obter mais informações.
16 gostos
Recompensa
16
5
Republicar
Partilhar
Comentar
0/400
NoStopLossNut
· 5h atrás
Este padrão de ligação de funções de biblioteca parece um pouco de "modularização pela modularização"... Será que uma simples soma realmente precisa de tanta complexidade?
Ver originalResponder0
WhaleInTraining
· 5h atrás
Este NumberoGoono é mesmo fraco, por que complicar tanto uma soma simples?
Ver originalResponder0
UncommonNPC
· 5h atrás
ngl, esta operação avançada usando library é realmente satisfatória em projetos grandes, mas contratos inteligentes pequenos realmente não precisam de tanta complexidade
Ver originalResponder0
StakeHouseDirector
· 5h atrás
ngl, já estou farto deste modo, a soma simples realmente não precisa de tanta complicação
Ver originalResponder0
GasFeeCrier
· 5h atrás
Amigo, esse naming é um pouco engraçado, NumberoGoono... parece o nome de uma meme moeda. Mas a biblioteca using realmente fez um trabalho bem limpo.
Então estou a analisar este padrão Solidity onde define uma biblioteca personalizada chamada GoonLib com uma função add para lidar com operações uint256. Depois cria um tipo personalizado NumberoGoono (basicamente um wrapper de uint256) e associa a biblioteca a ele usando a palavra-chave 'using'.
A questão é, você inicializa uma variável de estado interna _number com um valor de 1, depois chama _number.add(5) para executar a função da biblioteca. É uma forma limpa de estender a funcionalidade do tipo sem sobrecarregar a lógica do contrato principal.
Mas honestamente—por que razão estruturá-lo desta forma? Quero dizer, o padrão funciona para operações complexas onde quer manter as coisas modulares. Se estiver a fazer cálculos em lote ou cálculos matemáticos sofisticados, anexar bibliotecas a tipos personalizados mantém o seu código organizado. Para somas simples, no entanto? Parece exagero. Depende do que está realmente a construir.