Um bom exemplo de Orientação a Objetos

Virtual Machine Man Membro desde: 31/10/2007 07:36:22 Mensagens: 665 Offline

Caros amigos do GUJ vejo muitos dizendo que isso e Orientação e aquilo não é ai vem ooutro e distorci tudo, seria um otimo exemplo de orientação o que vou dizer abaixo?

Tenho uma classe CASA, e CASA possui diversos atributos como endereço porem endereço seria uma outra classe que possui seus atributos como rua, cep, numero e por ai vai entao concluimos que a minha classe casa possuira um atributo chamado endereço ao inves de possui nome de rua, cep e numero..concordam? isso seria pura orientação?

Obrigado e abraço a todos.

Virtual Machine Man Membro desde: 12/01/2007 23:35:34 Mensagens: 611 Offline

Nesse caminho mesmo.

OO não se resume a isso, mas o que falou faz parte sim.

para falar o estudo dar uma acessada nesse material.

link

Não. O seu exemplo pode ser obtido com registros (structs) ou mesmo com funções. Para ter um objeto você precisa de estado e comportamento no mesmo componente, não apenas dados estruturados.

Virtual Machine Man Membro desde: 31/10/2007 07:36:22 Mensagens: 665 Offline

pcalcado wrote:Não. O seu exemplo pode ser obtido com registros (structs) ou mesmo com funções. Para ter um objeto você precisa de estado e comportamento no mesmo componente, não apenas dados estruturados.

Sim isso todos sabemos, mas creio que o conceio de orientação parte disso de vc comecar a analsar objetos do Mundo Real e transformar em classes, sei que ainda faltam os comportamentos que serao definidos porseus metodos e coisas do tipo...mas creio que essa ideia seria a ideia default para o entendimento de OO

TeiTei wrote:

pcalcado wrote:Não. O seu exemplo pode ser obtido com registros (structs) ou mesmo com funções. Para ter um objeto você precisa de estado e comportamento no mesmo componente, não apenas dados estruturados.

Sim isso todos sabemos, mas creio que o conceio de orientação parte disso de vc comecar a analsar objetos do Mundo Real e transformar em classes, sei que ainda faltam os comportamentos que serao definidos porseus metodos e coisas do tipo...mas creio que essa ideia seria a ideia default para o entendimento de OO

Nao e eh exatamente o que eu tentei dizer.

Orientacao a Objetos nao tem necessariamente nada a ver com objetos do mundo real. Objetos sao apenas artefatos de software que possuem estado e comportamento, voce pode tanto ter objetos representando coisas do mundo real (que eh, por exemplo, a abordagem de Domain-Driven Design) quanto ter objetos que nao possuem equivalentes fora daquele software. Orientacao a Objetos tambem nao depende de classes, voce pode ter objetos com prototipos, por exemplo.

Se voce nao atribuir comportamento a sua estrutura de dados voce nao possui um objeto, possui apenas uma estrutura de dados. Eh esse o caso do seu exemplo logo nao se trata de um exemplo particularmente orientado a objetos porque pode ser criado utilizando praticamente qualquer paradigma de desenvolvimento.

Debugger Membro desde: 19/02/2008 15:40:37 Mensagens: 67 Offline

Caro pcalcado, poderia me dar um exemplo:

Orientacao a Objetos nao tem necessariamente nada a ver com objetos do mundo real

...ter objetos que nao possuem equivalentes fora daquele software. Orientacao a Objetos tambem nao depende de classes, voce pode ter objetos com prototipos, por exemplo.

Me desculpe, mas até o momento achava que OO era inerente às classes. Pode me dar um help!?

Algumas linguagens sem classes e Orientadas a Objetos:

http://www.iolanguage.com/
http://en.wikipedia.org/wiki/JavaScript
http://en.wikipedia.org/wiki/Self_(programming_language)

Mais aqui:
http://en.wikipedia.org/wiki/Prototype-based_programming#Languages

Virtual Machine Man Membro desde: 31/10/2007 07:36:22 Mensagens: 665 Offline

