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

[Igor Sutton Lopes]

On 2007/03/20, at 11:57, Luis Motta Campos wrote:

> 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.

Eu "falei, falei, falei" e acho que cheguei algures sim: o que eu  
quis frisar foi o fato que não vai ser a técnica utilizada para  
construir o seu software que vai dizer se é uma boa ou má  
implementação. Maus programadores e técnicas ruins vão existir  
sempre, e o que eu quis fortalecer foi que Perl te dá possibilidades  
de fazer isto de uma maneira misturada e nem por isso, ruim.

>    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...)

--
Igor Sutton
igor.sutton em gmail.com



-------------- Próxima Parte ----------
Um anexo em HTML foi limpo...
URL: http://mail.pm.org/pipermail/saopaulo-pm/attachments/20070320/94b2a84a/attachment.html