Programação Orientada a Objetos existe mesmo? Ou é mito?

Jocê já leu o livro Use a cabeça! A&POO :?:

Comecei a ler ele, é muito bom (conceitos / exemplos / casos de uso / etc… ) mas na literatura, ou seja em livros, ainda não vi projetos do tamanho de aplicações do mundo real, apenas exemplos para que você possa aplicar os conceitos (que são os mesmos)

Dê uma olhada no livro Utilizando UML e Padrões, do Craig Larman.

então Drigo

tenho esse livro, ainda não li não

estou lendo um pouco do Deitel, um pouco do Eduardo Bezerra, e de Isaias Boratti.

nos livro e apostilas tem conceitos e conceitos…

mas o que eu preciso é de um modelo de projeto OO(mundo real) com de um sistema com CRUDs que enviem dados para classes Controle -> Entidade(mundo real) e com o domínio do problema resolvido essas classes enviem os dados para gravação num SGBD como Postgre por ex.

na prática

o Netbeans tem um wizard que gera um CRUD

entretanto

e o paradigma da OO(mundo real)?

é realmente utilizada?

preciso de um projeto simples pronto na prática com CRUD->domínio problema(mundo real)->SGBD

para ter a noção de como elaborar

tudo que encontro na net é conceitos e mais conceitos somente

Olá

Orientação à objetos em Java? acho difícil encontrar isso em Java, não é porque instancia-se algumas coisas e então já está programando orientado à objetos,
não, não é isso, objetos são verdadeiramente implementados na forma de COMPONENTES, aí vc tem realmente os 3 pilares da orientação:

• herança
• encapsulamento
• polimorfismo

mas eu não vejo ninguém usando componentes em Java, alguns colegas já me disseram que na Eclipse tem mas não conseguem usar por algum motivo,
ah … e dos 3 pilares eu considero a herança o mais importante, sem herança não tem como haver orientação à objetos, não tem reutilização de código.

Abraço

gadriano:

Olá

Orientação à objetos em Java? acho difícil encontrar isso em Java, não é porque instancia-se algumas coisas e então já está programando orientado à objetos,
não, não é isso, objetos são verdadeiramente implementados na forma de COMPONENTES, aí vc tem realmente os 3 pilares da orientação:

• herança
• encapsulamento
• polimorfismo

mas eu não vejo ninguém usando componentes em Java, alguns colegas já me disseram que na Eclipse tem mas não conseguem usar por algum motivo,
ah … e dos 3 pilares eu considero a herança o mais importante, sem herança não tem como haver orientação à objetos, não tem reutilização de código.

Abraço

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…

Então, aparentemente, pelos comentários acima, OO em Java é possível :?:
Sim

Todos programadores Java utilizam?
Infelizmente não

Se você Iniciar qualquer projeto com esses conceitos (que você já deve estar cansado de ver) na cabeça, bem consolidados, seguindo os padrões de projeto, você fará sim uma aplicação orientada a objeto, sem repetição de código, com classes bem definidas, com bastante coesão e baixo acoplamento.

procure sobre Domain Model Desing neste modelo sim é usado digamos “mais OO pura”…

Orientada a Objeto significa -> Reaproveitamento de código, organização do código facilitando a manutenção do programa…

é muito complexo isso mesmo né

tudo vi até agora está fragmentado

um pouquinho de conceitos aqui

outro pouquinho de conceitos ali

é complexo porque não há um caminho a seguir é criação pura

objetos de fronteira colaborando com objetos de controle com objetos de entidade com fronteira e ator banco de dados

tem que estudar muito mesmo

melhor ir para o jeitão evento estruturado que é mais rápido rsrs

luisthiagos

saudações

o que é uma Interface de Componentes

lembro que li que herança deve ser evitada

Mas eu acho que é assim mesmo que funciona, vc aprende os conceitos e aplica o máximo que pode em seus códigos.

Isso mesmo…

Os “modelos” que irão te guiar são os padrões de projeto… e nem é toda hora que se aplica…

Quanto a ‘separação’ das camadas, você já sabe muita coisa, é só por a mão na massa

drigo

então acho que estou + ou -

no caminho

vou ver sobre os Patterns

vou criar minhas classe do jeito do mundo real com suas características de composição e ação e evitando recorrência de campos entre umas e outras

e depois fever a cabeça para ver como elas podem colaborar entre si

uma instância recebendo dados de um JFrame é fácil

o que preciso saber mais é como enviar esses dados para o banco após

eles terem sido digitados pelo Ator, passado para do JFrame para a classe controle CadastradorCliente por ex.

e na saída ir para o banco

outra coisa

falando de mensagens

por exemplo, neste código

umJogador.chuteBola(Bola b)

{

double gol = b.recebaChute();

}

quem é o Emissor?

quem é o Receptor?

quem é Mensagem?

nesse código há quantos Emissores e quantos Receptores?

:idea: Acho que ta tipo o jogador recebe uma mensagem ± “De um chute na bola b”
Neste caso ele é o receptor, o emissor ficou desconhecido

Então o jogador manda uma mensagem para a bola “Receba o chute”
Aqui o jogador é o emissor e a bola o receptor

Creio que seja isso mesmo…

drigo

o emissor nesse caso seria

por ex.

umTecnico.pecaChute(umJogador.chuteBola(Bola b));

ou

umTecnico.pecaChute(Jogador jogador)

{

jogador.chuteBola(Bola b);

}

nestes casos os emissores estão desconhecidos ainda?

não to conseguindo enteder

tem como você me dar um exemplo do emissor enviando mensagem para receptor, por favor

preciso saber para implementar em código os diagramas de uml

obrigado

não consegui

acho que entendi

o jogador está mandando uma mensagem bola.recebaChute

a mensagem é meio implícita né

Bruno Reis:

luisthiagos

saudações

o que é uma Interface de Componentes

Quiz me referir a uma classe que implementa esta interface: por exemplo motor e um componente do carro, se tivemos motor de ferrari por exemplo este motor implementa a interface motor que ira dispor de metodos como ligarMotor, darPartida,etc… (como não entendo nada de motores), metodos que serão comuns a todos os moteres porem tem implementação distinta…

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

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?

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.

luistiagos:

e algo essencial é trabalhar com interfaces invéz de classes concretas… o spring por exemplo trabalha assim.

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.