pcalcado wrote:Algumas linguagens sem classes e Orientadas a Objetos:

http://www.iolanguage.com/
http://en.wikipedia.org/wiki/JavaScript
http://en.wikipedia.org/wiki/Self_(programming_language)

Mais aqui:
http://en.wikipedia.org/wiki/Prototype-based_programming#Languages

Juro que nao entendo mais...kkkkkkkkkkk

Cada um fala uma coisa....acho q esse lance de OO e meio que aberto para opiniões sei la..kkkk..pq cada cara fala uma coisa...ja vi caras com 8 anos de experiencia dizer uma coisa outro de 10 anos dizerem outra..e assim vai...sei la...kkkkkkkkkkk

TeiTei wrote:
Juro que nao entendo mais...kkkkkkkkkkk

Cada um fala uma coisa....acho q esse lance de OO e meio que aberto para opiniões sei la..kkkk..pq cada cara fala uma coisa...ja vi caras com 8 anos de experiencia dizer uma coisa outro de 10 anos dizerem outra..e assim vai...sei la...kkkkkkkkkkk

Que tal ler algo sobre o assunto?

http://userpage.fu-berlin.de/~ram/pub/pub_jf47ht81Ht/doc_kay_oop_en
http://gagne.homedns.org/~tgagne/contrib/EarlyHistoryST.html
http://www.laputan.org/reflection/warfare.html
http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.56.4713
http://lucacardelli.name/

...

This message was edited 7 times. Last update was at 08/09/2008 09:41:43

Teitei,

existe um artigo bastante interessante sobre os paradigmas de programação escrito por Maria Cecília Calani Baranauskas, que acho bom você ler:

http://www.nied.unicamp.br/publicacoes/separatas/Sep3.pdf

Neste artigo, a autora se prende nos conceitos iniciais dos paradigma, e na preocupação de diferenciar a OO da estruturada, como um conceito completamente novo. Se você pegar os primeiros textos sobre smalltalk e posteriormente do Yourdon, você verá que a OO foi iniciada no contexto de que a "lógica dos sistemas" e sua implementação deveriam ser descritas como "objetos do mundo real" e a iteração entre estes objetos.

Em meados dos anos 70 e início dos anos 80 (1989 a 1994) vários métodos de modelagem orientada a objetos surgiram, sendo que os principais foram: Booch (Grady Booch), OMT (Rumbaugh), OOSE (Jacobson), Shlaer/Mellor (Sally Shlaer e Stephen Mellor), Coad/Yourdon (Peter Coad e Ed Yourdon), dentre outros.

Neste cenário Grady Booch e James Rumbaugh juntaram forças através da Rational Corporation para unificar os métodos Booch e OMT que resultou na versão 0.8 do Método Unificado, lançado em outubro de 1995.

Também no final de 1995, Ivar Jacobson juntou-se a equipe fundindo o método OOSE (Object-Oriented Software Engineering). Booch, Rumbaugh e Jacobson estavam motivados a criar uma linguagem unificada para modelar sistemas complexos de qualquer tipo: missão crítica, tempo real, cliente/servidor ou outros tipos. Após o apoio de parceiros importantes como Microsoft, Hewlett-Packard, Oracle, IBM, dentre outras em janeiro de 1997 foi lançado a UML 1.0 (Unified Modeling Language).

Em 2004, Martins considera que o desenvolvimento de software deve ser realizado utilizando um processo de desenvolvimento de sistemas consistente e sedimentado no mercado, tais como RUP. Utilizando gerenciamento de projetos, com suas áreas de conhecimento: gerenciamento do escopo, riscos, custo, tempo, qualidade, dentre outros.

Na visão de Kobryn na UML 2.0 o trabalho de revisão foi concluído, já que reflete a maior revisão e o futuro do desenho orientado a objetos. Trata-se de um importante marco na evolução da linguagem, na medida em que, suporta modelos grandes e complexos.

