08 Jun 08 Orientação a objetos é fácil, as pessoas é que complicam
A idéia de escrever este post veio desta discussão no GUJ, que começou falando de testes unitários e terminou sobre orientação a objetos.
Então seguem as minhas opiniões.
As linguagens de programação mais modernas, ou pelo menos as mais utilizadas de hoje em dia são Orientadas a Objeto, as famosas linguagens OO, mas mesmo assim, a grande maior parte dos desenvolvedores parece não conseguir entender direito a tal da Orientação a Objeto.
Resolvi escrever este este post porque do alto do meu ego inflado, acredito conseguir entender corretamente OO e poder ajudar um pouco.
Então, leiam o post até o final, e depois se quiserem tirar dúvidas ou me xingar, é só deixar um comentário …
O primeiro erro que todos cometem ao iniciar em OO é achar que Orientação a Objetos é sobre classes, isto não faz nenhum sentido, Orientação a Objetos como o próprio nome diz, é sobre Objetos, então, qualquer coisa que não seja um objeto não é realmente importante quando se fala em Orientação a Objetos.
OK, mas por que todos caem no mesmo engano então? porque a grande maior parte das linguagens de programação orientadas a objeto, utilizam classes como moldes para objetos, e durante o desenvolvimento se cria os moldes, ja que os objetos só existem em tempo de execução nestas linguagens.
Quais linguagens não funcionam assim? Bom, agora me vem a cabeça SmallTalk, IO e Ruby, mas devem ter outras.
SmallTalk porque não existe realmente distinção entre “tempo de desenvolvimento” e “tempo de execução” em SmallTalk, tudo esta sempre executando.
IO porque não utiliza o conceiro de classes (a não ser que eu tenha entendido a linguagem errado) e sim objetos template.
E Ruby porque as classes em Ruby são objetos também, mas das três é a que mais se aproxima do “padrão” que citei antes.
Outro erro bastante comum, desta vez quando se utiliza alguma tecnologia de mapeamento Objeto/Relacional, é achar que objetos são tabelas, mapeamento Objeto/Relacional serve para salvar o estado de um objeto em um banco de dados relacional, apenas isto, um objeto do tipo Usuario por exemplo, não possui um atributo “grupo_id”, mas pode possuir um relacionamento com um objeto do tipo Grupo. Percebam que eu escrevi atributo e não campo, pois tabelas tem campos e linhas, objetos possuem atributos e métodos.
Uma coisa bastante comum, ainda utilizando mapeamento O/R é achar que um objeto possui os mesmos atributos que a tabela correspondente, mas neste caso até os nomes são diferentes, infelizmente nestes casos, um objeto precisa ter um atributo “id” que mapeia para a chave primária da tabela, mas um objeto não tem uma chave primária, ele tem apenas atributos.
Então, como solucionar estes problemas?
Bom, no geral, um objeto tem comportamento, e alguns atributos também, mas o importante em um objeto é o que ele faz e como ele faz.
Claro que existem objetos que não tem comportamento, objetos em um sistema são a representação binária de alguma coisa do mundo real, e existem coisas no mundo real que não tem comportamento, tem apenas atributos, como por exemplo mesas e cadeiras, mas exceto se você estiver mapeando um destes objetos no seu sistema, todos os objetos tem um comportamento.
Por exemplo, se você criar um objeto do tipo Usuário, se ele não possuir nenhum comportamento, com certeza o seu sistema esta construído de forma errada, pois pelo menos eu, não conheço nenhum usuário que fique parado como uma estátua o tempo todo, e se este for o caso, com certeza ele não é usuário de sistema nenhum, portanto ele não deveria existir no seu sistema.
A mesma coisa se aplica a um carro, você conhece algum carro que não se move? Que não tenha comportamento algum? A única desculpa para um carro que não tem comportamento algum é um sistema para um museu de carros, onde só importa a carcaça do carro e os atributos dele, principalmente o ano de fabricação.
Outra coisa que todos entendem errado é o padrão MVC (Model, View, Controller).
Na definição do padrão, o controlador esta la apenas como ponto de entrada, ele passa parâmetros para um método de um Model, pega o resultado disto e passa para uma View, se ele estiver fazendo mais do que isto, ele possui parte do código que deveria estar dentro do Model, por tanto, o seu Controller esta errado!
Beleza, mas se eu estou dizendo que todos cometem os mesmos erros, como eu posso dizer que OO é fácil então?
Porque a maioria aprende primeiro a programar de forma estrutural, e depois passa para orientação a objetos, e como as pessoas aprendem coisas novas utilizando como base suas experiências anteriores, utilizam os paradigmas procedurais para tentar programar orientado a objetos, esta é basicamente a raiz do problema.
Para tornar a vida de todos mais fácil, o primeiro contato com programação nos cursos e faculdades deveria ser com SmallTalk e não com portugol ou pascal.
Se você aprender primeiro orientação a objetos, conseguira passar para programação procedural com uma facilidade muito maior do que alguem que aprende primeiro programação procedural tentando aprender orientação a objetos.
O pior é que as linguagens de programação que não são 100% OO contribuem ainda mais para aumentar este problema, vamos pegar o Java como exemplo de uma linguagem não 100% OO.
“Mas me disseram que java era uma linguagem de programação OO”
Bom isto também é verdade, eu disse não 100% OO, não disse que não era OO.
Exemplos de coisas que não são OO em Java: tipos primitivos e métodos estáticos
Basicamente eu acho que na linguagem é só isto que não é OO, mas isto ja causa problemas o suficiente confundindo a cabeça de muita gente.
“Perai, métodos estáticos ficam dentro de classes, como podem não ser OO?”
Mérodos estáticos são uma forma porca de programação procedural dentro de uma linguagem OO que teve uma linguagem procedural como origem, como por exemplo o Java e o C++.
Métodos estáticos não fazem parte de uma classe, utilizam a classe apenas como namespace, o que é diferente de fazer parte.
Em um método estático, não é possível nem saber a qual classe ele pertence, como é possível tanto em object pascal quanto em Ruby, ja que estas não possuem métodos estáticos e sim métodos de classe.
E os tipos primitivos estes sim, não tem relação nenhuma com orientação a objetos, só estão la porque quando a linguagem foi criada não era possível fazer uma classe ter a mesma performance do que um tipo mapeado diretamente do processador da máquina, eles existem em Java por problemas de performance e não por serem Orientados a Objeto.
Alguns design patterns foram criados apenas para contornar limitações da pataforma (Exemplo prático, com um banco de dados OO decente não seria necessário criar o pattern DTO), da mesma forma algumas das regras sobre a utilização de OO foram criadas apenas porque a maioria das pessoas não entende OO, como a regra que diz favoreça composição em vez de herança.
Este é um engano terrível cometido por muitas pessoas que eu não consigo entender.
Muita gente acha que estender uma classe é uma forma de compartilhar código, por exemplo:
Existe uma entidade no sistema de nome Cliente, e em algum momento é necessário criar um ClienteDependente que vai possuir todos os mesmos atributos de cliente mais um que aponta para o responsável, não faz sentido algum fazer ClienteDependente estender Cliente para compartilhar este código, porque o comportamento deles não é o mesmo, por exemplo, ClienteDependente não paga a conta, mas Cliente sim, neste caso seria melhor refatorar o sistema e criar uma entidade que pudesse realizar compras (Ou criar objetos do tipo Compra se o sistema foi bem modelado), e fazer com que Cliente e ClienteDependente estendessem desta, pois neste caso elas estariam realmente compartilhando o comportamento e não apenas evitando algum código aparentemente repetido.
Estender uma classe é estender o comportamento, ou seja, só faz sentido estender o comportamento se a classe “filha” tiver todo o comportamento da classe “pai”, ou seja, é um relacionamento o tipo “é um”. Mas como quase ninguém consegue entender que estender uma classe estende o comportamento (não me parece uma coisa tão complexa assim para se entender), foi criada esta regra que diz: Não use herança, use composição. Simplesmente para evitar que pessoas façam porcaria por não entender conceitos que são estupidamente simples, mas que todos tem mania de complicar.
Outro erro bastante comum é tentar colocar em uma classe apenas o comportamento de todo o sistema, se for para fazer isto, utilize programação procedural, pois você vai estar utilizando a classe apenas como namespace mesmo, não vai nem lembrar que em tempo de execução estara trabalhando com diversos objetos criados a partir daquela forma.
Orientação a objetos é simples, é um paradigma de desenvolvimento que modela um sistema transformando conceitos do mundo real como objetos que colaboram entre si para atingir um objetivo.
Acho que o nome Objeto pode ajudar a confundir boa parte das pessoas, pois em um sistema OO, Compra pode ser um tipo de Objetos, mas no mundo real, compra não é um objeto. Mas para resolver isto eu simplesmente assumo que qualquer um que queira ser um programador precisa ter capacidade para trabalhar com abstrações, não tenho uma explicação melhor para alguem que não consegue entender que Compra pode ser um tipo de Objeto em um sistema OO, assim como Viajem também pode ser um tipo de Objeto (estou utilizando “Tipo de Objeto” em vez de classe porque o que importa em um sistema OO são as instâncias e não as classes) dependendo do problema a ser resolvido.
Acho que são estes os erros mais comuns na orientação a objetos, lendo isto você não concorda comigo? OO é simples, as pessoas é que complicam!
Você lembra de algum outro erro muito comum em OO? deixe um comentário.
Se eu lembrar de mais coisas simples que as pessoas tem mania de complicar eu escrevo outro post.
Se você gostou deste post, lembre-se de assinar o RSS feed do blog, para ser notificado de novos posts!
Reader's Comments
Leave a Comment
Descontão no melhor livro de Rails
O melhor livro de Rails
Licença
Blog do Urubatan by Rodrigo Urubatan Ferreira Jardim is licensed under a Creative Commons Attribution-Share Alike 2.5 Brazil License.
Permissions beyond the scope of this license may be available at http://www.urubatan.com.br/contato/.
Muito bom o seu post Urubatan!
Gostaria de focar no ponto que eu achei crucial: “estudantes aprendem primeiro programação procedural”. Isso é fato, é real.
As faculdades e universidades deveriam começar o ensino em programação com linguagens orientadas a objetos, visto que no decorrer dos semestres as disciplinas utilização linguagens Orientadas a Objetos, normalmente Java e/ou C#.
Sobre programação procedural, vejo também um problema muito comum: profissionais de linguagens não Orientação a Objetos ou profissionais antigos.
Object Pascal é uma linguagem Orientação a Objetos, mas muita gente usa essa linguagem de forma errada, de forma procedural. Já trabalhei com gente assim e vejo muito isso atualmente. Conto nos dedos os profissionais que vinheram dessas linguagens e sabem bem o conceito e utilizam de forma correta a Orientação a Objetos, você é um deles.
Enfim, está na hora de criarmos um movimento do tipo “programe direito, faça como a gente” e agirmos com bom senso.
A OO é simples, com certeza, mas este blog caiu muitos pontos no meu conceito depois deste post, dizer que classes não tem nenhum sentido em relação a OO está errado, como um objeto pode existir sem que exista uma classe? Um objeto é a instância de uma classe, se não existe classe, não será possível obter uma instância dele.
Se SmallTalk, IO e Ruby utilizam somente objetos, sem a necessidade de ter uma classe, ou molde, tudo bem, agora não é um erro pensar que classes fazem parte da OO, já que todas as outras linguagem utilizam o conceito de classes e objetos.
Diogo, pode ser que eu não tenha me expressado bem, mas o que eu quis dizer foi que é errado pensar em termos de classes quando se esta programando orientado a objetos, é preciso pensar em objetos, as classes serão apenas os moldes.
Não disse que é errado ter classes em uma linguagem OO, disse que elas podem ajudar alguem que não esta acostumado com programação OO a se confundir, por pensar mais nas classes do que nos objetos criados a partir delas.
@urubatan
Olá Urubatan, gostei do post, porém em alguns pontos ficou meio confuso, talvez por você ter estendido o assunto a problemas de ORM e MVC, mas enfim o que me deixou confuso foi este comentário:
“Alguns design patterns foram criados apenas para contornar limitações da pataforma (Exemplo prático, com um banco de dados OO decente não seria necessário criar o pattern DTO) [...]”
Na verdade o pattern DTO (Data Transfer Object) surgiu para diminuir as chamadas remotas entre sistemas distribuídos, não tem muito a ver com banco de dados.
@diogo
Não é necessário se ter classes para se programar orientado a objetos, JavaScript por exemplo é uma linguagem OO baseada em protótipos e não classes. Assim como o Urubatan disse, o importante sãos os objetos e como eles interagem.
Urubatan, muito bom o post, realmente hoje em dia ainda nos deparamos com codigos procedurais feitos em liguagens OO.
Pelo que percebo é que algumas pessoas o fazem dessa forma ou por descompromisso com o projeto (gambiarra) ou por falta de conhecimento, pois quem procura pesquisar, estudar e ampliar seus conhecimentos está menos sujeito a desenvolver desta forma.
Parabens pelo post.
[]s.
Urubatan, interessante o post. Realmente seria muito bom se pudéssemos ver um sistema feito por você totalmente OO (pena que acredito que isso não seja possível rs).
Aprender em cima de exemplos “sólidos” (não coisas de uma classe só) é com certeza muito mais fácil.
De qualquer forma, me surgem muitas dúvidas na implementação do MVC para aplicações desktop, se você pudesse escrever algo sobre isso acho que seria interessante.
Abraços
Muito bom o post urubatan,
Eu acho que ensinar java no primeiro semestre para alguêm que não sabe o que é um “IF”, não é tão simples assim. Mas acho que os conceitos já podem ser iniciados pelo menos o básico no primeiro semestre.
Quanto ao desenvolvimento Procedural em linguagens OO é um fato…mas o problema é pior, normalmente os sistemas são desorganizados, sendo feitos em OO ou Procedural, tanto faz!! No mínimo que tenho em mente é: NÃO DUPLICAR CÓDIGO. A maioria dos sistemas que eu peguei para dar manutenção exemplo escritos em java, php etc são umas bagunças, código duplicado etc…sofrível..:)
Da-lhe grep para achar os códigos…
O que você me diz então daquelas classes utilitárias?
DateUtil,StringUtil, classe ou interfaces que possui as constantes do sistema.tudo isso você considera anti-pattern?
Antonio, não é obrigatoriamente um anti pattern, mas com certeza não é OO.
É uma forma necessária de trabalho para contornar problemas da plataforma, no caso do teu exemplo o Java se não estou enganado.
Por exemplo, se fosse possível alterar um objeto em java, o método String.format não precisaria ser estático, seria possível adicionar o método em um objeto do tipo String e em vez de se chamar:
String.format(”%.2d”,20)
Chamar:
“%.2d”.format(20)
o que seria muito mais OO do que o método estático.
Mauricio, este problema do IF seria solucionado ensinando OO com SmallTalk em vez de Java, em SmallTalk os objetos do tipo Boolean, possuem um método “ifTrue” e um método “ifFalse” que recebem blocos, não existe uma estrutura “if” da linguagem.
Rafael Ponte, o problema de muitas chamadas remotas entre as camadas foi criado pelo EJB 1.x/2.x, e o DTO foi criado para contornar o problema destas plataformas, com um banco de dados OO estilo o utilizado pelo MagLev para rodar Rails sobre o GemStone, um DTO seria completamente desnecessário, as coisas simplesmente estariam compartilhadas entre as camadas, mas concordo que foi um exemplo infeliz pois praticamente não existem implementações disto por ai.
muito bom!
realmente parece que as pessoas simplesmente não entendem. vejo códigos assim constantemente, classes sendo usadas como namespace e heranças sem qualquer sentido. já vi coisas do tipo ‘User extends Database’ apenas pra um método acessar o banco.
Hum… só uma pergunta: ser ‘mais orientado a objetos’ é uma qualidade? Ser ‘OO’ ou ‘procedural’ indica qualidade num software?
Não quero dizer que acho lindo as pessoas acreditarem que estão usando OO só porque fizeram uma classe abstrata ou um Singleton (rsrsrs), claro.
Mas o que é melhor, um sistema todo feito orientado a objetos, sem nenhuma modularização, com alto acoplamento, cheio de gargalos de sincronização e zero reúso, ou um sistema todo procedural, cheio de DTOs, mas performático, bem modularizado, que segue padronização de código e com uma boa separação entre as camadas?
Paradigma de programação e qualidade de software são duas coisas completamente diferentes e ortogonais. Não é a orientação a objetos que faz um design bom, mas sim, um bom design faz bom uso da orientação a objetos (e de outros paradigmas, se apropriados).
‘Baixo acoplamento’ e ‘alta coesão’, assim como todas as outras ‘qualidades’ de um software, não são intrínsecas nem exclusivas à OO. Um bom design OO pode obter estas qualidades, mas um bom design procedural também pode. E um design OO ruim é tão ruim quanto (talvez até pior que) um design procedural ruim.
E Rodrigo, eu não quis criticar o seu post. Entender bem a OO é muito importante, já que este é o paradigma mais usado nas linguagens de programação atuais. Eu só quero lembrar que, mais importante do que seguir cegamente os preceitos da OO, é entender como fazer um bom projeto/design, e como utilizar bem os recursos das tecnologias (linguagem de programação, bibliotecas, frameworks), sejam eles ‘OO’ ou não.
Tetsuo, concordo com tudo o que você escreveu,
É possível ter um software de qualidade e muito bem escrito utilizando linguagens procedurais, funcionais ou OO, uma coisa não tem ligação direta com a outra.
Mas escrever um sistema de forma procedural em uma linguagem OO é uma prova de desconhecimento da ferramenta no minimo
Acho que fui genérico demais quando eu escrevi “X é um design péssimo” eu deveria ter escrito “X em uma linguagem OO é um design péssimo” para evitar confusões
Sem confusão alguma!
Como eu disse, eu não estava criticando o seu post!
Eu também estou cansado de ver gente usando as features da OO mal e porcamente… Se vai usar, pelo menos aprenda como, né!
Bom post….boas explicações…Vc teria uma sugestão de bibliografia OO?
Ah, só alguns detalhes…nada haver com programação…mas uns erros clássicos que deveriam ser evitados:
SmallTalk por que não existe[...]
IO por que não utiliza[...]
E Ruby por que as classes[...]
“Por que” (separado, sem acento) é advérbio interrogativo…usado em interrogativas diretas ou indiretas…e tb pode ser pronome relativo…
O correto seria utilizar “porque” (junto, sem acento) pois é uma conjunção coordenativa explicativa - estabelece uma causa - (ou subordinativa causal)…
Aqui tem “duas sem tirar”…
[...]com certeza ele não é usuário de sistema nenhum, por tanto você não deveria telo no seu sistema.
‘Portanto’ é conjunção conclusiva…’por tanto’ = preposição + pronome
‘telo’ só pode ser sacanagem, né?
hehehehe
desculpa….é que sou concurseiro tb…rs
Obrigado pelas correções, texto corrigido (eu acho :$ )
Parece que preciso voltar para o primário, ou conseguir um corretor gramatical pois só o ortográfico não esta dando conta
Considero que (como provavelmente o Urubatan jah sabe), as colocacoes que ele fez fazem muitissimo sentido.
Eu considero que a forma (platonica) com que as classes vem sendo tratadas eh algo extremamente prejudicial para a compreensao da orientacao a objetos.
Soh nao concordo q a programacao procedural seja um causador da confusao mental… eu mesmo comecei a programar em C e mesmo na ehpoca que programava em C jah conhecia conceitos como heranca e polymorphismo corretamente, alias, conhecer isso da ohtica de uma linguagem mais proxima a maquina foi pra mim de grande valia na compreensao da coisa.
O problema das pessoas esta em nao aprenderem a pensar sobre a coisa da forma certa! As pessoas nunca aprenderam foi a modelar aplicacoes, e as que confundem o uso de classes e objetos, mesmo se programarem sem ferramentas para orientacao a objetos, acabarao fazendo merda.
Eu creio que mesmo Ruby ainda nao chegou aos moldes ideias de tratamento de classes, mas jah eh certamente um avanco enorme se comparado ao Java… Soh nao acho os moldes do Ruby o ideal, pq coisas como a palavra chave class poderiam ter sido construidas como methodos do module Kernel, a exemplo dos methodos private, protected e public… mas de qqr forma, eh extremamente notohrio pela simplicidade com que se faz metaprogramacao no Ruby (ou nao se faz, afinal aquilo eh programacao mesmo), as vantagens de que uma boa compreensao do fato de que classes tbm devem ser tratadas como objetos… Eu hj soh vejo ganhos neste tipo de abordagem. Gostaria muito que implementacoes “mais puras” do Ruby, como o Rubinius, tivessem a corragem de dar um passo adiante nisso, tornando a linguagem completamente flexivel nestes termos, acabando de vez com o conceito de classe e module como algo a parte… Cada vez mais penso que a “linguagem OO ideal” nao tem palavras reservadas, hehe
Tenho estudado um pouco sobre a incorporacao de estrategias de parsing gramatical oo dentro de linguagens, com o intuito de ampliar a capacidade de trablho com DSLs (e MSLs, conceito que soh recentemente aprendi), e tenho visto o como seria fantastico se tivessemos essa flexibilidade da “REAL E TOTAL” orientacao a objetos em alguma linguagem “pratica” como Ruby, o que implicaria em muitas coisas com o fim desse tratamento diferenciado de uma classe por exemplo… Tenho sentido uma falta enorme disso…
De qqr forma, os alertas que vc apresentou aqui fazem MUITO sentido para mim, e nao acho nao que vc nao saiba escrever, pois para mim a coisa ficou bastante clara.
Caro Urubatan!
Sou um iniciante e auto didata, não sou engenheiro de software, nem muito menos tem vivencia nesta area.
Minha descendencia é da linguagem assembler e C++, utilizo em microcontroladores (muitissimo baixo nível).
Dentro da minha caminhada, ja percebi que entender o OO é primordial, e independe da linguagem, pois a capacidade de transportar a realidade para abstração no sistema criado para “imitar” a realidade fica muito mais fácil com esta sistematica!
Por favor se puder me indique mais literaturas sobre o tema, pois minha caminhada se faz sob os livros e artigos como estes.
Nos dias atuais construo um console para aplicação desktop para interligar nossos equipamentos com o usuario, o OO me deu condições de entender e prever até mesmo a evolução dos euipamentos e adaptação do ssitema.
De qualquer forma obrigado e parabens!
OOP é fácil……
… para quem n…
Urubatan, gostei muito do seu post!
Estou começando a programar, tentei aprender java sozinho, mas não consegui, fiz um curso depois pensando que iria entender melhor… e nada, e agora me motivei a aprender outras linguagens por conta até mesmo da minha area, pois trabalho como designer e webdesigner também. Então comprei um livro de CSS e outro de PHP (Desenvolvendo websites com PHP), estava todo empolgado, em apenas uma semana já li metade do livro, mas me deparei com FUNÇÕES e OOP, funções entendi direitinho, no caso eu posso criar uma função para conectar ao banco, fazendo testes de login e senha, e aplicar onde for necessario, mas quando cheguei na parte de OOP, ai realmente acho que muda a forma de pensar totalmente, veio um flashback na minha cabeça do Java, acho que fiquei meio que traumatizado rsrs… Então estou motivado a entender OOP melhor agora, antes de continuar a aprender PHP e outras linguagens. Sempre aprendi tudo sozinho, edição de fotos e videos, efeitos visuais e especiais usando after effects, e varias outras coisas, mas infelizmente o meu maior problema esta sendo OOP no momento, depois que eu ultrapassar essa barreira, tenho certeza que as coisas vão andar bem mais rapido.
Você teria como me indicar algum material ? PDF ou livros que eu possa aprender OOP?
Aguardo resposta por email se possivel!
Caro Ubiratan,
Bem escrito o seu post. Muito clara a sua mensagem, só gostaria de acrescentar alguns comentários:
Primeiro: A não utilização adequada das linguagens OO não se deve a aprendizado anterior em programação estrutural, e sim, aos péssimos livros e cursos sobre o assunto. Só pra exemplificar sempre começam com a explicação do porque do termo “orientado a objetos”, relacionar com o mundo “real”, ai, você cita nos seus exemplos o objeto venda. Deu pra entender que o cérebro já entra em parafuso “venda” não é objeto no mundo real e pronto. Então a abstração está errada. Seria mais interessante a explicação no mundo da programação mesmo, metodos são funções aplicados aos objetos da mesma classe e por ai vai…
Segundo: Já li muito sobre orientação a objetos e não achei um único livro que explicasse com decência os padrões de desenvolvimento, com exemplos de programação mesmo, sem aquela conversa de “imagine um carro…”. Também não li nenhum exemplo MVC que mostrasse a tão sonhada implementação sem misturar “negócio” com controle e por ai vai.
Conclusão: A abstração é péssima para o aprendizado, e programação procedural não impede o aprendizado da orientação a objetos, e nem aprender uma na frente da outra é melhor, o que, faz alguém aprender algo é esforço, e bons professores.
Urubatan, vc comentou no seu post o seguinte:
“Outro erro bastante comum é tentar colocar em uma classe apenas o comportamento de todo o sistema, se for para fazer isto, utilize programação procedural, pois você vai estar utilizando a classe apenas como namespace mesmo, não vai nem lembrar que em tempo de execução estara trabalhando com diversos objetos criados a partir daquela forma.”
isso inclui ou exclui o padrão Facade? pois o padrão facade diz que você deve ter uma classe que sirva de atalho para todas as funcionalidades do sistema, e somente o objeto facade deve ser usado para se ter acesso a essas funcionalidades…
Fiquei com essa dúvida e resolvi comentar…
Abraços!
Gostei do post.
De fato muita gente complica o que é muito simples.
Quanto ao comentário acima (do Tiago ) eu uso Facade em todos meus projetos WEB e com muita satisfação. Eles funcionam oras ^^. Mas nem por isso deixo de usar OO pois a camada que está abaixo do Facade é toda OO.
Gosto de usar o Facade pois sei que toda solicitação de página passa por ali e facilita o debug, mas ele apenas é um seletor de serviços. Na realidade ele em si pode muito bem ser encarado como um objeto, pois ele tem propriedades e pelo menos uma ação (selecionar). Eu tenho um objeto Facade com ações genéricas e para cada projeto eu crio um mais especializado com ações mais específicas (e principalmente com a ação seletora).
Em cada seleção, ele joga o request, o response dentro de um objeto Request (que também criei) e dá execute (principal ação do meu objeto Request). Tudo pode sempre ser abstraido na forma de objetos, claro que tudo tem limites. ^^
bah meu muito bom esse post …
vlw..