$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 原則體現為:一個物件(方法)只做一件事情。
談個人見解,程式是給人讀的,一個函數的複雜度越高,讀通的成本就越高。即使是你寫的程序,幾個月後,看懂其中的意思可能就需要一會兒,何況別人也可能接手你的代碼!
程式先讓人看懂了,再談運行的效能最佳化
如果你的程式碼只需要用很短的時間,不需要以後迭代,不需要提供給其他同事用,也不需要單元測試,那麼隨便寫吧,功能實現就行了。
如果你的程式碼需要被其他同事調用,需要進行迭代,需要擴展,需要單元測試。那還是按照規範來做吧,效能從來就不是程式碼的形式決定的。
最簡單的方法,如果你的程式碼隔一個月以後自己來看,發現很難閱讀,很難維護,很難擴展,那還是重構吧。
我認為一個函數只乾一件事更好 .... 鬼知道這些陰險的函數會不會到處散播副作用 ...
還是只做一件事,最後把他們粘連起來使用比較好。
還有我不認為性能上有很大差距 也許一個函數只乾一件事性能還會更好。
第一段程式碼相比第二段的一個明顯特徵就是 每個函數的平均行數少了,第二個平均行數比較多。
維護編寫短小的程式碼心智負擔比較小 從而維護編寫的效率高
只做一件事意味著 這個函數只要能做完這件事就可以了, 你可以輕易地用別的演算法實現的這個函數的副本直接替換。
由於編寫了眾多短小精悍的小函數,組裝的時候抽象層次會高一些,更符合思考。
為了復用、為了拓展從來都不是
提前優化
,相反,更應該重視這兩個你說得沒錯。就是為了可讀性、擴展性、和復用。最主要還是可讀性/可維護性。做多件事情的函數你都沒辦法取名呢,更別說讓別人理解了。
過早最佳化是這個:「一個函數就佔記憶體的一些空間呢」。