Na visão da OMG, diversos dialetos tendem a surgir, onde os usuários customizarão a linguagem e adicionam características que melhor descrevam suas regras de negócio. Porém, a evolução significativa ocorrerá quando os ambientes de desenvolvimento suportar os diagramas permitindo múltiplas visões do negócio. Desta forma, a tendência natural será de um acoplamento através das extensões e modificações da UML às frameworks de desenvolvimento, como o J2EE e .NET.

No atual estágio do desenvolvimento tecnológico, as técnicas tradicionais de desenvolvimento de sistemas (análise e programação) estão chegando no limite de sua utilização. Por exemplo, tente descrever com a UML o funcionamento de aplicação que utilize a capacidade (no centro da solução) do processamento paralelo (multi-cores da vida).

E não estou falando em softwares que atendam várias requisições, como servidores web ou sgbds.

Imagine uma linguagem que para solucionar uma expressão matemática (como a fórmula báscara) seja capaz de para cada produto/divisão utilizar um processador e as adições posteriores sejam realizadas também em paralelo...

Tudo isso para dizer, que os paradigmas tradicionais estão sendo utilizados para representar, estudar e planejar sistemas muito mais complexos dos que eram possíveis de serem imaginados na época em que iniciaram seus desenvolvimentos. E estamos diariamente, construindo (ampliando) soluções com essas ferramentas disponíveis.

Para concluir, eu discordo um pouco da fala do Phillip, apesar de compreender o contexto que ele faz as suas afirmações, neste ponto:

Se voce nao atribuir comportamento a sua estrutura de dados voce nao possui um objeto, possui apenas uma estrutura de dados. Eh esse o caso do seu exemplo logo nao se trata de um exemplo particularmente orientado a objetos porque pode ser criado utilizando praticamente qualquer paradigma de desenvolvimento.

Se o contexto analisado identificar que você precise representar as informações Casas e endereço, e tomando como partida que uma casa não é um endereço, então você terá que modelar esse conhecimento do mundo real (no meu entendimento o sentido de mundo real é aplicado ao contexto não computacional e descrito pelo fornecedor de requisitos), em um contexto que pode ser abstrato, com as metodologias de desenvolvimento existentes.
Se a linguagem de programação que seu cliente dispõe, for por exemplo C, uma solução correta e aceita no paradigma estruturado é:

O mesmo ocorre se a situação for Java e OO:

O que devemos observar é que se os conceitos de sintaxe e léxica da linguagem utilizada estiverem corretos (passam pelo compilador), não significa que você "implementou" corretamente um paradigma ou outro.

Veja o risco do seu exemplo, por ele ser muito simples, ele permite escrevermos a mesma solução para os dois paradigmas. E no contexto apresentado eu acredito estarem corretos com relação a aderência dos mesmos em relação aos paradigmas.

Discussões sobre boas práticas de modelagem e formas de abordagem não servem para desqualificar a solução proposta, com relação ao fato de ser de um paradigma ou outro.

A essência do paradigma orientado objeto, está no foco ou atenção dada para representar uma proposta de solução para um problema computacional, que no paradigma OO estarão nos dados (informações) e no estruturado os códigos (ou ações/procedimentos).

Outro aspecto que acredito ser relevante nesse contexto, é que foi a própria SUN (e acredito que por alguma limitação da arquitetura do java que desconheço) que recomendou a criação de objetos pequenos (magros) e a disseminação de padrões de implementação como POJO, VO etc que não possuem (a principio) a necessidade explicita de "comportamento".

att

Dieval

This message was edited 1 time. Last update was at 08/09/2008 18:37:59

Dieval Guizelini wrote:
[...]

Bom agora parece que tive uma explicação mais clara...kkk..as coisas estao clariando mais....eu vou ler este pdf......vlw abraços e obrigado pela super atenção.
ate mais

Oi,

Dieval Guizelini wrote:
Para concluir, eu discordo um pouco da fala do Phillip, apesar de compreender o contexto que ele faz as suas afirmações, neste ponto:

Se voce nao atribuir comportamento a sua estrutura de dados voce nao possui um objeto, possui apenas uma estrutura de dados. Eh esse o caso do seu exemplo logo nao se trata de um exemplo particularmente orientado a objetos porque pode ser criado utilizando praticamente qualquer paradigma de desenvolvimento.

