Dependência de inversão de princípio em JavaScript

Question

É alguém capaz de ajudar a ilustrar Dependência de inversão de princípio em JavaScript, jQuery.

O que gostaria de destacar e explicar esses 2 pontos:

A.De alto nível módulos não devem depender de baixo nível módulos.Ambos devem depender de abstrações.

B.Abstrações não devem depender de detalhes.Detalhes devem depender de abstrações.

O que são abstrações ou alto/baixo nível de módulos?

Isso realmente vai ajudar no meu entendimento, obrigado!

Answer 1

Eu diria que o DIP aplica em JavaScript da mesma maneira como se aplica na maioria das linguagens de programação, mas você tem que estar ciente do papel da tipagem pato. Vamos fazer um exemplo para ver o que quero dizer ...

Vamos dizer que eu quero entrar em contato com o servidor para alguns dados. Sem aplicar DIP, isso pode parecer:

$.get("/address/to/data", function (data) {
    $("#thingy1").text(data.property1);
    $("#thingy2").text(data.property2);
});

Com DIP, eu poderia código em vez de escrita como

fillFromServer("/address/to/data", thingyView);

onde o fillFromServer abstração pode para o caso particular onde queremos usar Ajax do jQuery ser implementado como

function fillFromServer(url, view) {
    $.get(url, function (data) {
        view.setValues(data);
    });
}

eo view abstração pode ser implementado para o caso particular de uma visão baseada em elementos com IDs thingy1 e thingy2 como

var thingyView = {
    setValues: function (data) {
        $("#thingy1").text(data.property1);
        $("#thingy2").text(data.property2);
    }
};

Princípio A:

• fillFromServer pertence em um módulo de baixo nível, a manipulação como acontece a interação de baixo nível entre o servidor e a vista. Algo como, digamos, um objeto settingsUpdater seria parte de um módulo de nível superior, e que iria contar com a abstração fillFromServer --- não sobre os detalhes do mesmo, que são, neste caso, implementada via jQuery.
• Da mesma forma, fillFromServer não depende de especificidades dos elementos DOM e suas identificações para realizar o seu trabalho; em vez disso, depende da abstracção de um view, que para os fins é qualquer tipo que tem um método setValues. (Isto é o que se entende por "tipagem pato.")

Princípio B:

Este é um pouco menos fácil ver em JavaScript, com o seu pato digitação; em particular, algo como view não deriva de (ou seja, dependem) algum tipo de tipo viewInterface. Mas podemos dizer que o nosso caso particular, o thingyView, é uma detalhe que "depende" do view abstração.

