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 é:
struct _ENDERECO {
char *rua;
char *numero;
};
struct _CASA {
// alguma coisa
struct _ENDERECO endereco;
}
O mesmo ocorre se a situação for Java e OO:
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".
att
Dieval
