Compreender e usar os padrões de design pode cultivar nossos bons hábitos de programação orientados a objetos e, em aplicações reais, podemos aproveitar a diversão de estar à vontade.
O proxy é um modelo relativamente útil e há muitas variantes. Explicado como: Do ponto de partida até a camada intermediária entre os destinos, significando agente.
Definido no padrão de design: fornece um proxy para outros objetos controlarem o acesso a esse objeto.
Por que usar o modo proxy
1. Os usuários do mecanismo de autorização de diferentes níveis de autorização têm diferentes direitos de acesso ao mesmo objeto. (Usuários não registrados) e, em Jive, isso permite controlar os direitos de acesso desses dois usuários para o fórum através de um proxy como o ForumProxy.
2. Um cliente não pode operar diretamente para um objeto, mas deve interagir com esse objeto.
Dê dois exemplos específicos:
1. Se o objeto for uma imagem grande e leva muito tempo para exibi -lo, então quando a imagem é incluída no documento, use o editor ou o navegador para abrir o documento, e o documento deve ser aberto muito rapidamente e não pode esperar .
2. Se esse objeto estiver em um servidor remoto na Internet e operar diretamente esse objeto pode ser lento devido à velocidade da rede, podemos usar o proxy para substituir esse objeto primeiro.
Em suma, o princípio é que, para objetos com alta sobrecarga, eles são criados apenas ao usá -lo. Portanto, algumas pessoas pensam que Java consome memória de recursos, e acho que isso tem algo a ver com a ideia de programação.
Como usar o modo proxy
Tomando o sistema de fórum Jive como exemplo, existem muitos tipos de usuários que visitam o sistema de fórum: usuários comuns registrados, gerentes de fórum, gerentes de sistema e turistas. Somente registrando um usuário comum pode falar.
Fórum é a interface principal do Jive.
Usuários com vários níveis de permissões são definidos em forumpermissões:
A cópia do código é a seguinte:
Public Class ForumperMissions implementa cache {
/**
* Permissão para ler objeto.
*/
public static final int read = 0;
/**
* Permissão para administrador todo o sistema.
*/
public static final int System_admin = 1;
/**
* Permissão ao Administrador Um fórum específico.
*/
public static final int forum_admin = 2;
/**
* Permissão ao Administrador um usuário específico.
*/
public static final int user_admin = 3;
/**
* Permissão ao Administrador um grupo específico.
*/
public static final int group_admin = 4;
/**
* Permissão para modernizar tópicos.
*/
public static final int moderado_threads = 5;
/**
* Permissão para criar um novo thread.
*/
public static final int create_thread = 6;
/**
* Permissão para criar uma nova mensagem.
*/
public static final int create_message = 7;
/**
* Permissão para mensagens modernas.
*/
public static final int moderado_messages = 8;
.....
public boolean IssystemorForumadmin () {
return (valores [forum_admin] || valores [system_admin]);
}
.....
}
Portanto, várias permissões de operação no fórum estão relacionadas ao nível do usuário definido por forumpermissões. Por exemplo, ao modificar o nome do fórum, apenas o gerente do fórum ou o gerente do sistema pode modificá -lo, o código é o seguinte:
A cópia do código é a seguinte:
Public Classe ForumProxy implementa fórum {
permissões de forumpermissões privadas;
fórum privado fórum;
this.authorization = autorização;
FORUMPROXY Public (Fórum do Fórum, Autorização da Autorização,
Permissões de Forumpermissões) {
this.forum = fórum;
this.authorization = autorização;
this.permissions = permissões;
}
.....
public void setName (nome da string) lança UNAuthorizedException,
Forumalreadyexistsexception {
// Somente o sistema ou administrador do fórum pode modificar o nome se (permissões.issystemorforumadmin ()) {
forum.setName (nome);
}
outro {
lançar uma nova UNAuthorizedException ();
}
}
...
}
DBFORUM é a verdadeira implementação do Fórum da Interface.
A cópia do código é a seguinte:
Fórum de implementos public dbforum, em cache {
...
public void setName (nome da string) lança forumalreadyexistsexception {
....
this.name = nome;
// Aqui você realmente salva o novo nome no banco de dados em SaveTodb ();
....
}
...
}
Sempre que o evento de modificação do nome do fórum está envolvido, outros programas devem primeiro lidar com o FORUMPROXY.
Em aplicativos diários, é inevitável que o sistema de autorização ou segurança do sistema esteja sempre envolvido.
Vamos continuar falando mais profundamente em combinação com Jive, e o modelo de fábrica estará envolvido abaixo.
Já sabemos que o uso do fórum requer o uso do FORUMPROXY. Singleton é usado aqui (também um dos padrões de design), getInstance () retorna forumfactoryproxy.
Por que não devolver o ForumFactory, mas retornar forumfactory implementation ForumFactoryProxy? O motivo é óbvio e é necessário determinar se o fórum tem permissão para criá -lo através do proxy.
No FORUMFACFACTORYProxy, vemos o código da seguinte maneira:
A cópia do código é a seguinte:
public class ForumFactoryProxy estende fórumfactory {
fábrica forumfactorial protegida;
Autorização de autorização protegida;
Permissões de Forumpermissões Protegidas;
Public ForumFactoryProxy (autorização de autorização, fábrica de fábrica, permissões de forumpermissões) {
this.Factory = Factory;
this.authorization = autorização;
this.permissions = permissões;
}
Fórum Public CreateForum (Nome da String, String Descrição)
lança UNAuthorizedException, forumalreadyexistsexception {
// Somente administradores de sistema podem criar fórum
if (permissions.get (forumpermissions.system_admin)) {
Fórum newforum = factory.createForum (nome, descrição);
devolver novos forumproxy (newforum, autorização, permissões);
}
outro {
lançar uma nova UNAuthorizedException ();
}
}
}
O método createforum retorna o fórumproxy.
Observe que existem dois proxy aqui: ForumProxy e ForumFactoryProxy. Representa duas responsabilidades diferentes: usando o fórum e criando fórum. Quanto ao motivo pelo qual o uso de objetos é separado da criação de objetos, é por isso que o padrão de fábrica é usado: é para "encapsulamento" e "despacho". Em outras palavras, as funções são o mais simples possível para facilitar a manutenção e a modificação.
Outra criação pós -criação e uso no sistema de fórum Jive são baseados na ideia do fórum.
Acima, discutimos como usar o proxy para acesso ao mecanismo de autorização. Copiar um objeto enorme e complexo é uma operação muito cara. Use um proxy para adiar este processo de cópia.
Por exemplo: temos uma grande coleção, como hashtable, e muitos clientes o acessam simultaneamente ao mesmo tempo. Um dos clientes especiais precisa executar a aquisição contínua de dados e, neste momento, outros clientes são necessários para não adicionar ou excluir coisas à hashtable.
A solução mais direta é: use o bloqueio da coleção, deixe este cliente especial obter esse bloqueio, executar aquisição contínua de dados e solte o bloqueio.
A cópia do código é a seguinte:
FOFETHES PUBLIC VOID (HATHTABLE HT) {
sincronizado (ht) {
// Ação específica de aquisição de dados contínuos ...
}
}
No entanto, esse método pode bloquear a coleção por um longo tempo e outros clientes não poderão acessar a coleção durante esse período.
A segunda solução é fechar a coleção e, em seguida, deixar os dados contínuos obterem a operação de coleta para o clone. Esta solução tem como premissa o fato de que a coleção é clonável e deve haver um método para fornecer um clone profundo. A hashtable fornece seu próprio método clone, mas não o clone dos objetos de chave e valor.
A cópia do código é a seguinte:
FOFETHES PUBLIC VOID (HATHTABLE HT) {
Hashttable newht = (hashtable) ht.clone ();
}
O problema vem novamente.
A solução final: podemos esperar até que outros clientes tenham concluído a modificação antes de clonar, ou seja, esse cliente especial executa primeiro uma série de operações de aquisição de dados chamando um método chamado clone. Mas, de fato, nenhuma cópia de objetos foi feita até que outros clientes modificem a coleta de objetos.
Implementar esta solução usando proxy, que é a operação de cópia sobre gravação.
O proxy possui uma ampla gama de aplicações.