[SP-pm] OOA&D de vez em quando morde...

[Luis Motta Campos]

On Mar 20, 2007, at 11:58 AM, Igor Sutton Lopes wrote:
> On 2007/03/20, at 10:31, Luis Motta Campos wrote:
>>    Espero que isso te ajude a entender por que eu acho que OOA&D pode
>> morder.
>>    Putamplexos!
>
> Eu gosto do paradigma de orientação à objetos, e ainda assim  
> concordo com o Luis. Isto por que temos que separar a engenharia de  
> software como o Luis mencionou das buzzwords atuais. Estas  
> buzzwords adicionam muita complexidade desnecessária, e graças a  
> $deity Perl permite que você misture e escolha da maneira mais  
> apropriada à isto.
>
> O que isto quer dizer? Isto quer dizer que você pode muito bem  
> utilizar um framework orientado à papéis (roles) como o Catalyst e  
> escrever o resto do código utilizando código procedural. Ou  
> orientado à objetos. Ou spaghetti code. Ou...
>
> Orientação à objetos é bom sim, mas tem limite. Perl te dá opções,  
> escolha a que mais tem a ver com o seu trabalho - desenvolvimento  
> de sistemas web, programas de automação de sistemas operacionais,  
> etc - e escolha a que melhor lhe convir. E lembremos sempre de  
> utilizar *consistência*, e este é o principal problema hoje.

   Você falou, falou, falou, mas não chegou a lugar nenhum, Igor.

   Quando eu disse "OOA&D morde" eu deveria ter dito "Engenharia de  
Software morde". É apenas uma questão de enquadramento.

   Quando a gente cria sistemas (sigam eles o Paradigma da Orientação  
a Objetos ou qualquer outro), na verdade, criamos restrições. Muitas  
delas são muito úteis e permitem que o sistemas que a gente constrói  
funcionem como a gente espera. Mas nem sempre é este o único efeito  
destas regras. Muitas vezes, elas tem como efeito colateral coisas  
inesperadas, que vão affetar a sua capacidade de resolver problemas  
com boas soluções.

   Eu não estou defendendo que a gente deva tolerar as soluções  
ruins, muito pelo contrário. Defendo que um sistema bem pensado desde  
o princípio, quando é "só um quebra-galho" garante que você não vai  
ficar amarrado a regras, interfaces e restrições em geral que vão te  
"obrigar" a fazer código ruim em algum momento futuro.

   Em outras palavras: antes de implementar uma interface, pensa  
primeiro se ela não vai conseguir te morder no futuro. Não implemente  
coisas dependentes de um sistema que pode mudar, por exemplo, ou você  
vai precisar implementar de novo muito em breve (por que tudo nesta  
vida é passageiro, exceto o motorista e o cobrador...)

   Putamplexos!
--
Luis Motta Campos (a.k.a. Monsieur Champs) is a software engineer,
Perl fanatic evangelist, and amateur {cook, photographer}