Para clarear a coisas, a abstração de envio e a hierarquia de classes correspondente era algo do tipo:
class FileSender
{
public:
virtual sendFile(string filename, string destination) = 0;
};
class FTPFileSender: public FileSender
{
public:
sendFile(string filename, string destination) {...}
};
class SMBFileSender: public FileSender
{
public:
sendFile(string filename, string destination) {...}
};
Claro, a ideia era que usassem um factory method para a criação dos objetos. E todos acertaram esta parte. Todos implementaram um método FileSender::create, estático que fazia algum return new, criando objetos das classes filhas FTPFileSender ou SMBFileSender e retornando um FileSender* apontando para o objeto criado.
Até aqui 100%. O problema é que a maioria fez o seguinte:
typedef enum {FTP, SMB} FileSenderType;
FileSender::create(FileSenderType type)
{
switch(type)
{
case FTP:
return new FTPFileSender;
case SMB:
return new SMBFileSender;
default:
//Log error and abort.
}
}
void main()
{
cout << "SMB ou FTP?" << endl;
FileSenderType myType;
// Alguma lógica para ler resposta do usuário e guardar em myType...
FileSender* fileSender = FileSender::create(myType);
fileSender->send(.....);
}
Ah, então me acompanhe...
Me descreva o que a "factory" está fazendo e o que ela está poupando de trabalho para seu usuário (a main, no caso). Com um pouco de cuidado você vai concluir que ela não poupa trabalho nenhum da main. Na verdade, a factory não está fazendo NADA. Ela é código inútil, pois não engloba nenhuma abstração, não poupa nenhum trabalho da camada acima. Pense o que aconteceria se você colocasse os news direto na main; haveria alguma desvantagem? Obviamente não. Por isso a "factory" acima implementada não serve para nada.
Não está convencido? Então imagine que agora queremos adicionar a possibilidade de envio de arquivos por SSH. Isto será feito criando uma nova classe SSHFileSender. Mas, com esta adição, vamos ter de mexer na main (código usuário), certo? Pois é. Agora imagine um caso mais real... Em vez de um ponto só de uso, um programa real pode ter muitos pontos de uso espalhados. E, para adicionar uma funcionalidade específica de FileSenders, vamos ter de sair procurando pelo código inteiro... Ruim, não? Pois é. E pensar que o pattern factory foi criado justamente para evitar isto...
Dá para melhorar? Dá sim. Vamos atentar para o fato de que a "factory" implementada não faz nada e é código inútil. Vamos tentar dar alguma utilidade para esta nossa FileSender::create(). Que tal se ela se responsabilizasse por perguntar ao usuário qual FileSender usar? Ou seja, colocar dentro dela o código que o pessoal colocou na main:
FileSender::create()
{
typedef enum {FTP, SMB} FileSenderType;
cout << "SMB ou FTP?" << endl;
switch(chosenType)
FileSenderType chosenType;
// Alguma lógica para ler resposta do usuário e guardar em chosenType...
switch(chosenType)
{
case FTP:
return new FTPFileSender;
case SMB:
return new SMBFileSender;
default:
//Log error and abort.
}
}
void main()
{
FileSender* fileSender = FileSender::create();
fileSender->send(.....);
}
Você consegue ver que implementando desta forma a factory se tornou realmente útil? Você consegue ver que, agora, para adicionar um novo tipo de FileSender, eu só preciso mexer em entidades que estão dentro da hierarquia de classes FileSender? Você consegue perceber a vantagem disto?
Bom, por hoje era isto.
