Да. Концептуально перечислимый определяет тип и возможные значения того типа. Даже при том, что это кажется естественным, определить enum foo { bar, baz };
и затем относиться к foo::baz
совпадают с обращением к int::1
.
Я собрал простой легкий контейнер ioc, назвав его JsfIoc.
Я начал писать ту, которую так и не успел закончить. Не уверен, что когда-нибудь буду, поскольку накладные расходы, вероятно, того не стоят. если вам интересно, это по адресу: http://code.google.com/p/jasproject/wiki/JasFac (это часть IoC, полный набор находится по адресу http: // code.google.com/p/jasproject/)
Библиотека имитаторов довольно полная (хотя никаких ожиданий, на данный момент я просто использую утверждения для макетов / заглушек), но фреймворк для модульного тестирования отсутствует. Часть IoC довольно полная, но может содержать несколько ошибок (хотя не думаю)
Не стесняйтесь использовать ее и / или вносить свой вклад, я могу помочь там, где вам нужно.
РЕДАКТИРОВАТЬ: Можно увидеть больше использования в модульных тестах для jasfac: https://jasproject.googlecode.com/svn/trunk/Jas.Tests/JasFacTests.js
Я искал один в прошлом году и наткнулся на squirrel-ioc . Что-то мне в этом не понравилось - я думаю, он поддерживал только экземпляры в стиле singleton.
Squirrel - это контейнер IoC. реализован в Javascript для продвижения лучшее использование архитектуры и шаблоны в браузере Javascript applications
I started writing my own and got pretty far (constructor and setter injection, values and reference relationships, singleton support, JsUnit tests) but never really needed it in my application. I may have to check out Luke's project. For reference, here is an example of the configuration format I ended up with.
var iocConfig = {
"a" : { Type : A },
"b1" : { Type : B, Props : [{Name : 'Letter', Ref : "a"}] },
"b2" : { Type : B, Props : [{Name : 'Letter', Val : "a"}] },
"c2" : { Type : C, Args : [{Ref : "a"}, {Val : "a"}] },
"d" : { Type : D, Props : [{Name : 'Letter', Ref : "a"}] },
"date" : { Type : Date, Props : [{Name : 'FullYear', Val : 2008}, {Name : 'Month', Val : 0}, {Name : 'Date', Val : 1}] },
"array3" : { Type : Array, Args : [{Val : 3}] },
"number1" : { Type : Number, Args : [{Val : 1}] },
"string1" : { Type : String, Args : [{Val : "1"}] },
"s-true" : { Type : S, Singleton : true},
"s-false" : { Type : S, Singleton : false}
};
В языках с динамической типизацией, таких как JavaScript и Ruby, DI на самом деле не так полезен.
Основное преимущество DI в статически типизированных языках, таких как Java, заключается в тестировании - для замены реальной реализации какого-то класса с макетом. Это потому, что классы в Java являются неизменяемыми, и вы не можете так легко заменить их имитаторами - для этого вам нужна целая система DI.
Но в JavaScript вы можете легко заменить существующие классы / методы фиктивными. Так что DI на самом деле не нужен для достижения тестируемости.
Конечно, есть и другие сценарии, в которых DI может быть полезен, но вы на самом деле не указали, для чего вы хотите использовать DI, поэтому я рассмотрел наиболее очевидный случай.