Digamos que queira fazer o seguinte:
Gostaria de fazer 20 classes filhas que herdam propriedades da classe veículos.
É aconselhável fazer isso?
Qual a linguagem?
Melhor fazer uma interface ou uma classe abstrata para isso, não, @romulopb?
Outra coisa, dê uma olhada no primeiro design pattern do “SOLID”, o Single-responsibility principle
1 curtida
Eu vou precisar que seja com Python pois ela já dá a estrutura que preciso em outras áreas.
Eu sempre quis me atrever a fazer algo profissional, mas sempre fiz minhas “gambiarras” para resolver os problemas. Você me recomenda estudar que princípios para começar certo:
SOLID, Clean Code, TDD?
Obrigado.
De início eu recomendo, muito, manter o princípio KISS (Keep It Simple Stupid), ajuda muito a não inventar moda e você entender os princípios básicos. Clean Code é outro que vai te ajudar bastante, ainda mais quando os seus projetos começarem a escalonar.
1 curtida
Tem alguma sugestão de livro para Clean Code? Pode ser livro ou algum site, algo que me faça entender o básico para ir aplicando.
Obrigado.
Tio Bob…
Mas vá pegando a base “crua” da linguagem primeiro. Sem esta base, tu tá lascado, não apenas para Python, mas para migrar e entender qualquer outra. Outra coisa, se não estou equivocando-me, como vocẽ quer usar o pyGTK, você vai precisar trabalhar com orientação a evento, então, novamente, estude bastante a base de POO para ficar bem a vontade.
1 curtida
Mas porquê está fazendo assim?
1 curtida
Não sei. Eu comecei a ler sobre OOP há 1 dia. Estou tentando implementar uma coisa simples. A minha preocupação única é não ir aprendendo o paradigma errado.
Estou aqui parado o dia todo pensando e pesquisando como fazer da forma mais adequada.
Dando um exemplo:
No final, o que vou querer fazer é “controlar uma casa”, digamos assim. Eu pensei em OOP para criar os objetos mesmo. Digamos, uma TV, com seus métodos, uma geladeira… etc. Depois eu queria “conversar” com tudo, da maneira que fosse sendo necessário conforme eu fosse montando o que eu precisava.
Sei que para construir uma solução em software precisa pensar bem com calma, quase uma “consulta” antes de começar a desenvolver, mas como sou eu só, eu me dou a liberdade de cometer uns erros. Não é o meu foco profissional, é apenas mais uma habilidade que julgo ser bem relevante no presente e no futuro.
Ai é outro papo… Se tu não tiver uma base minimamente sólida com o básico (programação estruturada), você vai penar em POO. Jamais pule etapas de aprendizado. Comece do “be a ba” e, novamente, pratique muito. É chato? Muito… Mas é deveras necessário
Eu consigo fazer tudo o que preciso, mas de forma procedural e com funções. Sendo que já tive que reescrever o meu código algumas vezes pois muitas vezes preciso realizar coisas bem diferentes.
É como se num dado momento eu precisasse cortar a grama de casa, mas o cortador de grama estava dentro de um carro, aí tenho que remover ele dentro do carro para poder cortar a grama.
Meio “viajado” o exemplo, mas é mais ou menos isso. Pensei que eu eu fizesse tudo como objetos, seria mais fácil reaproveitar o código para qualquer outra coisa, já que teria o “carro” e o “cortador de grama” de forma independente.
Faço o que preciso, mas não de maneira profissional, sabe. Sou amador. Queria começar a me profissionalizar mais.
Ai que tá, não adianta apenas criar classes, herdar e achar que tá tudo certo. Você tem que aplicar o pilar do POO, ao menos alguns pontos, para tirar realmente proveito. Sendo eles:
1- Encapsulamento;
2- Abstração;
3- Herança;
4- Polimorfismo.
Eu concordo. É aí onde está o núcleo do problema. Eu, realmente, não tenho certeza se preciso, de fato de OOP, não para o “backend”. Mas como pretendo colocar uma interface gráfica em cima, com certeza vou precisar entender os conceitos.
É uma longa jornada. Eu vou experimentando. Quando tiver simples construído, eu posto aqui para vocês darem o toque se estou completamente “alienado” ou estou indo no caminho certo.
1- Encapsulamento;
2- Abstração;
3- Herança;
4- Polimorfismo.
É isso. Eu tenho o faro que entender o paradigma não é sair aplicando, mas ter esses conceitos impregnados na forma de pensar. Aí que entenderei OOP, de fato. Por enquanto estou “rabiscando” e adquirindo os conceitos. Algo meio caótico, mas creio que vai se formar uma ordem de forma espontânea.
Depende do que se busca, mas eu diria que no seu exemplo realmente, faria da classe veiculos uma classe abstrata ou uma interface.
Porque não fazer de veiculos uma classe concreta?
veiculos é uma classe incompleta (não existe uma definição comum para certos comportamentos de um veículo) e/ou a classe é naturalmente abstrata (não existe um objeto concreto veiculos em si de fato, existe um objeto concreto motos/carros/bicicletas/etc, portanto não é desejável que possamos instanciar veiculos diretamente e portanto não é desejável arcar com as desvantagens de se herdar uma classe concreta veiculos (herança múltipla, acoplamento forte, etc).
Caso seus objetos tenham alguns comportamentos polimórficos mais puros que possam ser expressados diretamente na classe base e isso seja vantajoso, vá de classe abstrata. Caso contrário use uma interface.
Usar interface vai evitar problemas com herança múltipla. Da mesma forma irá contribuir para um acoplamento mais fraco (maior encapsulamento) das classes do seu projeto isso facilita na hora de mudar, incrementar ou testar o projeto o que significa que seu software será mais adaptável e manutenível.
De resto se eu fosse apontar um erro comum que eu gostaria que o pessoal tivesse mais atenção com relação a classes, é que herança não é panaceia… Eu já cansei de ver herança sendo usada onde deveria ter sido usado composição. Por exemplo, jamais faça algo como:
class veiculos(rodas)
1 curtida