Benjamin poprosił mnie o wyjaśnienie mojej pozycji, więc zredagowałem mój poprzedni post i dodałem dalsze przemyślenia.
Bob Martin jest autorem świetnej książki zatytułowanej Clean Code. W tej książce znajduje się rozdział (Rozdział 6) o nazwie Obiekty i struktury danych, w którym omawia najważniejsze różnice między obiektami a strukturami danych i twierdzi, że musimy wybierać między nimi, ponieważ mieszanie ich jest bardzo złym pomysłem.
To zamieszanie czasami prowadzi do niefortunnych struktur hybrydowych, które są w połowie strukturą obiektową i w połowie strukturą danych. Mają funkcje, które robią znaczące rzeczy, a także mają zmienne publiczne lub publiczne akcesory i mutatory, które pod każdym względem upubliczniają zmienne prywatne, kusząc inne funkcje zewnętrzne do używania tych zmiennych w sposób, w jaki program proceduralny użyłby struktura danych.4 Takie hybrydy utrudniają dodawanie nowych funkcji, ale także utrudniają dodawanie nowych struktur danych. Są najgorsze z obu światów. Unikaj ich tworzenia. Wskazują na zagmatwany projekt, którego autorzy nie są pewni - lub gorzej, nie znają - czy potrzebują ochrony przed funkcjami lub typami.
Myślę, że DOM jest przykładem takich hybryd obiektów i struktury danych. Na przykład przez DOM piszemy takie kody:
el.appendChild(node);
el.childNodes;
// bleeding internals
el.setAttribute(attr, val);
el.attributes;
// bleeding internals
el.style.color;
// at least this is okay
el = document.createElement(tag);
doc = document.implementation.createHTMLDocument();
// document is both a factory and a tree root
DOM powinien być wyraźnie strukturą danych zamiast hybrydy.
el.childNodes.add(node);
// or el.childNodes[el.childNodes.length] = node;
el.childNodes;
el.attributes.put(attr, val);
// or el.attributes[attr] = val;
el.attributes;
el.style.get("color");
// or el.style.color;
factory = new HtmlNodeFactory();
el = factory.createElement(document, tag);
doc = factory.createDocument();
Struktura jQuery jest zbiorem procedur, które mogą wybierać i modyfikować kolekcję węzłów DOM oraz wykonywać wiele innych czynności. Jak zauważył Laurent w swoim poście, jQuery ma coś takiego:
html(select("#body"), "<p>hello</p>");
Twórcy jQuery połączyli wszystkie te procedury w jedną klasę, która odpowiada za wszystkie wymienione powyżej funkcje. Tak więc wyraźnie narusza zasadę pojedynczej odpowiedzialności i dlatego jest przedmiotem boskim. Jedyna rzecz, ponieważ niczego nie psuje, ponieważ jest to pojedyncza samodzielna klasa, która działa na pojedynczej strukturze danych (zbiór węzłów DOM). Gdybyśmy dodali podklasy jQuery lub inną strukturę danych, projekt zawaliłby się bardzo szybko. Nie sądzę więc, abyśmy mogli mówić o oo przez jQuery, jest to raczej procedura niż oo, mimo że definiuje klasę.
To, co twierdzi Laurent, jest kompletnym nonsensem:
Więc co to wszystko znaczy? To jQuery (jak LINQ) nie jest anty-wzorcem obiektu Boga. Zamiast tego jest to przypadek bardzo szanowanego wzoru zwanego Dekoratorem.
Wzorzec Dekoratora polega na dodawaniu nowej funkcjonalności przez utrzymanie interfejsu i nie modyfikowanie istniejących klas. Na przykład:
Możesz zdefiniować 2 klasy, które implementują ten sam interfejs, ale z zupełnie inną implementacją:
/**
* @interface
*/
var Something = function (){};
/**
* @argument {string} arg1 The first argument.
* @argument {string} arg2 The second argument.
*/
Something.prototype.doSomething = function (arg1, arg2){};
/**
* @class
* @implements {Something}
*/
var A = function (){
// ...
};
/**
* @argument {string} arg1 The first argument.
* @argument {string} arg2 The second argument.
*/
A.prototype.doSomething = function (arg1, arg2){
// doSomething implementation of A
};
/**
* @class
* @implements {Something}
*/
var B = function (){
// ...
};
/**
* @argument {string} arg1 The first argument.
* @argument {string} arg2 The second argument.
*/
B.prototype.doSomething = function (arg1, arg2){
// doSomething implementation of B
// it is completely different from the implementation of A
// that's why it cannot be a sub-class of A
};
Jeśli masz metody wykorzystujące tylko wspólny interfejs, możesz zdefiniować jeden lub więcej dekoratorów zamiast kopiować i wklejać ten sam kod między A i B. Możesz używać tych dekoratorów nawet w zagnieżdżonej strukturze.
/**
* @class
* @implements {Something}
* @argument {Something} something The decorated object.
*/
var SomethingDecorator = function (something){
this.something = something;
// ...
};
/**
* @argument {string} arg1 The first argument.
* @argument {string} arg2 The second argument.
*/
SomethingDecorator.prototype.doSomething = function (arg1, arg2){
return this.something.doSomething(arg1, arg2);
};
/**
* A new method which can be common by A and B.
*
* @argument {function} done The callback.
* @argument {string} arg1 The first argument.
* @argument {string} arg2 The second argument.
*/
SomethingDecorator.prototype.doSomethingDelayed = function (done, arg1, arg2){
var err, res;
setTimeout(function (){
try {
res = this.doSomething(o.arg1, o.arg2);
} catch (e) {
err = e;
}
callback(err, res);
}, 1000);
};
Możesz więc zastąpić oryginalne wystąpienia wystąpieniami dekoratora w kodzie o wyższym poziomie abstrakcji.
function decorateWithManyFeatures(something){
var d1 = new SomethingDecorator(something);
var d2 = new AnotherSomethingDecorator(d1);
// ...
return dn;
}
var a = new A();
var b = new B();
var decoratedA = decorateWithManyFeatures(a);
var decoratedB = decorateWithManyFeatures(b);
decoratedA.doSomethingDelayed(...);
decoratedB.doSomethingDelayed(...);
Wniosek, że jQuery nie jest dekoratorem czegokolwiek, ponieważ nie implementuje tego samego interfejsu co Array, NodeList ani żaden inny obiekt DOM. Implementuje własny interfejs. Moduły nie są również używane jako Dekoratory, po prostu zastępują oryginalny prototyp. Dlatego wzorzec Dekoratora nie jest używany w całej bibliotece jQuery. Klasa jQuery to po prostu ogromny adapter, który pozwala nam używać tego samego API przez wiele różnych przeglądarek. Z punktu widzenia oo jest to kompletny bałagan, ale to tak naprawdę nie ma znaczenia, działa dobrze i korzystamy z niego.
$funkcji anijQueryobiektu.