Quando usar OO

Cara, quando não uso OO é porque achei difícil aplicar um conceito X, por não saber muito ainda sobre o assunto e sua implementação.

Mas sempre, sempre, sempre me arrependo depois, pois é um inferno manter código procedural. Sempre é. Então refatoro para algo mais orientado a objetos e a facilidade garantida pela naturalidade dos relacionamentos e mensagens entre objetos sempre me satisfaz.

Até hoje o que pude perceber:

1. Quando não aplico OO, é por falta de experiência minha.
2. OO é simples. Difícil é fazer procedural.
3. 70% do tempo de vida de um software é manutenção, pense bastante nisso.
4. O que não é bom resolver com OO, com um tantinho de AOP resolve perfeitamente.

Sério, leia o livro que o Shoes tanto recomenda. Nunca passei da página 100, mas agradeço por elas a cada linha de código que eu escrevo hehe

Lipe fiquei curioso, que livro é esse? Design Patterns? Diga ai! rs

LIPE:

Cara, quando não uso OO é porque achei difícil aplicar um conceito X, por não saber muito ainda sobre o assunto e sua implementação.

Mas sempre, sempre, sempre me arrependo depois, pois é um inferno manter código procedural. Sempre é. Então refatoro para algo mais orientado a objetos e a facilidade garantida pela naturalidade dos relacionamentos e mensagens entre objetos sempre me satisfaz.

Até hoje o que pude perceber:

1. Quando não aplico OO, é por falta de experiência minha.
2. OO é simples. Difícil é fazer procedural.
3. 70% do tempo de vida de um software é manutenção, pense bastante nisso.
4. O que não é bom resolver com OO, com um tantinho de AOP resolve perfeitamente.

Sério, leia o livro que o Shoes tanto recomenda. Nunca passei da página 100, mas agradeço por elas a cada linha de código que eu escrevo hehe

Minhas Rules of Thumb:

Quando usar OOP:

• Quando me preocupar em manter o código
• Quando estiver construindo algo que não seja tão simples que um script resolva
• Quando não for um protótipo rápido
• Quando não der mais trabalho utilizar OOP que outra tecnologia (i.e. programando em C, pascal, perl, bash, tcsh, ksh)

Note que quando a pessoa se propõe a usar OOP, que use. Se quiser programar de forma estruturada, que programe, mas não ache que programação procedural nãot em suas regras.

Se eu frequentasse um fórum de C ou pascal hoje em dia, provavelmente ia atentar a todo momento para os princípios do projeto estruturado que simplesmente são ignorados.

Tem um livro do page-Jones muito bom, hoje já fora de catálogo no Brasil, chamado Practical Guide to Structured Systems Design que foi o primeiro livro de design que li na vida. Este livro traz regras sobre programação procedural que formam a base das regras que hoje são aplicadas a POO (no seu livro sobre design OO, Meilir cita este livro a todo instante).

Se você realmente quer utilizar programação procedural, eu recomendaria uma linguagem com mais recursos reais. Java tem um apelo muito grande, mas acho que voltar pra C seria o caminho lógico.

abstract:

Lipe fiquei curioso, que livro é esse? Design Patterns? Diga ai! rs

Bertrand Meyer (primo do scotty):
Object-Oriented Software Construction

Esse é o livro básico de OOP (apesar de não ser para iniciantes). Qualquer livro realmente bom e inovador nos últimos dez anos tem ele na bibliografia.

Eu costumo explicar o uso de objetos com o exemplo da árvore binária.

Voltando a programação estruturada:
Teríamos um módulo, com variáveis globais e funções qual poderíamos utilizar para realizar uma certa tarefa. Por exemplo, o módulo de árvore binária. Este módulo teria operações de adicionar nós, fazer buscas, remover nós, e variáveis globais como um ponteiro para a raiz.

Mas surge um problema quando queremos num mesmo programa utilizar mais de uma instância de uma árvore binária. Por isso, a idéia de uma mesma estrutura incorporar comportamento e propriedades, permitindo múltiplas instâncias de um mesmo “módulo”.

A questão é que eu não me vejo fazendo tantos módulos que precisem de rodar em múltiplas instâncias. Mesmo programas grandes muitas vezes são somátorios de “scripts” que fogem a necessidade de OO.

Ah! Excelentes argumentos Shoes! Parabéns e obrigado!

O exemplo é bom, mas não é a única forma de se justificar OOP.

