O contra destas duas abordagens é que perdemos a capacidade de um teste direto, precisando realizar uma injeção de memória para que possamos mockar o objeto e testá-lo.
O último padrão que vamos comentar é o FlyWeight, ou, literalmente, “peso mosca”. Como o próprio nome já diz, este padrão tem como foco a criação de objetos mais leves e que ocupam menos memória. Ele faz isso por permitir que você utilize mais de um objeto para armazenar um estado compartilhado ao invés de guardar o estado todo em um único objeto.
Um exemplo interessante é o compartilhamento de propriedades em jogos. Por exemplo, quando estamos jogando, partículas e projéteis do jogo geralmente possuem algumas propriedades idênticas, como as cores e o sprite. Estas propriedades podem ser compartilhadas ao invés de serem copiadas para todas as instâncias das partículas.
O padrão flyweight cria o conceito de estados externos e estados internos. Os estados externos são todos os dados que podem ser alterados entre uma instância e outra, enquanto o estado interno são os dados imutáveis pertencentes a todas as classes do grupo.
Na partícula do jogo, o estado externo serão as propriedades que se alteram de tempos em tempos, enquanto o estado interno (ou intrínseco) é tudo aquilo que elas compartilham entre si.
Importante: lembre-se de que este padrão não é nada mais do que uma otimização, ou seja, não saia aplicando ele sem antes ter certeza de que o problema que você está enfrentando é, de fato, um problema de falta de memória por repetição.
1. A classe Flyweight tem o estado repetitivo, ou seja, o estado interno da classe que será otimizada
2. A classe Context contém o contexto, que é o estado externo, ou seja, as partes da classe que se alteram