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

[Solli Honorio]

On 3/20/07, Luis Motta Campos <luismottacampos em yahoo.co.uk> wrote:
>
> On Mar 19, 2007, at 7:45 PM, Solli Honorio wrote:
> > Puxa, agora eu fiquei confuso... tenho para mim que POO é uma
> > excelente forme de pensar qualquer tamanho de projeto, pois o cara
> > pode crescer sem complicação, e é apenas um pouco complicado no
> > início com os construtores e destrutores (DESTROY). Esta sua
> > afirmação vem de alguma complicação real que possa ser
> > compartilhada conosco ?
> >
>
>    Hum. Isto aqui é a minha opinião. Eu gosto de gente que discorda
> dela, especialmente quando discorda sem descer das tamancas e sem ser
> mal-educado. Eu estou postando isto aqui por que me perguntaram
> diretamente sobre o assunto. Se você se interessa sobre isso, e quer
> debater, sinta-se à vontade para responder.
>
>    Quando a gente faz análise e projeto orientado a objeto (OOA&D,
> para quem gosta de sopa de letrinhas), normalmente tem de fazer
> opções: que base de dados usar? Postgres? MySQL? MSSQL Server?
> Oracle? Todas? Nenhuma?
>
>    Dentro da mesma linha de raciocício, precisamos escolher e tomar
> decisões sobre que formas de autenticação utilizar (password?
> challenge-response? chaves criptográficas?), que arquitetura geral
> nosso sistema vai ter (MVC? Client-Server? Ambas? Outras?), e,
> lentamente, de escolha em escolha, vamos definindo um contrato, uma
> interface para o sistema, que vamos ser obrigados a seguir sem
> alterações por muito tempo depois do projeto ter terminado.
>
>    Este "projeto por contrato" é o que eu acredito ser o maior perigo
> do OOA&D. Quando a gente começa a estabelecer contratos sem muito
> critério, nos comportamos como crianças que jogam aqueles jogos de
> embaralhar mãos e pés sobre um tabuleiro no chão, conforme se
> sorteiam cores, numeros ou formas. E, eventualmente, todas as
> crianças vão perder o equilíbrio e cair no chão, umas enroladas nas
> outras.


Como você bem disse, um projeto de software é de uma maneira simplista (e
possível neste contexto) regras de restrições, e estas restrições podem
significar maior ou menor flexibilidade no futuro, o quê em informática é
algumas semanas.

Por esta visão, do qual eu compartilho, então temos que tomar cuidado com o
A&D, já que é nesta faze que definimos os 'contratos'.

Vejo no OO uma das técnicas mais flexível para contornar as amarras destes
contrato, ou estou enganado ? Não tenho a mesma experiência de programação
que vc, mas acredito que programação estrutural, ou o spaguethi :)
dificultam muito mais as adaptações futuras.

   A diferença é que, quando um engenheiro de software incauto faz
> isso, não tem graça nenhuma, e, normalmente, não é possível
> desembaralhar mãos e pernas e começar novamente o jogo.
>
>    Assim, quando eu digo "tomem cuidado com OOA&D", é por que, em
> determinada altura da vida, eu comecei a reparar que a gente toma
> decisões e implementa coisas que são nojentas, simplemente por que é
> a única forma "lícita" de se fazer isso sem quebrar os contratos que
> foram estabelecidos até o momento.
>
>    Claro, seu chefe nunca quer saber de nenhum contrato quebrado: se
> você não implementar as coisas em tempo, ele simplesmente te joga na
> rua e coloca outro incauto ali, que vai xingar, criticar, adaptar,
> escrever, pesquisar, tentar reformar, e... aderir ao contrato. Pelo
> menos, desta forma, não quebramos o "software legado" vão te dizer.
> Não é preciso fazer força, já veio quebrado "de fábrica"...
>
>    Espero que isso te ajude a entender por que eu acho que OOA&D pode
> morder.
>    Putamplexos!
> --
> Luis Motta Campos (a.k.a. Monsieur Champs) is a software engineer,
> Perl fanatic evangelist, and amateur {cook, photographer}
>
>
> _______________________________________________
> SaoPaulo-pm mailing list
> SaoPaulo-pm em pm.org
> http://mail.pm.org/mailman/listinfo/saopaulo-pm
>
-------------- Próxima Parte ----------
Um anexo em HTML foi limpo...
URL: http://mail.pm.org/pipermail/saopaulo-pm/attachments/20070320/bf2436e4/attachment.html