nesse caso
você está falando de herança com polimorfismo das partes do carro agregadas não é?
então seria uma superclasse abstrata Motor?
que tenha vários tipos de motores derivados refinados
isso?
Isso realmente me parece polimorfismo…
Mas, mudando um pouco do assunto, você não teria por aí um caso de uso (não muito extenso) para irmos debatendo? acho que assim fica mais fácil…
Mas, se não for pedir muito, pega algo mais próximo da vida real…
fala drigo
então
nossa
sou meio ruim de criar uns casos de uso
vou pensar nuns aqui
legal você pedir isso
bom que eu estudo mais, e discuto esse assunto com pessoas + experientes
moro aqui no mato, aqui não tem nada nem com quem conversar rrsrsr
vou ver aqui e logo postarei
obrigado
[quote=Bruno Reis]nesse caso
você está falando de herança com polimorfismo das partes do carro agregadas não é?
então seria uma superclasse abstrata Motor?
que tenha vários tipos de motores derivados refinados
isso?[/quote]
Depende… poderia ser classe abstrata ou uma interface, caso o motor tenha um comportamento comum e todos os motores deverão ter este comportamento isto devera ser uma classe abstrata se não uma interface mesmo… nestes casos usa-se polimorfismo mas o que eu quero enfatizar é
a composição neste caso pois vc poderia ter um automóvel abstrato com outros modelos concretos que herdam deste automóvel… mas tera pouco reaproveitamento de codigo… pois se criar um carro A que tenha um peneu aro 30 e um B que seja diferente mas tenha o mesmo tipo de peneu vc terá que reescrever o codigo deste peneu para cada carro se fizer desta maneira. Este é um exemplo onde a OO é bem util. Veja sobre o desing pattern Estrategi.
e algo essencial é trabalhar com interfaces invéz de classes concretas… o spring por exemplo trabalha assim.
Quando eu estava aprendendo sobre POO me deram o exemplo de carros e motores, acho que foi o melhor que ja tive hahaha se vc usar essa linha de pensamento com certeza não terá problemas em entender.
Talvez, o que o autor do tópico está sentindo falta são exemplos reais de modelos OO. Alguns exemplos existem no livro Analysis Patterns, de Martin Fowler. É um livro antigo, não usa UML e merecia uma segunda edição, na minha opinião. Mas tem um material desse gênero. Porem, concordo que existe pouco material didático com exemplos reais de modelagem OO em diferentes domínios.
[quote=luistiagos]
e algo essencial é trabalhar com interfaces invéz de classes concretas… o spring por exemplo trabalha assim.[/quote]
Concordo, mas, na verdade, o Spring não força você a usar interfaces no seu código. E, infelizmente, muita gente acaba usando classes concretas.
"Errado amigo… evite, prefira agregar e compor objetos ao invéz de herda-lo…
Imagine o seguinte cenário vc tem uma classe abstrata automovel que tem penus, motor, lataria, volante, etc… vc pode criar novos automovel extendendo de sua classe automovel tipo caminhão, camionete, carro, etc… vc terá n classes onde em cada classe vc re-implementará os componentes do automovel (peneu, motor, volante,…) pois cada automovel tem seus componentes diferentes. Seria bem melhor se vc tivesse interfaces para estes componentes: interface(peneu, motor, volante,…), e na sua classe automovel seria composto por estas interfaces… assim vc só precisaria implementar e instanciar um componente de cada vez e não necessitar mudar todos a cada automovel diferente… assim cada automovel será uma composição de componentes comuns a automoveis.
não sei se deu pra entender mas ta ai um exemplo… "
ao luistiagos …
não amigo, errado está você, não prefira “agregar” nem “compor objetos”, não é esse o caminho, isso foi imposto a você, alguém disse isso, e quem disse
que o esperto que falou isso está com a razão? não tá não, o correto é herdar, mas o Java não tem estrutura pra isso, não conseguiram implementar isso no Java,
quando eu falo em componentes, não é componentes como conceito não, não são os componentes do automóvel, pneu, motor, volante, interface também é um conceito
fraco, quero ver os caras fazerem alguma coisa de útil com essa história de interface, esqueçam isso, é mais um conceito pronto, vindo dos norte-americanos e que não serve pra nada, como muitos desses conceitos inúteis, o que funciona mesmo é o seguinte:
- objetos são componentes VISUAIS, que vc arrasta e solta no form e sai pro abraço, porque ali tem 3 ou 5 mil linhas de códigos encapsulados, esse
componente VISUAL herda dos seus ancestrais todo o comportamento e vc economiza muito tempo, não sei porque falam contra as linguagens visuais de arrastar
e soltar, foi outra coisa imposta pelos norte-americanos concorrentes que queriam derrubar o Delphi, que queriam acabar com a Borland, mas tecnologia boa de
componentes vc só encontra nessa linguagem, só pra exemplificar, o que vc faz com componentes prontos pra rodar no Windows em digamos 1 semana, vc levaria 10 x mais tempo pra escrever tudo na mão, com uma qualidade bem inferior, com muito mais erros, em uma linguagem que não usa componentes.
Por isso luistiagos, vejo que vc deve ser novo na programação, porque o teu conceito de orientaçao a objeto tá bem longe de algo realmente produtivo, não se deixe influenciar pelas besteiras que falam por aí, é tudo influência de empresas norte-americanas, sejamos brasileiros nacionalistas, eles querem IMPOR linguagens só pra
depois que todo mundo tá usando, aí sim cobrar licenças, como tá acontecendo com o Java agora, tá sendo fechado, mas quem queria ter dado o bote era a IBM né?
ela que mais fomentou, que desenvolveu o bugado bloco de notas chamado Eclipse e impôs pra todo mundo que aquilo era uma maravilha, fala sério, e muitos acreditaram
criando assim uma geração de programadores que só conhecem o que lhes foi imposto (Java) pela influência e pelas nossas fraquíssimas faculdades “maria-vai-com-as-outras”.
“Troll, bom motivo pra ser criança…”
Trollagem (ao Java) atacando no GUJ, que feio hein gurizada!
Se vc quer desenvolver um sistema OO de forma simples e direta, usando muitas boas práticas de programação, sugiro seguir passo a passo a apostila FJ-28 da Caelum. Os conceitos que você vai aprender nessa apostila vale mais a pena do que ser um purista OO.
http://www.caelum.com.br/curso/fj-28-vraptor-hibernate-ajax/
Agora, se você quer realmente algo muito OO, bem purista mesmo (lotado de exemplos de como usar OO até onde não precisa), recomendo um livro PHP. Programando com orientação a objetos - http://novatec.com.br/livros/phpobj/.
Um kra q tem uma noção e uma assimilação impressionante d OO é o Shoes, sera interessante ele se manifestar por aqui.
Eu penso da seguinte forma, é td mto bonito a teoria do OO, Patterns e tals … mas qdo vc dá um nó na tua cabeça com tanta teoria, lembra da simplicidade, sem ser negligente. Q q eu quero dizer? sem firulas no projeto, simplicidade em programação é legal. Simplicidade e organização. Organização para não ser negligente a ponto d futuras alterações no projeto (mudanças d requisitos por exemplo) serem motivos para se atirar da janela. Complexidade sem necessidade nao faz sentido, como patterns em excesso. Excesso d zelo por aplicar a teoria OO … Foca no problema q teu projeto tem q resolver, consciente d futuras alterações. Simplicidade, Organização, Abstração e Generalização. Qto mais abstração e consequente generalização, mais fácil fica d adaptar teu código para futuras alterações.
Críticas são bem-vindas uma vez q expressei uma opinião extremamente particular.
MINHA OPINIÃO…
Muitas pessoas acham que programar orientadao a objetos é simples e que criando algumas classe e relacionando elas esta ja 100%.
Não é bem assim…é dificil você desenvolver um sistema OO que tenha realmente as caracteristicas OO, porem se conseguir faze-lo voce estara tranquilo em relação a manutenções e melhorias no sistema…
A OO presa por 2 principois de alta coesão e baixo acolplamento o que significa que suas classe devem ser bem especificas e ter pouca relações com outras classes concretas.
Por muitas vezes criamos classes que tentam abraçar o mundo…e assim ja fugimos dos principios da Orientação Objeto.
so pra complementar o que vc disse quando abriu o topico ao meu ver esta mais relacionado com padroes de projetos do que com OO
Não é isso o que significa não. Isso é a consequência de seu uso.
Não é que ela deva ser evitada, mas sim analisado se seu uso é adequado à necessidade. É mais fácil falar para evitar para que não seja usada inconvenientemente.