$scope.del = function () {
var delItemId = getDelId(); // 要删除的项目的身份标识
// 如果没选择删除项
if (!delItemId.length) {
$promptLayer.show({
str: $message.delItemIsEmpty
});
return;
}
delTarArr = delItemId;
$weuiAndroidDialog2.show($message.store.delConfirm, $message.store.delCloseBtn, $message.store.delOkBtn);
};
// 确认删除
$rootScope.$on('androidDialog2Btn1', function () {
del( delTarArr.join(',') );
$weuiAndroidDialog2.hide();
});
// 取消删除
$rootScope.$on('androidDialog2Btn0', function () {
$weuiAndroidDialog2.hide();
});
var delTarArr;
// 获取要删除项标识
function getDelId() {
var delTarArr = [];
$angular.forEach($scope.selectAllItem, function (v, i) {
if (v) {
delTarArr.push($scope.storeList[i].Sid);
}
});
return delTarArr;
}
// 删除
function del(param) {
// 请求删除接口
$handler.store.del( param ).then(function () {
delAllJumpPage(delTarArr.length, $scope.selectAllItem.length); // 删空跳页
});
}
// 删空跳页
function delAllJumpPage(delNum, totalNum) {
var curPage = $scope.pageControlCurNum; // 当前所在页数
// 此页删空 跳上一页
if (delNum === totalNum)
curPage = curPage - 1;
$scope.loadList(curPage);
$scope.pageControlCurNum = curPage;
}
oder
var delTarArr;
$scope.del = function () {
// 看是否有选中项
$angular.forEach($scope.selectAllItem, function (v, i) {
if (v) {
delTarArr.push($scope.storeList[i].Sid); // 获取选中项 Sid
}
});
// 如果没有删除项
if (!delTarArr.length) {
$promptLayer.show({
str: $message.delItemIsEmpty
});
return;
}
// 再次确认提示层
$weuiAndroidDialog2.show($message.store.delConfirm, $message.store.delCloseBtn, $message.store.delOkBtn);
};
// 确认删除
$rootScope.$on('androidDialog2Btn1', function () {
// 请求删除接口
$handler.store.del( delTarArr.join(',') ).then(function () {
// 删空跳页
var curPage = $scope.pageControlCurNum; // 当前所在页数
// 此页删空 跳上一页
if (delTarArr.length === $scope.selectAllItem.length)
curPage = curPage - 1;
$scope.loadList(curPage);
$scope.pageControlCurNum = curPage;
});
$weuiAndroidDialog2.hide();
});
// 取消删除
$rootScope.$on('androidDialog2Btn0', function () {
$weuiAndroidDialog2.hide();
});
Welcher dieser beiden Codeteile ist besser? Obwohl beide ziemlicher Dreck sind, wollen wir mal sehen, wie Sie damit umgehen
Eine Funktion kann nur eines tun. Warum ist sie so lesbar? Skalierbarkeit? Wiederverwendbarkeit? Meiner Meinung nach ist das Deklarieren einer Funktion nicht kostenlos. Eine Funktion nimmt nur etwas Platz im Speicher ein. Der Aufruf der Funktion ist ohne direkte Analyse
Wenn es sich um eine Wiederverwendung und Erweiterung handelt, ist es dann wirklich nicht möglich, dies beim ersten Schreiben im Voraus zu tun? Woher wissen Sie, dass die vorgeschlagene Funktion in Zukunft universell sein wird? Es anzusehen ist definitiv nicht die beste Performance-Praxis~Ist die Früh-/Übergangsoptimierung nicht die Wurzel allen Übels? ~
就一个类而言，应该仅有一个引起它变化的原因。在 JavaScript 中，需要用到类的场景并不
太多，单一职责原则更多地是被运用在对象或者方法级别上，因此本节我们的讨论大多基于对象
和方法。
单一职责原则（SRP）的职责被定义为“引起变化的原因”。如果我们有两个动机去改写一
个方法，那么这个方法就具有两个职责。每个职责都是变化的一个轴线，如果一个方法承担了过
多的职责，那么在需求的变迁过程中，需要改写这个方法的可能性就越大。
此时，这个方法通常是一个不稳定的方法，修改代码总是一件危险的事情，特别是当两个职
责耦合在一起的时候，一个职责发生变化可能会影响到其他职责的实现，造成意想不到的破坏，
这种耦合性得到的是低内聚和脆弱的设计。
因此， SRP 原则体现为：一个对象（方法）只做一件事情。
谈一下个人见解，程序是给人读的，一个函数的复杂度越高，读通的成本就越高。即使是你写的程序，几个月后，看懂其中的意思可能就需要一会儿，何况别人也可能接手你的代码！
程序先让人看懂了，再谈运行的性能优化
如果你的代码只需要用很短的时间，不需要以后迭代，不需要提供给其他同事用，也不需要单元测试，那么随便写吧，功能实现就行了。
如果你的代码需要被其他同事调用，需要进行迭代，需要扩展，需要单元测试。那还是按照规范来做吧，性能从来就不是代码的形式决定的。
最简单的方法，如果你的代码隔一个月以后自己来看，发现很难阅读，很难维护，很难扩展，那还是重构吧。
我认为一个函数只干一件事更好 .... 鬼知道这些阴险的函数会不会到处散播副作用 ...
还是只做一件事，最后把他们黏连起来使用比较好。
还有我不认为性能上有很大差距 也许一个函数只干一件事性能还会更好。
第一段代码相比第二段的一个明显特点就是 每个函数的平均行数少了，第二个平均行数比较多。
维护编写短小的代码心智负担比较小 从而维护编写的效率高
只做一件事意味着 这个函数只要能做完这件事就可以了， 你可以轻而易举地用别的算法实现的这个函数的副本直接替换。
由于编写了众多短小精悍的小函数，组装的时候抽象层次会高一些，更符合思考。
为了复用、为了拓展从来都不是
提前优化，相反，更应该重视这两个你说得没错。就是为了可读性、扩展性、和复用。最主要还是可读性/可维护性。干多件事情的函数你都没法起名呢，更别说让别人理解了。
过早优化是这个：「一个函数就占内存的一些空间呢」。