Лучше передать *интерфейс* или *объект* в качестве параметра к функции?
Использование библиотеки q обещаний означает, что ваша функция успеха может оставаться в вашем распоряжении:
app.factory('Data', function ($http, $q) {
return {
ajaxItems: function () {
var deferred = $q.defer();
$http({ method: "POST", url: "/Home/GetSearchResults" })
.success(function (data, status, headers, config) {
deferred.resolve(data);
}).error(function (data, status, headers, config) {
deferred.reject(status);
});
return deferred.promise;
}
}
});
app.controller('ResultsCtrl', ['$scope', 'Data', function ($scope, Data) {
$scope.get = function () {
$scope.items = Data.ajaxItems();
//the model returns a promise and THEN items
$scope.items.then(function (items) {
$scope.items = items;
}, function (status) {
console.log(status);
});
};
}]);
5 ответов
One of the first principles you learn in OO development:
Program to an interface, not an реализация.
Вы указываете, что «всегда будет только один из этих больших классов - i / f никогда не будет использоваться для другого объекта». Это может быть правдой в вашем случае, но мне жаль, что у меня не было ни цента за каждый раз, когда такое утверждение оказывалось неверным.
Помимо рассмотрения того, может ли существовать несколько реализаций вашего интерфейса, вам также следует подумать, есть ли у вас конкретный объект экспортирует (или может экспортировать) дополнительные методы, которые не имеют логического сходства с операциями, объявленными в интерфейсе. В таком случае вы можете просто объявить дополнительные операции в одном или нескольких дополнительных интерфейсах. Таким образом, клиенту нужно только соединиться с интерфейсом, который экспортирует операции, в которых он заинтересован.
Проще говоря,
Я бы предпочел избегать создания и интерфейса ради создания интерфейса. Если вы можете использовать этот интерфейс более чем в одном месте, то у вас есть победитель - или если это общедоступная функция и класс, и вы специально хотите упростить.
Принцип инверсии зависимостей можно резюмировать следующим образом: лучше зависеть от абстракций, чем от конкреций.
Почти всегда лучше передать интерфейс, чем он есть для передачи конкретного класса.
Тем не менее, высокая связность с внутренними типами - это нормально для конкретного модуля, но это очень субъективно в отношении того, когда и как вы должны передавать конкретные объекты.
Если вы Передавая реализацию, вы теряете одно из преимуществ использования интерфейсов, то есть отделение логики от фактической реализации.
Интерфейс программного модуля A намеренно хранится отдельно от реализация этого модуля. В последний содержит фактический код процедуры и методы, описанные в интерфейс, а также другие «частные» переменные, процедуры и т. д. Любой другой программный модуль B (который может называться клиентом A), который взаимодействует с A вынужден сделать это только через интерфейс. Один практическая польза от этого договоренность заключается в том, что замена реализация А другим который соответствует тем же спецификациям интерфейс не должен заставлять B неуспешно - до тех пор, пока его использование A соответствует со спецификациями интерфейс (см. также Лисков принцип подстановки).
Другая проблема - это сам ваш очень большой класс. Возможно, это выходит за рамки того, что вы делаете, но очень большой класс подразумевает, что он может делать слишком много с самого начала. Можете ли вы реорганизовать его в более мелкие классы, где информация, необходимая для вызываемой функции, инкапсулирована в ее собственный меньший класс? Если вы создадите интерфейс для этого класса, вы можете найти его гораздо более пригодным для повторного использования, чем для очень большого класса, который у вас есть в настоящее время.