Verdades e Mitos sobre a Programação Orientada a Objetos

1- Objetos são "abstrações" do mundo real.  

Mito. Objetos nem sempre representam "coisas" do mundo real. Eles são unidades especializadas compostas por dados e comportamento, que atuam de forma colaborativa para compor uma aplicação. Podem ou não representar algo do mundo real. Por essa definição, tanto um servlet, um dataset ou um cliente podem representar objetos válidos em um sistema. A confusão se dá devido às instâncias de classes que representam conceitos de um domínio e que são chamadas de business objects. Essas são bastante valiosas para vários tipos de aplicações, pois servem como Domain Model do negócio que o software pretende atender, com suas regras de negócio, linguagens compartilhadas e necessidades específicas (abordagem da técnica conhecida como Domain Driven Design).

Obs: objetos que não possuem comportamento são conhecidos como objetos anêmicos, termo cunhado por Martin Fowler para designar entidades "burras" que funcionam apenas como depósito de dados.

2 - O Desenvolvimento OO é mais lento.

Verdade. Aplicações OO são compostas de pequenas classes especializadas nas várias funcionalidades que uma aplicação necessita para atender a uma área de negócio. O foco é nas entidades que realizam o processo e não no seu fluxo (marcante no desenvolvimento procedural). Há "seres" responsáveis em gerenciar conexões, executar cálculos, mapear dados, imprimir relatórios, gerar visualizações, etc. A criação dessas classes demanda um esforço inicial maior por parte do time de desenvolvimento - esforço que será recompensado por uma maior facilidade de manutenção, reutilização e evolução do software em questão.

Obs: esse atraso no desenvolvimento é parcialmente compensado pelo uso de frameworks que auxiliam na construção da infra das aplicações como mapeamento de entidades, segurança, configuração e logs.

3 - Programar em Java ou C# gera automaticamente software OO.

Mito. O desenvolvimento OO começa na mente do programador. É, acima de tudo, uma forma de design. Linguagens como Java, C# e VB.Net são ótimas pois permitem que o design OO imaginado  pelo projetista/programador seja facilmente implementado pelo time de desenvolvimento. Elas são equipadas de recursos como herança, polimorfismo, encapsulamento e permitem a criação de classes, objetos, interfaces, enumerações, etc. Porém, sem o domínio de como fazer design OO, estaremos usando essas ferramentas, na melhor das hipóteses, para gerar um código procedural "disfarçado" de software OO.

4 - Para aprender OO é preciso aprender UML.

Mito. A Unified Modeling Language (UML) é uma excelente ferramenta para comunicar ideias de modelagem, ajudando no processo de desenvolvimento de uma determinada aplicação. Entretanto, ela não ajudará na construção do design da solução. Em outras palavras, sem a atitude mental correta, servirá  apenas para modelar perfeitamente uma aplicação ruim. O interessante da UML é o fato de ser uma forma de notação conhecida por inúmeros desenvolvedores ao redor do globo, possibilitando uma linguagem de modelagem comum para o time e outros stakeholders do projeto. Profissionais de OO experientes utilizam a UML para modelar soluções de forma livre em white boards e/ou ferramentas case (geralmente em conjunto com outros membros do time). Outro benefício (secundário) da UML é a possibilidade de geração de documentação.

5 - Programadores mais antigos têm dificuldades com OO.

Verdade. A última década consolidou o modelo de desenvolvimento OO, principalmente devido à popularização do Java e ao crescimento da plataforma .Net. Por que então tantos programadores ainda têm dificuldades com esse paradigma? A resposta é simples: a maioria desses programadores com dificuldades foi formada sob a ótica procedural e ao desenvolvimento orientado a banco de dados. A programação OO vira o mundo desses profissionais de cabeça pra baixo, propondo uma forma diferente de se construir software, com a promessa de gerar aplicações mais fáceis de manter (e estender) e mais resistentes a mudanças, requisitos-chave para atender às exigências do mundo moderno.

6 - A programação OO favorece a reutilização.

Verdade. A criação de várias instâncias de objetos de uma mesma classe já é um grande exemplo, por si só,  de reutilização de código. Cria-se a classe apenas uma vez. Instâncias de objetos são obtidas com base nessa "forma" que molda as características e o comportamento da entidade. Outras formas de reutilização são a componentização e o uso de patterns (Design Patterns e Architectural Patterns).