> Pergunta: Na sua opinião, para uma equipe isso poderia ser induzido (regras) > de forma a nivelar ou direcionar a ação que ela promove? Eu acho que sim. Talvez o real benefício do que eu chamei de Conceptual Constraints seja "resumir" determinados conceitos numa espécie de "Guidelines do que NÃO DEVE ser feito".
Este conceito nasceu de um problema que enfrentamos com uma equipe de desenvolvedores que, na época, estavam começando a desenvolver em Flex. Primeiro falamos para eles trabalharem com eventos e logo havia eventos desnecessários espalhados por toda a aplicação. Depois voltamos atrás e falamos para tirar proveito do DataBinding, mostramos o ChangeWatcher e logo havia ChangeWather toda a aplicação. Foi então que percebemos que não deveríamos falar como fazer e sim o que não deve ser feito num nível conceitual. O problema é que solução alguma atenderá todas as situações e quando você impõe uma solução são grandes as chances dela ser mal usada em diversas situações para as quais ela não é adequada. Agora, quando você diz o que não deve ser feito num nível mais conceitual, creio que aumentam as chances dos desenvolvedores encontrarem boas soluções para as mais variadas situações. E justamente por não conhecer o que não deve ser feito num nível mais conceitual muitos desenvolvedores acabam achando que o Cairngorm ou o PureMVC e desnecessário. []'s Beck Novaes On Aug 19, 2:44 pm, "Vicente Maciel Junior" <[EMAIL PROTECTED]> wrote: > Citações/Questões... > > > Definição > > ======= > > Conceptual Constraints são conceitos que você mantém na mente e que > > lhe obrigam a procurar outras alternativas para resolver um problema, > > pois você sabe que as soluções que lhe ocorreram num primeiro instante > > irão violar estes conceitos. > > Perfeito! > Pergunta: Na sua opinião, para uma equipe isso poderia ser induzido (regras) > de forma a nivelar ou direcionar a ação que ela promove? > Fiquei com dois pensamentos distintos a respeito: > Sim... vamos induzir. > Esperado: Fluxo de pensamento e esforço no mesmo nível e direção. > Possível: Criatividade = nenhuma ou menos regras (positivo? negativo?) > > > Exemplos de Conceptual Constraints do Cairngorm: > > - O ModelLocator não deve saber nada do Command nem da View > > - O Command não deve saber nada da View > > - A View não deve saber nada do Command > > - O ModelLocator é possível manter o estado no cliente, mas os dados > > nele armazenados devem ter um significado semântico. No lugar de > > preço, nome e descrição, devemos ter um objeto Produto no > > ModelLocator. Além disto, estes objetos, muitas vezes devem encapsular > > lógica de negócio – o que possibilita a realização de testes unitários > > - Os Commands são as Worker Classes do Cairngorm. Como tal, elas devem > > prover a funcionalidade de negócios do seu aplicativo. > > - Nada impede que o Command tenha apenas um método "execute". > > Excelente descrição da estrutura do Cairngorm. Pode ter passado despercebido > por mim, mas é a primeira vez que a vejo em portugues de forma objetiva. > > -- > Vicente Maciel Junior > Independent Web Developer & Consultant > Adobe Advanced Certified Developer > Adobe Certified Instructor (ColdFusion & Flash Platform) > +55 (71) 8120-0035 / 9212-0909 - MSN: [EMAIL > PROTECTED]://teclandoalto.blogspot.com --~--~---------~--~----~------------~-------~--~----~ Você recebeu esta mensagem porque está inscrito na lista "flexdev" Para enviar uma mensagem, envie um e-mail para [email protected] Para sair da lista, envie um email em branco para [EMAIL PROTECTED] Mais opções estão disponíveis em http://groups.google.com/group/flexdev -~----------~----~----~----~------~----~------~--~---
