J'ai le code suivant:
protocol Component {
associatedtype SomeStep: Step
var step: SomeStep { get }
}
3 Réponses :
Avez-vous vraiment besoin de tous les protocoles? Vous pouvez le faire avec des valeurs associées:
Oui, j'ai besoin de tous les protocoles, vous pouvez considérer cela une expérience. J'essaie de comprendre si ce que j'ai fait comme une solution de contournement est mauvais, pourquoi cela fonctionne, si des extensions de protocole font le polymorphisme de classe, etc.
L'erreur est de la manière dont les protocoles sont définis.
étape de type étape (un protocole)
- La variable
étape est redéclamé dans le composant de protocole
- Alors, lorsque vous définissez
Somecomponentoftypea Le compilateur donne une erreur car il trouve étape de type stepa par composait mais Pas de type étape par composant protocole.
- Lorsque vous définissez la définition d'associé, vous utilisez ensuite des génériques pour spécifier que variable dans
composant peut être de n'importe quel type après le protocole étape
- Alors maintenant, la variable étape du composant satisfait le point 4 et sans erreur.
Et donc, ce que vous avez enfin utilisé avec des génériques est la bonne approche pour un tel cas, si vous vouliez vraiment redéclaré la variable pas dans composenta pour un type spécifique stepa .
Ok, je comprends votre réponse, mais comment se fait-il que le compilateur me permet de redéclaré l'étape variable dans le protocole Componenta et Composentb? Cela me permet, le problème n'apparaît que lorsque certaines struct / classe tentent d'implémenter Componenta / ComponentB, alors il ne peut pas le comprendre ..
True, car le cas d'un protocole est techniquement toujours valable. Seulement lorsqu'un protocole est suivi à travers une structure / classe sera-t-il, il sera possible de la mettre en œuvre non? C'est pourquoi l'erreur alors :)
Protocole peut être adopté par une structure ou une énumération, de sorte qu'il ne fait pas de polymorphisme de classe, car ils ne peuvent pas être hérités. C'est aussi l'une des raisons pour lesquelles pourquoi Retour à votre question, vous avez défini une variable avec le même nom que le protocole parent dans le sous-protocole, mais le type est différent , cela est autorisé car le protocole n'est pas un type concret. Mais ce n'est pas une surcharge de type, car le protocole fonctionne différemment de la classe. Dans ce cas, vous feriez mieux d'utiliser des génériques, ce qui est sortie: associé existe. associé . Mais si vous devez utiliser ces trois protocoles, il vous suffit de déclarer le sous-protocole. somecomponentoftypea n'autorise que stepa type.
Merci pour l'explication, je devrais également préciser que je voulais le faire de manière à ce que celui qui soit conforme au protocole composéa ou composantb, sera obligé d'avoir une propriété de type STEPA, respectivement belleb. Cela serait-il possible?
Utilisation du type associé ressemble à la bonne solution ici car essayez de cacher une propriété en l'ourdlant avec un avec le même nom ressemble à un mauvais design
Désolé mais je ne suis pas suivi, c'est la bonne solution, mais aussi en ayant le même nom le fait ressembler à un mauvais design?
J'étais un peu clair désolé. Je voulais dire que la mise en œuvre initiale, nuire à la propriété, était une mauvaise conception