Umas possibilidade é escolher a arma. Por exemplo, ter um método que define se a arma é machado, espada, clava, etc. o mesmo para mago se ele cura ou ataca (pode escolher elementos com fogo, raio, agua,...) e para arqueiro se usa besta ou arco e aí ter atributos de distância e força. Nossa, explosão de ideias.
Nesse caso vc seria obrigado a implementar tudo que há em IHabilidade. Desse modo, vc não teria a mobilidade de criar várias habilidades fora do Guerreiro e "passa-las" ao guerreiro. O pattern prioriza essa separação
Pq aí dentro da classe Guerreiro vc teria que implementar os métodos abstratos de iHabilidade. Mas como vc implementaria, se vc não sabe qual a habilidade e nivel de poder q vc quer ter no guerreiro? E se vc quisesse criar varios guerreiros com habilidades e niveis distintos? ... Isso cairia no mesmo problema do inicio, de "engessar" a classe. Pra isso ele permite que essas habilidades sejam passadas como parametro, pq por fora da classe vc tem pleno controle das habilidades que o seu guerreiro vai ter, sem precisar modificar nada na classe Guerreiro.
@ProgramadorLhama a função comportamento não poderia receber como parametro o comportamento e com isso evitar criar todas as outras classes? Como pode ver nos videos anteriores, estou iniciando agora os estudos sobre esse assunto, então sorry qualquer pergunta "boba". É que ver essa repetição para cada classe, me fez pensar que poderia ter uma generica onde para o comportamento eu pudesse passar "espada", "arco e flecha" (ou até mesmo a frase do print como ditatica) por exemplo ao inves de ter essas repeticoes para cada uma. Faz sentido??
Um pouco de cuidado aí: se vc tem uma classe genérica, vc tem todos os comportamentos atrelados a um único ponto (a classe genérica). Se vc tem classes criadas separadamente, vc tem comportamentos totalmente separados. Se vc for fazer alteração futura em código, qual tu acha mais fácil atuar? Tudo junto ou tudo separado? Eu prefiro separado...
Me tira uma dúvida, no arquivo run. Como eu crio o código que irá interagir com as classes. Ali você você passou as instância, se fosse um código, quando eu clico para abrir, o que terá ali? um função, uma class com método estáticos. Não sei se você me entendeu. Pq estudando poo sempre vejo a galera ensiando e instanciando objeto manualmente.
gostei muito me ajudou a melhorar meu código, entretanto estou tendo problema na hora de importar os modulos para o run.py, ele nao consegue encontrar as classes dentro de src, eu vi q vc coloca um "." antes do src e dos modulos quando vai fazer indicar de onde vem o import, mas nao ta rolando kk tem algum video que explora imports?
Para criação de diretórios (ou módulos), vc precisa colocar o __init__.py nas pastas. Eu particularmente uso esse arquivo para exportar elementos de dentro de uma pasta e "encapsular" funcionalidades. Logo, basta só referenciar a pasta e não o arquivo (ex: src/something) Provavelmente esse esteja sendo seu problema
"maRchado" kkkkkkkkkkk. Excelente a explicação! O padrão Strategy é mesmo incrível! Já virou meu xodó.
Tamo junto parceiro. Fico feliz em ajudar!
Galera nem like deixa nessa masterpiece. ta doido melhor tuto que achei.
Vlw mesmo parceiro! Espero que lhe ajude! :)
Rapaz, excelente explicação e demonstração. Adotei essa playlist pra mim. Continue com o bom trabalho!!
Lucas muito obrigado mesmo cara! Tamo junto nessa caminhada! :)
Umas possibilidade é escolher a arma. Por exemplo, ter um método que define se a arma é machado, espada, clava, etc. o mesmo para mago se ele cura ou ataca (pode escolher elementos com fogo, raio, agua,...) e para arqueiro se usa besta ou arco e aí ter atributos de distância e força. Nossa, explosão de ideias.
Essa é a ideia! Já pode criar seu jogo RPG agora kkk
"solução cachorra" aksoaksokasokasoka
muito ótima. Agora posso dormir em paz aqui kk
"Solução cachorra" kkkk muito bom, ótimo conteúdo
Top demais!!
Você poderia passar a classe IHabilidade como classe pai de Guerreiro ao invés de passar como um parâmetro? Qual a vantagem e desvantagem disso?
Nesse caso vc seria obrigado a implementar tudo que há em IHabilidade. Desse modo, vc não teria a mobilidade de criar várias habilidades fora do Guerreiro e "passa-las" ao guerreiro. O pattern prioriza essa separação
Pq aí dentro da classe Guerreiro vc teria que implementar os métodos abstratos de iHabilidade. Mas como vc implementaria, se vc não sabe qual a habilidade e nivel de poder q vc quer ter no guerreiro? E se vc quisesse criar varios guerreiros com habilidades e niveis distintos? ... Isso cairia no mesmo problema do inicio, de "engessar" a classe. Pra isso ele permite que essas habilidades sejam passadas como parametro, pq por fora da classe vc tem pleno controle das habilidades que o seu guerreiro vai ter, sem precisar modificar nada na classe Guerreiro.
@ProgramadorLhama a função comportamento não poderia receber como parametro o comportamento e com isso evitar criar todas as outras classes? Como pode ver nos videos anteriores, estou iniciando agora os estudos sobre esse assunto, então sorry qualquer pergunta "boba". É que ver essa repetição para cada classe, me fez pensar que poderia ter uma generica onde para o comportamento eu pudesse passar "espada", "arco e flecha" (ou até mesmo a frase do print como ditatica) por exemplo ao inves de ter essas repeticoes para cada uma. Faz sentido??
Um pouco de cuidado aí: se vc tem uma classe genérica, vc tem todos os comportamentos atrelados a um único ponto (a classe genérica). Se vc tem classes criadas separadamente, vc tem comportamentos totalmente separados. Se vc for fazer alteração futura em código, qual tu acha mais fácil atuar? Tudo junto ou tudo separado? Eu prefiro separado...
Me tira uma dúvida, no arquivo run. Como eu crio o código que irá interagir com as classes. Ali você você passou as instância, se fosse um código, quando eu clico para abrir, o que terá ali? um função, uma class com método estáticos. Não sei se você me entendeu. Pq estudando poo sempre vejo a galera ensiando e instanciando objeto manualmente.
Iae lhama! Então quando eu for fazer a inversão de dependência, eu vou estar fazendo este design pattern?
A ideia é a mesma sim. A única diferença é o motivo de se usar. Mas, pode-se resumir esse pattern como a inversão mesmo
gostei muito me ajudou a melhorar meu código, entretanto estou tendo problema na hora de importar os modulos para o run.py, ele nao consegue encontrar as classes dentro de src, eu vi q vc coloca um "." antes do src e dos modulos quando vai fazer indicar de onde vem o import, mas nao ta rolando kk tem algum video que explora imports?
Para criação de diretórios (ou módulos), vc precisa colocar o __init__.py nas pastas. Eu particularmente uso esse arquivo para exportar elementos de dentro de uma pasta e "encapsular" funcionalidades. Logo, basta só referenciar a pasta e não o arquivo (ex: src/something) Provavelmente esse esteja sendo seu problema
@@ProgramadorLhama Acho que entendi, deu certo aqui muito obrigado