<br><br><div><span class="gmail_quote">On 3/20/07, <b class="gmail_sendername">Luis Motta Campos</b> &lt;<a href="mailto:luismottacampos@yahoo.co.uk">luismottacampos@yahoo.co.uk</a>&gt; wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
On Mar 19, 2007, at 7:45 PM, Solli Honorio wrote:<br>&gt; Puxa, agora eu fiquei confuso... tenho para mim que POO é uma<br>&gt; excelente forme de pensar qualquer tamanho de projeto, pois o cara<br>&gt; pode crescer sem complicação, e é apenas um pouco complicado no
<br>&gt; início com os construtores e destrutores (DESTROY). Esta sua<br>&gt; afirmação vem de alguma complicação real que possa ser<br>&gt; compartilhada conosco ?<br>&gt;<br><br>&nbsp;&nbsp; Hum. Isto aqui é a minha opinião. Eu gosto de gente que discorda
<br>dela, especialmente quando discorda sem descer das tamancas e sem ser<br>mal-educado. Eu estou postando isto aqui por que me perguntaram<br>diretamente sobre o assunto. Se você se interessa sobre isso, e quer<br>debater, sinta-se à vontade para responder.
<br><br>&nbsp;&nbsp; Quando a gente faz análise e projeto orientado a objeto (OOA&amp;D,<br>para quem gosta de sopa de letrinhas), normalmente tem de fazer<br>opções: que base de dados usar? Postgres? MySQL? MSSQL Server?<br>Oracle? Todas? Nenhuma?
<br><br>&nbsp;&nbsp; Dentro da mesma linha de raciocício, precisamos escolher e tomar<br>decisões sobre que formas de autenticação utilizar (password?<br>challenge-response? chaves criptográficas?), que arquitetura geral<br>nosso sistema vai ter (MVC? Client-Server? Ambas? Outras?), e,
<br>lentamente, de escolha em escolha, vamos definindo um contrato, uma<br>interface para o sistema, que vamos ser obrigados a seguir sem<br>alterações por muito tempo depois do projeto ter terminado.<br><br>&nbsp;&nbsp; Este &quot;projeto por contrato&quot; é o que eu acredito ser o maior perigo
<br>do OOA&amp;D. Quando a gente começa a estabelecer contratos sem muito<br>critério, nos comportamos como crianças que jogam aqueles jogos de<br>embaralhar mãos e pés sobre um tabuleiro no chão, conforme se<br>sorteiam cores, numeros ou formas. E, eventualmente, todas as
<br>crianças vão perder o equilíbrio e cair no chão, umas enroladas nas<br>outras.</blockquote><div><br><span style="font-family: courier new,monospace;">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.
<br><br>Por esta visão, do qual eu compartilho, então temos que tomar cuidado com o A&amp;D, já que é nesta faze que definimos os &#39;contratos&#39;.<br><br>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.
<br style="font-family: courier new,monospace;"></span></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">&nbsp;&nbsp; A diferença é que, quando um engenheiro de software incauto faz
<br>isso, não tem graça nenhuma, e, normalmente, não é possível<br>desembaralhar mãos e pernas e começar novamente o jogo.<br><br>&nbsp;&nbsp; Assim, quando eu digo &quot;tomem cuidado com OOA&amp;D&quot;, é por que, em<br>determinada altura da vida, eu comecei a reparar que a gente toma
<br>decisões e implementa coisas que são nojentas, simplemente por que é<br>a única forma &quot;lícita&quot; de se fazer isso sem quebrar os contratos que<br>foram estabelecidos até o momento.<br><br>&nbsp;&nbsp; Claro, seu chefe nunca quer saber de nenhum contrato quebrado: se
<br>você não implementar as coisas em tempo, ele simplesmente te joga na<br>rua e coloca outro incauto ali, que vai xingar, criticar, adaptar,<br>escrever, pesquisar, tentar reformar, e... aderir ao contrato. Pelo<br>menos, desta forma, não quebramos o &quot;software legado&quot; vão te dizer.
<br>Não é preciso fazer força, já veio quebrado &quot;de fábrica&quot;...<br><br>&nbsp;&nbsp; Espero que isso te ajude a entender por que eu acho que OOA&amp;D pode<br>morder.<br>&nbsp;&nbsp; Putamplexos!<br>--<br>Luis Motta Campos (a.k.a. Monsieur Champs) is a software engineer,
<br>Perl fanatic evangelist, and amateur {cook, photographer}<br><br><br>_______________________________________________<br>SaoPaulo-pm mailing list<br><a href="mailto:SaoPaulo-pm@pm.org">SaoPaulo-pm@pm.org</a><br><a href="http://mail.pm.org/mailman/listinfo/saopaulo-pm">
http://mail.pm.org/mailman/listinfo/saopaulo-pm</a><br></blockquote></div><br>