Se o contexto analisado identificar que você precise representar as informações Casas e endereço, e tomando como partida que uma casa não é um endereço, então você terá que modelar esse conhecimento do mundo real (no meu entendimento o sentido de mundo real é aplicado ao contexto não computacional e descrito pelo fornecedor de requisitos), em um contexto que pode ser abstrato, com as metodologias de desenvolvimento existentes.
[...]
O que devemos observar é que se os conceitos de sintaxe e léxica da linguagem utilizada estiverem corretos (passam pelo compilador), não significa que você "implementou" corretamente um paradigma ou outro.

Veja o risco do seu exemplo, por ele ser muito simples, ele permite escrevermos a mesma solução para os dois paradigmas. E no contexto apresentado eu acredito estarem corretos com relação a aderência dos mesmos em relação aos paradigmas.

Não entendi onde você discorda, foi exatamente o que eu disse. O exemplo acima pode ser OO, mas pode não ser. Ele pode ser implementado em qualquer paradigma que eu conheça.

Dieval Guizelini wrote:
Outro aspecto que acredito ser relevante nesse contexto, é que foi a própria SUN (e acredito que por alguma limitação da arquitetura do java que desconheço) que recomendou a criação de objetos pequenos (magros) e a disseminação de padrões de implementação como POJO, VO etc que não possuem (a principio) a necessidade explicita de "comportamento".

A Sun não é exatamente a melhor referência para este tipo de coisa (vide Blueprints J2EE) mas ainda que fosse acho que você fez uma confusão acima. POJO (um termo criado e difundido por Martin Fowler) não diz nada sobre granularidade, estado ou comportamento. Ele apenas diz que o objeto não depende de nenhum framework. O Transfer Object (antigo VO) é um padrão de projeto que deve ser aplicado numa situação muito específica (no caso, com EJB 2.1) e não uma recomendação geral para modelagem de objetos.

Outra coisa importante: um dos papers que linkei acima é "The Early Story of Smalltalk", por Alan Kay. Neste paper você vai ver que, ao contrário do texto postado aqui, objetos não são particularmente criados ara modelar o mundo real. Eles modelam idéias, que podem ter um correspondente fora do sistema ou não.

Olá Phillip,

o ponto que disse não concordar com suas colocações foi em relação a frase "(...)Se voce nao atribuir comportamento a sua estrutura de dados voce nao possui um objeto, possui apenas uma estrutura de dados(...)".

Eu discordo em partes, que um objeto tenha que ter "comportamento definido" para que o contexto que o mesmo seja modelado seja considerado aderente ou não ao paradigma orientado objetos. Tanto para análise como para programação.

Com relação aos exemplos que citei da Sun (mesmo concordando com você, de não serem boas referências com relação a OO), são o fato deles criarem (com vários nomes) classes contendo apenas propriedades, construtores e métodos set/get... sem lógica de negócio própria ou comportamento. E mesmo assim, esses padrões de desenvolvimento de sistemas são aderentes ao paradigma OO, colaborando com o meu ponto de vista de que ter comportamento não é um requisito essencial para dizer que a modelagem de uma classe está ou não aderente ao paradigma OO.

A título de exemplo do que usei no post anterior:
1) Transfer Object (TO) http://java.sun.com/blueprints/corej2eepatterns/Patterns/TransferObject.html
2) Value Object http://java.sun.com/j2ee/patterns/ValueObject.html

E como você disse, Blueprints...

E no segundo post, quanto ao conceito de modelar o mundo real, eu concordo com sua forma de expressão. Apenas tinha me expresso de outra forma, em:

(...)no meu entendimento o sentido de mundo real é aplicado ao contexto não computacional e descrito pelo fornecedor de requisito(...)

Com relação ao texto do "The Early Story of Smalltalk". Eu não o conhecia, mas já tinha feito um pdf dele e pode ter certeza que irei ler com atenção.

até mais,

Dieval

Notícias, artigos e o maior fórum brasileiro sobre Java