Em meu último artigo, Porque eu odeio frameworks, traduzi uma parábola fictícia que critica a crescente complexidade dos frameworks. Se você não tem muita experiência com Design Patterns (Padrões de Projeto) e com diversificados frameworks, provavelmente não tenha entendido ou mesmo achado o texto pouco interessante.
Agora, sendo mais direto, irei analisar nos tópicos a seguir alguns dos problemas e dificuldades que devemos nos precaver quando usamos frameworks e bibliotecas. Escolhas erradas impactam todas as fases do desenvolvimento de um sistema!
Complexidade excessiva
Quando aprendemos sobre Design Patterns e princípios como coesão e desacoplamento, temos a tendência de considerar tudo isso como soluções mágicas para os problemas de complexidade do software. Alguns começam a aplicá-los indiscriminadamente de forma que, mesmo operações que antes eram simples, exigem agora diversas classes para implementação e conhecimentos de vários conceitos para o entendimento.
Quando ainda estamos nessa fase de “descoberta”, onde acreditamos cegamente nas “vantagens”, sem compreender as consequências de nossas decisões ou mesmo a correta aplicação dos padrões, podemos acabar com dezenas de frameworks pendurados em nossos sistemas e inúmeras classes adicionais mesmo para tarefas simples. Já ouviu a expressão “matar uma mosca com um canhão?”
Soluções “genéricas”
Bons frameworks e bibliotecas possuem aplicações bem definidas. Nenhum framework é tão bom e completo a ponto de ser usado em todo e qualquer projeto. Nem mesmo uma determinada arquitetura como o MVC, por exemplo, mas infelizmente não é sempre assim que aprendemos na teoria.
Por outro lado, nós, desenvolvedores, somos culpados muitas vezes de usar um framework ou biblioteca indiscriminadamente, simplesmente porque já temos algum conhecimento.
Comprometimento da Arquitetura
Muitos frameworks são intrusivos no que diz respeito à arquitetura do software. Isso quer dizer que eles nos obrigam a tomar certas decisões arquiteturais simplesmente para que eles funcionem.
Infelizmente, a realidade hoje é que a grande maioria dos sistemas existentes possuem suas regras de negócios codificadas conjuntamente com classes específicas de terceiros. Não sabemos, e talvez nem pensemos sobre isso, o quanto somos orientados a tecnologias. Para falar a verdade, eu reconheço que também sou culpado disso. Quando codificamos, na maior parte das vezes, estamos mais preocupados com questões técnicas do que em realmente atender aos requisitos. Ou pior, quantas vezes não queremos simplesmente concluir o trabalho e não nos preocupamos com a qualidade interna do código? Infelizmente, a “preguiça” do programador em codificar corretamente é um dos grandes fatores que fazem crescer o número de defeitos e o número de horas extra.
Conclusão
Infelizmente, é preciso queimar muitos neurônios para criar frameworks e bibliotecas que, sendo flexíveis, não sejam demasiadamente complexos e intrusivos nos sistemas. E o mesmo se aplica ao uso deles. Bons programadores devem saber não apenas como configurar, instanciar e executar objetos de frameworks e bibliotecas, mas principalmente sua precisa escolha e aplicação.
Por fim, para divertimento dos nerds de plantão, selecionei um exemplo de um Hello World em Java que abusa um pouco da complexidade. Ele serve para ilustrar como é possível complicar algo tão trivial.
public interface MessageStrategy {
public void sendMessage();
}
public abstract class AbstractStrategyFactory {
public abstract MessageStrategy createStrategy(MessageBody mb);
}
public class MessageBody {
Object payload;
public Object getPayload() { return payload; }
public void configure(Object obj) { payload = obj; }
public void send(MessageStrategy ms) {
ms.sendMessage();
}
}
public class DefaultFactory extends AbstractStrategyFactory {
private DefaultFactory() {}
static DefaultFactory instance;
public static AbstractStrategyFactory getInstance() {
if (null==instance) instance = new DefaultFactory();
return instance;
}
public MessageStrategy createStrategy(final MessageBody mb) {
return new MessageStrategy() {
MessageBody body = mb;
public void sendMessage() {
Object obj = body.getPayload();
System.out.println(obj.toString());
}
};
}
}
public class HelloWorld {
public static void main(String[] args) {
MessageBody mb = new MessageBody();
mb.configure("Hello World!");
AbstractStrategyFactory asf = DefaultFactory.getInstance();
MessageStrategy strategy = asf.createStrategy(mb);
mb.send(strategy);
}
}
* Extraído de http://seenonslash.com/node/465
O desenvolvedor aprende sobre alguns processos, metodologias, normas ou padrões. Ele adota uma metodologia, um par de padrões e tenta seguir tudo à risca, acredita que toda regra estabelecida é importante e todos os que não acompanham nesse pensamento estão errados, não entendendo como essas pessoas podem ser tão tolas.
O desenvolvedor consciente trabalha com base em princípios. Ele utiliza esses princípios para selecionar a melhor abordagem para cada situação, extraindo regras de metodologias existentes, mas aplicando-as com sabedoria quando elas devem ser aplicadas.
