Prefácio
Neste capítulo, explicaremos o quarto capítulo da implementação dos cinco principais princípios do JavaScript sólido, o princípio da segregação da interface.
Texto em inglês original: http://freshbrewedcode.com/derekgreeer/2012/01/08/solid-javascript-therface-segregation-principle/
Nota: O autor deste artigo é bastante tocante, então o tio também está deprimido para entendê -lo. Basta ler como quiser, não fique preso nele.
A descrição do princípio do isolamento da interface é:
A cópia do código é a seguinte:
Os clientes não devem ser forçados a depender dos métodos que não usam.
Os clientes não devem ser forçados a confiar nos métodos que não usam.
Quando o método da interface do qual o usuário depende é usado apenas por outros usuários e não o usa, ele deve implementar essas interfaces. Em outras palavras, se um usuário confiar em uma interface que não é usada, mas usada por outros usuários, quando outros usuários modificam a interface, todos os usuários que confiam na interface serão afetados. Obviamente, isso viola o princípio de abrir e fechar, e não é o que esperamos.
O Princípio do Isolamento da Interface ISP é um pouco semelhante à responsabilidade única. Ambos são usados para agregar responsabilidades funcionais. De fato, o ISP pode ser entendido como converter programas com responsabilidades únicas em um objeto com uma interface pública.
Interface JavaScript
Como cumprimos esse princípio sob JavaScript? Afinal, o JavaScript não possui o recurso das interfaces. Se a interface é o que queremos estabelecer contrato e dissociar através de tipos abstratos fornecidos por um determinado idioma, pode -se dizer que está tudo bem, mas o JavaScript tem outra forma de interface. Nos padrões de design do livro, elementos de software reutilizável orientado a objetos, encontramos a definição da interface:
http://www.amazon.com/design-patterns-elements-reusable-object-oriented/dp/0201633612
Qualquer operação declarada por um objeto contém um nome de operação, objeto de parâmetro e valor de retorno da operação. Chamamos isso de assinatura do operador.
Todas as operações declaradas em um objeto são chamadas de interface desse objeto. A interface de um objeto descreve todas as informações de solicitação que ocorrem nesse objeto.
Independentemente de um idioma fornecer um construto separado para representar uma interface, todos os objetos têm uma interface implícita composta por todas as propriedades e métodos do objeto. Consulte o seguinte código:
A cópia do código é a seguinte:
var exemplobinder = {};
Explebinder.modelobserver = (function () {
/* Variável privada*/
retornar {
Observe: function (modelo) {
/* Código*/
retornar newmodel;
},
OnChange: function (retorno de chamada) {
/* Código*/
}
}
}) ();
Explebinder.ViewAdaptor = (function () {
/* Variável privada*/
retornar {
Bind: function (Model) {
/* Código*/
}
}
}) ();
exemplobinder.bind = function (modelo) {
/* Variável privada*/
ExemploBinder.modelobserver.onchange (/ * retorno de chamada de retorno */);
var om = exemplobinder.modelobserver.observe (modelo);
exemplobinder.ViewAdaptor.bind (OM);
retornar om;
};
A biblioteca de classes do Exemplobinder acima implementa a ligação de mão dupla. A interface pública exposta por esta biblioteca de classes é o método de ligação, onde as funções de notificação de alteração e interação de visualização usadas no Bind são implementadas por objetos separados Modelobserver e ViewAptor, respectivamente. Esses objetos são, em certo sentido, a implementação específica do método de ligação de interface pública.
Embora o JavaScript não forneça tipos de interface para suportar contratos de objetos, a interface implícita do objeto ainda pode ser fornecida aos usuários do programa como um contrato.
ISP e JavaScript
Algumas das subseções que discutimos abaixo estão o impacto de violar o princípio de isolamento da interface no JavaScript. Como visto acima, embora seja uma pena implementar o princípio do isolamento da interface nos programas JavaScript, ele não é tão poderoso quanto os idiomas estaticamente digitados. As características do idioma do JavaScript às vezes tornam a chamada interface um pouco antiaderente.
A realização da depravação
Em idiomas estaticamente digitados, uma das razões para violar os princípios do ISP é a implementação degenerada. Os métodos definidos em todas as interfaces em Java e C# devem ser implementados. Se você precisar apenas de alguns deles, os outros métodos também devem ser implementados (podem ser implementados por exceções vazias ou lançando). No JavaScript, se apenas algumas interfaces em um objeto forem necessárias, ele não poderá resolver o problema da implementação degenerada, embora não haja necessidade de forçar a implementação da interface acima. No entanto, essa implementação ainda viola o princípio da substituição de Richter.
A cópia do código é a seguinte:
var retângulo = {
área: function () {
/* Código*/
},
desenho: function () {
/* Código*/
}
};
var geometryApplication = {
getLargestRectangle: function (retângulos) {
/* Código*/
}
};
var drawingApplication = {
drawrectangles: function (retângulos) {
/* Código*/
}
};
Quando uma alternativa de retângulo para satisfazer o getLargestRectangle do novo aplicativo de geometria do objeto, ele precisa apenas do método Retângulo (), mas viola o LSP (porque não pode usar o método de desenho que só pode ser usado no método Drawrectangles).
Acoplamento estático
Outro motivo para violações do ISP em idiomas estaticamente tipados é o acoplamento estático. Em idiomas estaticamente digitados, as interfaces desempenham um papel importante em um programa de design frouxamente acoplado. Seja em uma linguagem dinâmica ou estática, às vezes um objeto pode precisar se comunicar entre vários usuários de clientes (como o estado compartilhado). Para linguagens estaticamente digitadas, a melhor solução é usar as interfaces de função, que permitem ao usuário interagir com o objeto (que pode precisar estar em várias funções) como sua implementação para dissociar o usuário e o comportamento não relacionado. Não existe esse problema no JavaScript, porque os objetos são dissociados pelas vantagens únicas dos idiomas dinâmicos.
Acoplamento semântico
Um motivo comum para violar o ISP é os idiomas dinâmicos e estaticamente digitados, que é o acoplamento semântico. O chamado acoplamento semântico é a interdependência, ou seja, o comportamento de um objeto depende de outro objeto, o que significa que, se um usuário alterar um dos comportamentos, é provável que afete outro usuário. Isso também viola o princípio da responsabilidade única. Esse problema pode ser resolvido por meio de herança e substituição de objetos.
Escalabilidade
Outro motivo para o problema é sobre escalabilidade. Muitas pessoas darão exemplos sobre retorno de chamada para demonstrar escalabilidade (como as configurações de retorno de chamada após o sucesso no AJAX). Se essa interface precisar de uma implementação e houver muitos métodos familiares ou no objeto desta implementação, o ISP se tornará muito importante. Ou seja, quando uma interface interface se torna uma necessidade de implementar muitos métodos, sua implementação se tornará extremamente complexa e pode fazer com que essas interfaces assumam uma responsabilidade que não é de nós. Esta é a interface gorda que costumamos mencionar.
Resumir
As características da linguagem dinâmica no JavaScript tornam nossa implementação de interfaces antiaderentes menos influentes do que os idiomas estaticamente digitados, mas o princípio do isolamento da interface ainda tem sua função no modelo de programação JavaScript.