Apenas quero partilhar convosco um artigo que publiquei no CodeProject acerca de um padrão que descobri que possibilita ter estado privado em instâncias de objectos JavaScript:
http://www.codeproject.com/KB/ajax/SafeFactoryPattern.aspx
A quem interessar!
Duarte Cunha Leão
[Este é o terceiro artigo da série “A Arquitectura Aplicacional” I) Introdução II) Análise de Características]
No último artigo abordei algumas das características que caracterizam (esta é que não sabiam) uma arquitectura aplicacional. Não foi feita uma análise exaustiva, pelo que, com certeza, muitas características importantes terão não sido referidas. Como exemplo, não foi referida, explicitamente, a vulgar característica «expansibilidade» [reconheço que a palavra não me soa perfeita; mas não consegui encontrar as palavras «escalabilidade» ou «escalável», num dicionário de português (de Portugal), mas apenas: escala, escalar, escalada, escalamento, escalagem e escalador. Por isso, acabei por preferir os tradicionais termos «expansibilidade» e «expansível», utilizados aqui à semelhança de em “slot de expansão”], que descreve a aptidão de uma arquitectura para poder crescer, em termos de carga suportada, ou na sua distribuição geográfica.
Neste artigo, exploro algumas características que, julgo, são hoje subestimadas no desenho de sistemas e arquitecturas aplicacionais.
É comum dar-se muita importância a cada um dos componentes ou módulos de um sistema e menosprezar a importância que tem o que os une, os liga e o que partilham e trocam uns com os outros.
Estamos na época da modularidade, e de pouco mais. Também já não é mau, reconheço que podia ser pior. É-nos suficiente. Satisfaz-nos. Decora as soluções com traços de inteligência e complexidade, o que fica sempre bem. Enche o olho de quem compra. O deslumbramento é tanto que nem se quer saber o que é que está dentro dos módulos, as caixas, pretas. São quartos escuros, geralmente com tanta luz quanta inspiração e cuidado.
Na pior das hipóteses, se se descobrir que um módulo não presta: deita-se este fora e troca-se por outro. É higiénico, não se toca em mais nada (tal como se faz hoje em dia com as placas de circuito impresso — nem vale a pena tentar descobrir qual o transístor que está queimado).
A modularidade é uma característica imprescindível de qualquer sistema e arquitectura. Só não deve é ser utilizada para esconder o lixo debaixo do tapete. Como qualquer arma, esta pode ser usada bem ou mal. Para flexibilizar, separar, proteger e arrumar, ou para esconder a confusão, o desmazelo e a ignorância.
Eis algumas máximas, todas elas válidas em devido contexto, mas que, evocadas de cor, facilmente conduzem a um uso medíocre da modularidade:
“Depois, se houver tempo, faz-se melhor…”
“A qualquer altura se substitui…”
“Faz-se iterativamente e acrescenta-se faseada e oportunamente”
“É uma questão de compromisso entre isto e aquilo…”
“O óptimo é inimigo do bom…”
“Não sejamos mais papistas que o P
áapa”.
Notem os seguintes, igualmente válidos, dizeres:
“Raramente há tempo e oportunidade para melhorar o que já está (mais ou menos) feito”
“O que nasce torto (ou incompleto) tarde ou nunca se endireita (ou completa)”
“Quando não há vontade, qualquer razão serve…”
“O bom também é inimigo do óptimo”
“Com o mal dos outros posso eu bem”
“A qualidade compensa, gasta-se agora, ganha-se depois”
“Para hábil executor é tão mais fácil fazer bem do que mal”
A modularidade é tanto acerca de caixas como de ligações.
Deparados com um monólito de 1000 linhas [porque não em C#, já que este é um blog ligado a tecnologias Microsoft], feito por um qualquer colega insano [que devia ser mandado para o Campo Pequeno e…], a necessidade imperativa de reposição da ordem que invade qualquer programador que se preze, debate-se imediatamente com o seguinte: para separar, há que ligar a seguir. É essa a razão por que mentes preguiçosas, sob a pressão dos prazos, se ficam pelo monólito: “É mais seguro, fica tudo juntinho e não se perde”.
De que são feitas as ligações? De um fio condutor e dos electrões. Isto na electricidade, é claro, porque no caso das aplicações informáticas, é, surpreendentemente, a mesma coisa. Façamos F = “fio condutor” e E = “electrão”. Entre funções de um programa: F = “variável” e E = “um inteiro”, entre uma página web e o seu servidor: F = “canal tcp/ip, protocolo http” e E = “conteúdo do body da mensagem http”, e por aí adiante.
A flexibilidade de um sistema deve-se à flexibilidade das ligações entre os seus módulos.
Uma ligação não é flexível apenas por existir (existo logo sou flexível?). Uma função não está ligada de forma flexível às funções suas chamadoras apenas por ter muitos parâmetros de entrada (e, eventualmente, vários de saída). Não é tanto a quantidade de ligações que traz a flexibilidade, mas antes a qualidade do que as atravessa.
A flexibilidade de um conjunto de ligações é função do número de fins que estas podem produzir.
Eis um exemplo da “vida real”. O corpo humano, assim como muitos outros organismos vivos, é um sistema extraordinariamente flexível. A sua flexibilidade deve-se em grande medida à flexibilidade do seu (sub-)sistema de ligações. Os vasos sanguíneos — o canal condutor, F — ligam todos os pontos do corpo; pelo meio, atravessam barreiras físicas, como as articulações entre os membros, sem prejudicar a sua mobilidade; penetram fundo nos seus órgãos internos. O sangue — o líquido portador — viaja nos vasos sanguíneos levando consigo alimentos, glóbulos e demais agentes de toda a espécie — E.
A reter:
Todos os sistemas bem sucedidos, que sobrevivem, perduram e evoluem, são flexíveis. Têm como suporte às ligações entre as suas partes um (sub-)sistema de ligações flexível.
O domínio do que é comunicado, do que viaja através dos canais de comunicação, é, na mais geral das hipóteses, todo o conhecimento (“the sky is the limit”), cujo elemento abstracto se denomina de «coisa». Pode ser uma mensagem, um “objecto”, um número inteiro, uma entidade de negócio, enfim, qualquer «coisa».
Quanto mais tipos diferentes de «coisas» puderem passar por uma ligação, maior será a sua flexibilidade. Maior será, também, a dificuldade de lidar com “tanta «coisa»”. Por isso, a utilização eficiente das ligações, passa por descobrir, para o problema subjacente aos módulos ligados, qual é o menor conjunto de «coisas» que o descreve.
Actualmente, quando se desenham sistemas e arquitecturas, nmho, não se tira partido de um eficiente desenho do modelo de entidades de negócio. É comum que cada módulo ou camada de um sistema tenha o seu bem diferente modelo de entidades, do mesmo negócio. Não são apenas diferentes vistas parciais de um mesmo modelo, de acordo com as necessidades de cada um. São antes diferentes, contraditórias, e igualmente infiéis representações de um mesmo modelo de negócio, que todos mal conhecem.
A utilização de um modelo de dados comum em todo um sistema é o maior potenciador da sua eficiência, a todos os níveis, e da simplicidade conseguida nas suas ligações [reveja-se o corpo humano].
No próximo artigo, abordarei alguns sentidos desafios do desenho de um tal modelo de dados. Até lá. Não resistam. Pensem nisto.
Caros colegas, quantas vezes a nossa produtividade se resume à (rápida) acessibilidade da informação?
Várias vezes dou por mim à procura, pela centésima vigésima primeira vez, daquele help porreiro de JavaScript, ou, a dizer: “onde é que eu tenho aquele snippet para escrever o raio de um DOCTYPE de xhtml…será que está na pen ou no computador de casa…”
Isto é típico das matérias que não usamos todos os dias, mas só dia-sim, dia-não :-).
Por isso achei um espectáculo encontrar um post que faz um apanhado de várias “cheat sheets”, de várias tecnologias, a maioria, prontas a imprimir numa folha A4, ou ver no Acrobat:
http://john-sheehan.com/blog/index.php/net-cheat-sheets/
É claro que as cábulas só interessam a quem sabe mais do que aquilo que elas tiverem, resultado da elevada compressão (com perdas) da informação constante :-)
[Este é o segundo artigo da série “A Arquitectura Aplicacional” I) Introdução III) Factores de Sobrevivência]
Depois de tão aplaudida estreia não tenho outro remédio senão continuar a série de artigos sobre a “A Arquitectura Aplicacional”. Agradeço, desde já, os hipotéticos futuros aplausos.
Hoje, ao ler (mais que tardiamente) o artigo do Joaquim Ferreira abriu-se-me o apetite para a escrita!
Tal como prometi no último artigo, vamos baixar a altitude. Colegas consultores: peço-vos que desabotoem os punhos das camisas e arregacem as mangas, pois vamos sujar um pouco as mãos [isto do consultor de colarinho branco e botões de punho não joga, nmho, muito bem com a programação, e com o trabalho em particular, também].
No último artigo concluímos que não existe uma só arquitectura aplicacional que seja adequada para servir todos os sistemas. Mas que, por outro lado, existem características de uma arquitectura que nos permitem classificar e escolher de entre as infinitas arquitecturas existentes. Que características são essas? As seguintes características são positivas:
Outras características positivas, muito abrangentes, mas, de fulcral importância:
Pois, a cada sistema, a arquitectura que lhe seja fiel.
Muitas outras características existem, com certeza [gostaria que o meu leitor imaginário comentasse sobre elas…].
Mas há uma que deixei de fora, de propósito, pois será o tema do próximo artigo.
Acabámos por não sujar mais do que a ponta dos dedos.
[Este é o primeiro artigo da série “A Arquitectura Aplicacional” II) Análise de Características III) Factores de Sobrevivência]
Quero partilhar convosco algumas ideias acerca de arquitecturas para o desenvolvimento de aplicações (i.e. software!). Tal como salienta o ambicioso título, vamos descobrir “A Arquitectura Aplicacional” — aquela que será o Santo Graal das arquitecturas aplicacionais. A sério, não vamos descobrir nada de novo. Vamos apenas olhar para aquilo que já conhecemos, que, provavelmente, já usamos, e dedicar-lhe algum do nosso tempo. O tema é vasto o suficiente para justificar que o abordemos em vários artigos. Este é o primeiro artigo da série que se seguirá.
Arquitecturas há muitas, tantas quantas se quiser inventar. No limite da interpretação, cada sistema é uma arquitectura, e há infinitos sistemas. No entanto, tais arquitecturas seriam de pouco valor, para lá dos sistemas que as originaram, por serem tão talhadas para eles. Já não seriam arquitecturas. Seriam só mais uns sistemas.
No outro extremo, existiria uma arquitectura tão geral que se aplicaria a todos os infinitos sistemas. Não teria nada de específico. Não serviria para nada. Não seria uma arquitectura. Mas é pena. Eu adorava que existisse.
Se não existe “A Arquitectura Aplicacional”, existirão pelo menos boas e más arquitecturas. Podemos identificar características destas que nos permitam entendê-las e desenhá-las melhor, quem sabe, até, que permitam abstrair-mo-nos dos sistemas originais.
A arquitectura clássica (quem sou eu para afirmar isto?) trata do problema da organização do homem no espaço. Lida com a relação do “homem com os seus objectos”; estes últimos vão desde o mobiliário, aos edifícios e à paisagem. Os objectos da arquitectura aplicacional são outros (passo a piada). São sistemas, processos, componentes, pacotes, entidades, classes, interfaces, tabelas, camadas, contratos, padrões, interacções e mais uns quantos que, sinceramente, não me recordo. A arquitectura aplicacional trata do problema da organização do homem no espaço, virtual.
É isso então. Temos apenas que compreender melhor a natureza das diferentes relações entre estes objectos (e entre os objectos e o homem). Esse conhecimento, servir-nos-á de guia para desenhar qualquer arquitectura que venha a ser necessária.
No próximo artigo vamos baixar um pouco a altitude. O ar por aqui é rarefeito.
