Это очень старый вопрос, и этот ответ, вероятно, должен быть комментарием, а не ответом, но я думаю, что эту тему стоит продолжать обсуждать, и этот ответ слишком длинный, чтобы быть комментарием.
Первоначальное мышление о «беглости», по-видимому, в основном заключалось в добавлении мощности и гибкости (связывание методов и т. Д.) К объектам, в то же время делая код немного более понятным.
Например
Company a = new Company("Calamaz Holding Corp");
Person p = new Person("Clapper", 113, 24, "Frank");
Company c = new Company(a, 'Floridex', p, 1973);
менее "свободно", чем
Company c = new Company().Set
.Name("Floridex");
.Manager(
new Person().Set.FirstName("Frank").LastName("Clapper").Awards(24)
)
.YearFounded(1973)
.ParentCompany(
new Company().Set.Name("Calamaz Holding Corp")
)
;
Но, на мой взгляд, последнее на самом деле не более могущественно, гибко или самоочевидно, чем
Company c = new Company(){
Name = "Floridex",
Manager = new Person(){ FirstName="Frank", LastName="Clapper", Awards=24 },
YearFounded = 1973,
ParentCompany = new Company(){ Name="Calamaz Holding Corp." }
};
.. на самом деле я бы назвал эту последнюю версию более легкой для создания, чтения и обслуживания, чем предыдущую, и я бы сказал, что она требует значительно меньшего количества багажа и за кулисами. Что для меня важно, по крайней мере, по двум причинам:
1 - Стоимость, связанная с созданием и поддержанием слоев объектов (независимо от того, кто это делает), так же реальна, актуальна и важна, как и стоимость, связанная с созданием и обслуживанием кода, который их потребляет.
2 - Раздувание кода, внедренное в слои объектов, создает столько же (если не больше) проблем, что и раздувание кода в коде, который потребляет эти объекты.
Использование последней версии означает, что вы можете добавить (потенциально полезное) свойство в класс Company, просто добавив одну очень простую строку кода.
Это не значит, что я чувствую, что нет места для цепочки методов. Мне очень нравится, что я могу делать что-то вроде (в JavaScript)
var _this = this;
Ajax.Call({
url: '/service/getproduct',
parameters: {productId: productId},
)
.Done(
function(product){
_this.showProduct(product);
}
)
.Fail(
function(error){
_this.presentError(error);
}
);
.. где (в гипотетическом случае, который я представляю) Done и Fail были дополнениями к исходному объекту Ajax, и их можно было добавлять без изменения какого-либо исходного кода объекта Ajax или любого существующего кода, который сделал использование исходного объекта Ajax и без создания разовых вещей, которые были исключениями из общей организации кода.
Так что я определенно нашел значение в том, чтобы подмножество функций объекта возвращало объект this. Фактически, всякий раз, когда у меня есть функция, которая в противном случае возвращает void, я считаю, что она должна возвращать это.
Но я еще не нашел существенного значения в добавлении «плавных интерфейсов» (.eg «Set») к объекту, хотя теоретически кажется, что может существовать своего рода организация кода, подобная пространству имен, которая может возникнуть практики делать это, что может быть полезным. («Набор» может быть не особенно ценным, но «Команда», «Запрос» и «Перенос» могут быть полезны, если бы он помог организовать вещи, облегчить и минимизировать влияние дополнений и изменений.) Одно из потенциальных преимуществ такой практики в зависимости от того, как это было сделано, может быть улучшение типичного уровня заботы кодера и внимания к уровням защиты, недостаток которых, безусловно, вызвал большие объемы горя.