Na realidade, é "de acordo" com o fato de que os chamadores entender que tipo de métodos deve ser chamado, ou seja, que os chamadores são consciente da abstração apropriado. Nas línguas habituais orientadas a objetos, é mais fácil ver a dependência de thingyView explicitamente na própria abstração. Em tais línguas, a abstração seria incorporada em uma interface (por exemplo, IView em C # ou Viewable em Java), e a dependência explícita é através de herança (class ThingyView : IView ou class ThingyView implements Viewable). O mesmo sentimento se aplica, no entanto.

---

Por que isso é legal? Bem, digamos que um dia eu precisava colocar os dados do servidor em caixas de texto com IDs text1 e text2 vez de <span />s com IDs thingy1 e thingy2. Além disso, digamos que este código estava sendo chamado muito, muito frequentemente, e avaliação comparativa revelou que o desempenho crítico estava sendo perdido através do uso de jQuery. Eu poderia, então, basta criar uma nova "implementação" da abstração view, assim:

var textViewNoJQuery = {
   setValues: function (data) {
        document.getElementById("text1").value = data.property1;
        document.getElementById("text2").value = data.property2;
   }
};

Então eu injectar este caso particular da abstração vista em minha fillFromServer abstração:

fillFromServer("/address/to/data", textViewNoJQuery);

Isso exigiu não alterações no código fillFromServer, porque dependiam apenas na abstração de um view com um método setValues, e não sobre os detalhes do DOM e como podemos acessá-lo. Não só isso é gratificante em que podemos reutilizar o código, ele também indica que temos claramente separados nossas preocupações e criou um código muito à prova de futuro.

Answer 2

EDITAR:

Isso mostra o uso de MERGULHO em matérias-primas para JavaScript e um concluída em menos jQuery exemplo.No entanto, a seguinte descrição pode ser facilmente aplicada para o jQuery.Ver jQuery exemplo na parte inferior.

A melhor maneira é aproveitar o Adaptador "Padrão" -- também chamado de um "wrapper".

Um Adaptador é basicamente um modo de acondicionamento de um objeto ou módulo de tal forma que ele fornece a mesma interface consistente para a sua dependentes.Dessa forma, os dependentes de classe (normalmente um nível superior classe) pode facilmente trocar módulos do mesmo tipo.

Um exemplo disso seria um nível alto (ou supra) módulo de quem depende Geo/módulos de Mapeamento.

Vamos analisar isso.Se nossos supra módulo já está utilizando o GoogleMaps, mas, em seguida, gestão determina a sua mais barato para ir com LeafletMaps -- não queremos ter de reescrever a cada chamada de método gMap.showMap(user, latLong) para leaflet.render(apiSecret,latLong, user), et al.Isso seria um pesadelo para ter à porta de nossa aplicação a partir de um quadro para outro desta forma.

O que queremos:Seria como um "wrapper" que fornece a mesma consistente interface para o supra módulo-e fazer isso para cada menor nível de módulo (ou infra módulo).

Aqui é um variar exemplo simples:

var infra1 = (function(){
    function alertMessage(message){
        alert(message);
    }

    return {
        notify: alertMessage
    };
})();

var infra2 = (function(){
    function logMessage(message){
        console.log(message);
    }

    return {
        notify: logMessage
    };
})();


var Supra = function(writer){
    var notifier = writer;
    function writeMessage(msg){
        notifier.notify(msg);
    }

    this.writeNotification = writeMessage;
};


var supra;

supra = new Supra(infra1);
supra.writeNotification('This is a message');

supra = new Supra(infra2);
supra.writeNotification('This is a message');

Observe que não importa que tipo de nível inferior do módulo de "escrever" nós usamos (neste caso infra1 e infra2), não temos que reescrever qualquer da implementação do nosso alto nível de módulo, Supra.Isso é porque DIP leva vantagem de dois tipos diferentes de Software Princípios de Design:"Coi" (Inversão de Controle) e "DI" (Injeção de Dependência).

A melhor analogia que eu encontrei é a imagem mostrada abaixo.

Cada fonte de energia depende de um interface específicos para os tipos de coisas que precisa para ligar para ele.

jQuery Descrição:

Este padrão pode ser facilmente aplicada para o uso de frameworks como o jQuery.Um exemplo seria o simples DOM-identificador de Consulta.Podemos usar DIP para permitir o baixo acoplamento, de modo que se alguma vez decidir mudar de quadros ou dependem nativo DOM-métodos de Consulta, a manutenção é fácil:

var jQ = (function($){

    return {
        getElement: $
    };
})(jQuery);

var nativeModule = (function(){

    return {
        getElement: document.querySelector
    };
})();


var SupraDOMQuery = function(api){
    var helper = api, thus = this;

    function queryDOM(selector){
        el = helper.getElement(selector);
        return thus;
    }

    this.get = queryDOM;
};


var DOM;

DOM = new SupraDOMQuery(jQ);
DOM.get('#id.class');

DOM = new SupraDOMQuery(nativeModule);
DOM.get('#id.class');

Obviamente, esse exemplo seria a necessidade de magnitudes de mais funcionalidade, a fim de ser prático, mas eu espero que ele chegue do outro lado.

Basicamente, as diferenças entre uma Placa e uma Fachada de tornar-se algo trivial.Na Fachada, você está olhando, provavelmente, um único módulo que envolve uma API ou outro módulo;considerando que um Adaptador cria um consistente Fachada API para cada um de seus módulos, e explora essa técnica para obviar apertado de acoplamento.

Mais do JavaScript Padrões de Design livros de ir sobre o Adaptador Padrão;aquele que, especificamente, vai mais um 'jQuery Placa' é Aprender JavaScript Padrões De Projeto por Addy Osmani publicado por O'Reilly -- aqui.No entanto, eu também aconselho olhando para Pro JavaScript Padrões De Projeto por Dustin Diaz e Ross Harmes publicado por Apress -- confira.No entanto, eu acho que é importante entender o contexto em que pretendemos implementar DIP em relação ao jQuery.

Espero que isso ajude a esclarecer as coisas :)

Answer 3

Encontrado algumas ilustrações úteis aqui .

Answer 4

princípio de inversão de dependência em JavaScript jQuery

Não existe alguma conexão entre DI e jQuery. DI é tudo sobre a estrutura e a montagem de aplicação de compoents. jQuery é um wrapper acessível ao redor DOM, nada mais, não tem qualquer estrutura ou componentes.

Você pode usar DI para montagem de seu aplicativo JavaScript, mas seria parece muito o mesmo, não importa que você usa jQuery ou não.