$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;
}
or
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();
});
这两段代码哪个相对较优一点…… 虽然都挺渣的 大佬们对付看吧
一个函数只能干一件事这么做是为什么 可读性?扩展性?复用性?在我看来声明函数也不是没有成本的啊 一个函数就占内存的一些空间呢 调用函数也没有直接解析来的快吧~
如果是为了复用、扩展的话 第一次写的时候就这样做的真的不是提前优化吗 以后的需求都确定不了呢 怎么知道提出的函数放在未来是通用的呢 这样看绝对不是最佳性能的实践啊~
提前 / 过渡优化不是万恶之源吗?~
就一个类而言,应该仅有一个引起它变化的原因。在 JavaScript 中,需要用到类的场景并不
太多,单一职责原则更多地是被运用在对象或者方法级别上,因此本节我们的讨论大多基于对象
和方法。
单一职责原则(SRP)的职责被定义为“引起变化的原因”。如果我们有两个动机去改写一
个方法,那么这个方法就具有两个职责。每个职责都是变化的一个轴线,如果一个方法承担了过
多的职责,那么在需求的变迁过程中,需要改写这个方法的可能性就越大。
此时,这个方法通常是一个不稳定的方法,修改代码总是一件危险的事情,特别是当两个职
责耦合在一起的时候,一个职责发生变化可能会影响到其他职责的实现,造成意想不到的破坏,
这种耦合性得到的是低内聚和脆弱的设计。
因此, SRP 原则体现为:一个对象(方法)只做一件事情。
谈一下个人见解,程序是给人读的,一个函数的复杂度越高,读通的成本就越高。即使是你写的程序,几个月后,看懂其中的意思可能就需要一会儿,何况别人也可能接手你的代码!
程序先让人看懂了,再谈运行的性能优化
如果你的代码只需要用很短的时间,不需要以后迭代,不需要提供给其他同事用,也不需要单元测试,那么随便写吧,功能实现就行了。
如果你的代码需要被其他同事调用,需要进行迭代,需要扩展,需要单元测试。那还是按照规范来做吧,性能从来就不是代码的形式决定的。
最简单的方法,如果你的代码隔一个月以后自己来看,发现很难阅读,很难维护,很难扩展,那还是重构吧。
我认为一个函数只干一件事更好 .... 鬼知道这些阴险的函数会不会到处散播副作用 ...
还是只做一件事,最后把他们黏连起来使用比较好。
还有我不认为性能上有很大差距 也许一个函数只干一件事性能还会更好。
第一段代码相比第二段的一个明显特点就是 每个函数的平均行数少了,第二个平均行数比较多。
维护编写短小的代码心智负担比较小 从而维护编写的效率高
只做一件事意味着 这个函数只要能做完这件事就可以了, 你可以轻而易举地用别的算法实现的这个函数的副本直接替换。
由于编写了众多短小精悍的小函数,组装的时候抽象层次会高一些,更符合思考。
为了复用、为了拓展从来都不是
提前优化
,相反,更应该重视这两个你说得没错。就是为了可读性、扩展性、和复用。最主要还是可读性/可维护性。干多件事情的函数你都没法起名呢,更别说让别人理解了。
过早优化是这个:「一个函数就占内存的一些空间呢」。