Estrutura de software

br>>p> Os designers de estruturas de software visam facilitar o desenvolvimento de software, permitindo aos designers e programadores dedicarem o seu tempo a satisfazer os requisitos de software em vez de lidarem com os detalhes de baixo nível mais padronizados do fornecimento de um sistema de trabalho, reduzindo assim o tempo global de desenvolvimento. Por exemplo, uma equipa que utiliza uma estrutura web para desenvolver um website bancário pode concentrar-se na escrita de código específico para a banca em vez da mecânica de tratamento de pedidos e gestão do estado.

Frameworks acrescentam frequentemente ao tamanho dos programas, um fenómeno denominado “inchaço do código”. Devido às necessidades das aplicações orientadas para a procura do cliente, tanto as estruturas concorrentes como as complementares acabam, por vezes, num produto. Além disso, devido à complexidade das suas APIs, a redução pretendida no tempo global de desenvolvimento pode não ser alcançada devido à necessidade de gastar mais tempo a aprender a utilizar a estrutura; esta crítica é claramente válida quando uma estrutura especial ou nova é encontrada pela primeira vez pelo pessoal de desenvolvimento. Se tal estrutura não for utilizada em tarefas subsequentes, o tempo investido na aprendizagem da estrutura pode custar mais do que o código propositadamente escrito familiar ao pessoal do projecto; muitos programadores guardam cópias de uma placa de caldeira útil para necessidades comuns.

No entanto, uma vez que uma estrutura é aprendida, os projectos futuros podem ser mais rápidos e mais fáceis de completar; o conceito de uma estrutura é fazer um conjunto de soluções de tamanho único, e com familiaridade, a produção de código deve aumentar logicamente. Não existem tais afirmações sobre o tamanho do código eventualmente associado ao produto final, nem a sua relativa eficiência e concisão. A utilização de qualquer solução de biblioteca implica necessariamente a utilização de extras e activos estranhos não utilizados, a menos que o software seja um compilador-objector de ligação tornando um módulo executável apertado (pequeno, totalmente controlado, e especificado).

A questão continua, mas uma década mais de experiência da indústria mostrou que as estruturas mais eficazes acabam por ser as que evoluem da re-facturação do código comum da empresa, em vez de utilizar uma estrutura genérica de “tamanho único” desenvolvida por terceiros para fins gerais. Um exemplo disso seria como a interface do utilizador num pacote de aplicações como uma suite de escritório cresce para ter uma aparência, sensação, e atributos e métodos comuns de partilha de dados, uma vez que as outrora díspares aplicações agrupadas, crescem unificadas numa suite que é mais restrita e mais pequena; a suite mais recente/evolutiva pode ser um produto que partilha bibliotecas de utilitários e interfaces de utilizador integrais.

Esta tendência na controvérsia levanta uma questão importante sobre frameworks. Criar uma estrutura que seja elegante, versus uma que apenas resolva um problema, ainda é mais um ofício do que uma ciência. A “elegância do software” implica clareza, concisão, e pouco desperdício (funcionalidade extra ou estranha, grande parte da qual é definida pelo utilizador). Para aquelas estruturas que geram código, por exemplo, “elegância” implicaria a criação de código limpo e compreensível para um programador razoavelmente conhecedor (e que é, portanto, facilmente modificável), versus um que apenas gera código correcto. A questão da elegância é a razão pela qual relativamente poucas estruturas de software resistiram ao teste do tempo: as melhores estruturas foram capazes de evoluir graciosamente como a tecnologia subjacente sobre a qual foram construídas de forma avançada. Mesmo aí, tendo evoluído, muitos desses pacotes irão reter as capacidades herdadas, inchando o software final, já que métodos substituídos foram retidos em paralelo com os métodos mais recentes.