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?
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
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[/quote]
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.
[quote]…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.
[/quote]
Me desculpe, mas até o momento achava que OO era inerente às classes. Pode me dar um help!?
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
[quote=TeiTei]
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[/quote]
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 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 é:
class Endereco {
String rua,numero;
}
class Casa {
Endereco endereco;
}
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”.
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
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.
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.
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.
Entao eu me pergunto: o que caracteriza um objeto para voce? Dada a afirmacao acima eu posso inferir que qualquer linguagem com estruturas de dados defiunidas pelo usuario eh orientada a objetos.
Nao sao aderentes e nem precisam ser. []bNao eh porque voce usa uma linguagem OO e construtos como classes que voce possui um programa orientado a objetos[/b], bem como eu nao preciso de uma linguagem OO para ter objetos. Em certos momentos (como no caso do TO/DTO) faz sentido abrir mao de objetos em funcao de alguma outra caracteristica.
No mais, como citei antes basta voce ler os links que voce mesmo mandou que vai perceber que este tipo de pseudo-objeto (como todo padrao) possui aplicabilidade restrita a casos especificos.
Ps: os dois links que voce mandou se referem ao mesmo padrao, que mudou de VO para TO na segunda edicao do livro.