Re: [請益] 很多層迴圈和if 怎麼寫比較好整理

[TonyQ (沉默是金。)]

※ 引述《ericinttu (第幾次的)》之銘言：
:         那麼, 這又要怎麼寫呢?
:         function 我要把特定區域的pixel紀錄在特定table裡(image,region,table)
:         {...}
:         所以, 這樣懂了嘛?
:         不懂的話, 不要說什麼高中生法官之類的, 我還只是個小學生.


        我覺得你這個例子不是那麼的好 XD

        我們來談深入一點的東西吧，在複雜條件式判斷的狀況下。


        一般狀況下，複雜條件式判斷指的是執行的路線是分歧的，
        也就是滿足 A Condition 的時候我做 A() , 滿足 B Condition 時我做 B()。


        而今天主要的問題會在於兩件事，

        1.擴充性，我今天要增加 C Condition 時，
          我會不會因為 A Condition /B Condition 而增加「很多」複雜度。

        2.封閉性，我今天修改A Condition，會不會不小心一起改了 B Condition


        所以複雜 if-else 的問題呢，本質上其實問題不在 if-else 的敘述，
        而是在於「共用條件」這件事情，能不能在程式碼上清楚的表達出來。


        理想狀態是兩個條件彼此之間是應該盡量不要有太多相依的判斷，




        理想狀態其實至少應該要是這樣的

        if(isA()) A();
        else if(isB()) B();
        else if(isC()) C();


        至少這種狀況下你新增跟修改都不會有太大的問題，
        當然野心再大一點就是這個東西會是用狀態或策略模式去判斷


        他就會變成類似這樣的例子，
        雖然這個例子並不是那麼通用，不過概念上點到就好。囧

        Map<String,Handler> handleSet;
        void addHandler(String type,Handler handle){
                ....
        }

        -----------------------------------

        Handler han = handlerSet.get(type);
        handler.run(data) ;



        至於其他的邏輯跟實作交給 Handler 去封裝，
        你只要負責確保這個 handler 是能做事跟拿的到的就好。


        這個的好處是在於完全就是抽象層的判斷，
        對於實作比較不是那麼講究（通常是performance 考量較低的），

        會比較舒服點。


        當然也有些人或有些時候不一定需要為了很簡單的邏輯，
        抽狀態或策略物件，這也是個權衡的要素。

        我不覺得看到 if-else 就非得要讓他消失...

        -----------------------------------


        另外單一的 for 基本上都是能封裝拆 method 出去的，
        通常是端看你願不願意/想不想拆而已，


--
我：一半的日子讓你說，我聽你說你的所有______________________________________
______________________________________一半的日子我想說，對你說過去的所有：我
        _______________________________________________________

        在討論中妥善扮演兼具聆聽與分享的角色，是我們一生的課題。
        _______________________________________________________

--
※ 發信站: 批踢踢實業坊(ptt.cc)
◆ From: 12.208.243.66
※ 編輯: TonyQ           來自: 12.208.243.66        (07/16 19:02)
※ 編輯: TonyQ           來自: 12.208.243.66        (07/16 19:04)
推 andymai:推~不過如果要套Design Pattern可能也要考慮到Know How的
→ andymai:問題~因為有很多時候是看起來可以套~但預期以後要改的地方
→ andymai:會和這個設計相衝突，那套了可能不會比較好~重構的工更多
推 edward13:原po只給一堆括號叫人paring連pseudo code都沒真是好問題
→ edward13:                    parsing