Sim, fui eu que inventei o termo! :) (Se bem que já espreitei este tema na net e acho que o termo não é lá muito original :))
Também podia ser BOP (Business Oriented Programming), p'ra dar um ar mais académico à coisa! :))
O que é?
Esta estratégia de desenho/implementação parece estar a ganhar cada vez mais força. Trata-se de pensar num sistema pensando primariamente nas necessidades de negócio, ie, nas necessidades dos clientes (utilizadores) do sistema.
Não é fácil! Muda um pouco (muito!) o algoritmo mental, habituado a pensar mais em pormenores técnicos do que na vertente de negócio.
Li uma noticia na net sobre um empresário da Escandinávia que reformulou uma companhia aérea, focando a estratégia da organização nos passageiros, e não tanto nos aviões, nas infraestruturas e outros factores que para o cliente não interessam primariamente.
Cito: "Hoje, nas reuniões de planeamento de sites, felizmente vejo uma preocupação maior em servir o usuário. Antes, as reuniões eram sobre o servidor X ou tecnologia Y. Por que hão-de o servidor X e a Tecnologia Y ter impacto na satisfação do meu utilizador?"
http://webinsider.uol.com.br/index.php/2007/05/14/web-20-oferece-momento-unico-a-cada-acesso
Como é que isso afecta a minha forma de programar?
Bem, são inúmeras as coisas que 'mudam' ao adoptar esta abordagem. Eu própria ainda ando a descobrir algumas! :)
Mas aqui ficam já algumas dicas.
- Nomes dos objectos:
. Os nomes que damos aos objectos devem reflectir aquilo que eles de facto são. Por exemplo, o objecto Produto diz-nos que a sua responsabilidade é lidar com as funcionalidades de manipulação de Produtos.
- Nomes dos métodos:
. Os métodos devem ter nomes significativos para o negócio, nao para o código! Por exemplo, nomes como somarValores(), ou adicionarLinha() não dizem muito sobre o negócio. Mas por exemplo, nomes como calcularPreco() ou adicionarProduto() são já mais elucidativos.
- Trabalhar a partir do Domain Model, não das Vistas:
. Aprendi da pior forma que esta é a abordagem correcta! :) Lembram-se do MVC (alguns posts atrás)? Pois então! A vista é manipulada pelo Controlador, com base no Modelo. Não o contrário! Há alguns dias tive de implementar uma alteração (de negócio!) a um sistema, e comecei por onde? Pela Vista... Pois! Devia ter começado pelo Modelo, porque se o tivesse feito iria perceber que as horas que perdi a mexer na Vista quase não teriam sido necessárias, já que se tratava de uma alteração ao Modelo, que iria afectar a Vista. Não o contrário!
Estas são apenas algumas dicas, de entre muitas.
O cerne da questão é a orientação ao negócio como ponto de partida. Ao pensar assim, o passo seguinte é olhar para o Modelo, que, precisamente(!), modela o negócio. Tudo o resto acaba depois por fluir.
Não é muito fácil, porque é acima de tudo uma mudança de mentalidade. Mas compensa!
Divirtam-se! ;)
Também podia ser BOP (Business Oriented Programming), p'ra dar um ar mais académico à coisa! :))
O que é?
Esta estratégia de desenho/implementação parece estar a ganhar cada vez mais força. Trata-se de pensar num sistema pensando primariamente nas necessidades de negócio, ie, nas necessidades dos clientes (utilizadores) do sistema.
Não é fácil! Muda um pouco (muito!) o algoritmo mental, habituado a pensar mais em pormenores técnicos do que na vertente de negócio.
Li uma noticia na net sobre um empresário da Escandinávia que reformulou uma companhia aérea, focando a estratégia da organização nos passageiros, e não tanto nos aviões, nas infraestruturas e outros factores que para o cliente não interessam primariamente.
Cito: "Hoje, nas reuniões de planeamento de sites, felizmente vejo uma preocupação maior em servir o usuário. Antes, as reuniões eram sobre o servidor X ou tecnologia Y. Por que hão-de o servidor X e a Tecnologia Y ter impacto na satisfação do meu utilizador?"
http://webinsider.uol.com.br/index.php/2007/05/14/web-20-oferece-momento-unico-a-cada-acesso
Como é que isso afecta a minha forma de programar?
Bem, são inúmeras as coisas que 'mudam' ao adoptar esta abordagem. Eu própria ainda ando a descobrir algumas! :)
Mas aqui ficam já algumas dicas.
- Nomes dos objectos:
. Os nomes que damos aos objectos devem reflectir aquilo que eles de facto são. Por exemplo, o objecto Produto diz-nos que a sua responsabilidade é lidar com as funcionalidades de manipulação de Produtos.
- Nomes dos métodos:
. Os métodos devem ter nomes significativos para o negócio, nao para o código! Por exemplo, nomes como somarValores(), ou adicionarLinha() não dizem muito sobre o negócio. Mas por exemplo, nomes como calcularPreco() ou adicionarProduto() são já mais elucidativos.
- Trabalhar a partir do Domain Model, não das Vistas:
. Aprendi da pior forma que esta é a abordagem correcta! :) Lembram-se do MVC (alguns posts atrás)? Pois então! A vista é manipulada pelo Controlador, com base no Modelo. Não o contrário! Há alguns dias tive de implementar uma alteração (de negócio!) a um sistema, e comecei por onde? Pela Vista... Pois! Devia ter começado pelo Modelo, porque se o tivesse feito iria perceber que as horas que perdi a mexer na Vista quase não teriam sido necessárias, já que se tratava de uma alteração ao Modelo, que iria afectar a Vista. Não o contrário!
Estas são apenas algumas dicas, de entre muitas.
O cerne da questão é a orientação ao negócio como ponto de partida. Ao pensar assim, o passo seguinte é olhar para o Modelo, que, precisamente(!), modela o negócio. Tudo o resto acaba depois por fluir.
Não é muito fácil, porque é acima de tudo uma mudança de mentalidade. Mas compensa!
Divirtam-se! ;)
1 comment:
Incluo como comentário parte de uma pequena discussão que tive à volta do tema por email, e que acho que pode ser interessante.
Divirtam-se! :)
-----
Daquilo que percebi o que é o PON, são mais ou menos as regras definidas para nomenclaturas utilizadas para os "objectos técnicos".
A utilização de uma linguagem ubíqua entre o negócio e a tecnologia permite estabelece paralelos entre estes 2 mundos de uma forma mais simples e natural. Esta regra é uma "regra de bolso" amplamente estabelecida e aceite (embora não praticada ;)).
Pensa só neste cenário : uma empresa que produz software com algumas dezenas de programadores.
Imagina o que será se cada programador utilizar a sua própria "linguagem" para se exprimir no código que produz.
Pedro N. L.
O que tentei transmitir no post é precisamente a importância/vantagens de utilizar uma estrategia do tipo PON. Vai um pouco além de utilizar apenas nomenclaturas para "objectos técnicos".
Citando: "Trata-se de pensar num sistema pensando primariamente nas necessidades de negócio, ie, nas necessidades dos clientes (utilizadores) do sistema. "
Porque acaba por afectar a nossa forma de programar. Precisamente por causa do que disseste: "Esta regra é uma "regra de bolso" amplamente estabelecida e aceite (embora não praticada ;))."
Nyrian
Post a Comment