Como falei antes, se o que você quer fazer é uma peça de software com meia dúzia de funções e estrutura de dados, e principalmente de vida curta, um script (e nem precisa ser OO, como Groovy, Ruby ou Python) é mais que suficiente. No entanto a única linguagem compilada procedural que eu utilizaria hoje, creio, é C, por sua maturidade e amplo suporte em tantos ambientes.

No meu ver, Estruturada está para OOP como Programação Não Estruturada está para Programação Estruturada.

Quem nunca fez um programa em C com uma única função: main()?

Eu :XD:

Lipe, que só programou em Java na vida.

Voltando à pergunta original, eu gosto muito de OO mas reconheço que existem muitos casos em que não é a melhor solução. Às vezes uma abordagem mais declarativa é mais natural, uma ótima ilustração disso é esse artigo do Fowler sobre arquivos de build - o Make, o Ant e o Rake todos usam esse tipo de modelo. Mais exemplos são CSS e XSLT (esta última é até uma linguagem funcional de verdade) e linguagens de busca (SQL, XQuery/Xpath, D do TTM).

Outro tipo de situação que não se adapta bem à OO são os sistemas distríbuidos (segundo o Ted Neward “There is no such thing as a good distributed object model”). Tanto o padrão DTO quanto web-services feitos direito (document-style soap ou rest) são marcadamente não-OO, e com bom motivo.

AllMighty:

Voltando à pergunta original, eu gosto muito de OO mas reconheço que existem muitos casos em que não é a melhor solução. Às vezes uma abordagem mais declarativa é mais natural, uma ótima ilustração disso é esse artigo do Fowler sobre arquivos de build - o Make, o Ant e o Rake todos usam esse tipo de modelo. Mais exemplos são CSS e XSLT (esta última é até uma linguagem funcional de verdade) e linguagens de busca (SQL, XQuery/Xpath, D do TTM).

Eu tenho minhas duvidas quanto ao build em si (um project.build(); que recursivamente chamasse varios sourceCode.compile() nao em soaria tao estranho), mas trnasformação e bsuca realmente doem com OOP.

AllMighty:

Outro tipo de situação que não se adapta bem à OO são os sistemas distríbuidos (segundo o Ted Neward “There is no such thing as a good distributed object model”). Tanto o padrão DTO quanto web-services feitos direito (document-style soap ou rest) são marcadamente não-OO, e com bom motivo.

Sistemas realmente distribuidos funcionando direito geralmente eh sinonimo de sopa de paradigmas

Esse é o Shoes que eu conheço :XD:

Para engrossar a lista da não utlização de OO segue:
_ até hoje tem os sistemas baseados em lógica como alguns sistemas especialistas, inteligência artificial, etc.
_ sistemas baseados em fluxos.

O livro de conceitos do Robert W. Sebesta tange os diferentes paradigmas de programação e suas aplicações devidas.

Mas… uma coisa que é legal no Java é o fato de ser uma linguagem de propósito de geral e de grande aceitação (Você não consegue fazer tudo que o Java faz usando PL SQL, por exemplo). E eu acredito que algumas vezes podemos programar em Java sem usar OO (mesmo em sistemas vezes). O cruel, é dizer quando levando em conta os medos do shoes com relação à manutenção, clareza, etc.

Escolher o paradigma e ferramentas certa faz parte do prcoesso de desenvolvimento de software.

Mesmo em java você pode adotar uma outra filosofia (assim como posso aplicar conceitos de OOP em C) e dependendo do caso pdoe mesmo ser muito melhor, apesar de eu achar que você deveria tentar dar uma olhada em ferramentas mais adequadas ao seu problema. Se eu repetir “no silver bullet” aqui eu mesmo me dou um tiro de tanto tédio (aliás, o artigo do brooks fala explicitamente de OO). Ops, repeti. X(

O grande ponto é que, certo ou errado, existe um consenso de que a melhor forma de se modelar domínios de negócio (nãoe stou falando de domínio matemático, físico ou qualquer coisa menos cotidiana para mim) hoje é através de objetos e a tendência atual de separar “serviços paralelos” com aspectos.

Um sistema com domínio forte e bem-construido expressa claramente o que o sistema faz, conhecendo a falácia que é especificação funcional e documentaçãoe scrita, nada melhor que isso.

Se uma pessoa concorda realmente com isso e não está seguindo princípios básicos do paradigma, então tem algo errado e ela deve ser alertada, concordando ou não.