2011年2月15日 星期二

c++ string tokenizer

This is string splitter for STL string. If there is any problem, please contact me. This version is used wstring. You can modify it into "tstring" version for all condition.

 

    void Tokenize(const wstring& str, list<wstring>& tokens, const wstring& delimiters = L" ") {

        // Skip delimiters at beginning.

        wstring::size_type lastPos = str.find_first_not_of(delimiters, 0);

        // Find first "non-delimiter".

        wstring::size_type pos = str.find_first_of(delimiters, lastPos);

        while (wstring::npos != pos || wstring::npos != lastPos) {

            // Found a token, add it to the vector.

            tokens.push_back(str.substr(lastPos, pos - lastPos));

            // Skip delimiters.  Note the "not_of"

            lastPos = str.find_first_not_of(delimiters, pos);

            // Find next "non-delimiter"

            pos = str.find_first_of(delimiters, lastPos);

        }

    }

 

int _tmain(int argc, _TCHAR* argv[]) {

    wstring wstrInput = L"This;Is;A;Test;;;;;;";

    list<wstring> tokens;

    Tokenize(wstrInput, tokens, L";");

    return 0;

}

 

2011年2月14日 星期一

OO設計原則

OO的設計很多人都知道

 

•Encapsulation (封裝)

–Encapsulate member into a class

–Modularity

–Information hiding

–Reusing

•Inheritance (繼承)

–Override

–Extension from super classes

•Polymorphism (多型)

–Re-implement interfaces from super classes

–Overload

 

但是, OO設計的原則, 卻很少人提及...

•SRP:Single Responsibility Principle(單一職責)

•OCP: Open Closed Principle(開放封閉)

•DIP : Dependency Inversion Principle(依賴倒轉)

•ISP:Interface Segregation Principle(介面隔離)

•LSP : Liskov Substitution Principle(替換)

•CARP:Composite/Aggregate Reuse Principle(合成/聚合複用)

•LoD : Law of Demeter(迪迷特-最小最少認知)

其中最容易理解, 卻也最難做到的, 正是單一職責及開放封閉原則

第一, 何謂單一職責!?

一個class不該擁有兩種以上的能力(功能), 也就是說, 一個class只做一件事, 當然這件事的大小, 可以再分割下去, 直到寫程式不再是一件難事就行, 但是如果這個class慢慢的被加大, 那就該考慮是不是該用refactor方法, 再分割這個class, 但為什麼這很難達成呢?

答案是:偷懶, 每次加一點code, 就像青蛙在水褚被煮一樣, 你不會有所感覺, 直到有一天真的很大了, 也難分割了, 就以就放著讓他爛...

最好的解法: 當然有, 但..要看到一個class加了一個新的功能時(不影響主功能)就分割, 可能要有點經驗的人才知道這樣的分法是好一點的, 有的class很小, 有的class很大, 寧可讓所有的class都是小的再結合成大的, 也千萬不要讓class長大再refactor, 如果你有maintain很大型的code經驗, 你知道我在說什麼

第二, 何謂開放封閉原則!?

一段程式碼, 應該對於修改採取封閉, 對新增功能採取開放..

也就是我不允許別人修改我寫完的code, 但是對於要新加的功能是可以的, 最好的做法就是繼承, 當然這也不是解決"開放封閉原則"最好的方法, 最好的方法是程式寫好都不要動, 所有的功能都放在另一個地方去指定, 把這功能都組合起來就可以達到你想做的事情, 但....

答案是: 不可能

在設計的最初這件事情不可能達成, 但設計後總有design document, 可以指定哪些東西不得修改(這是這個程式最主要的功能, 沒有這功能其他都免談的地方), 也就是不可修改程式必須的功能, 但對於擴充功能是要可以的..

可是可是...這個也很難達成是吧...一個巨型的計劃中, 所有的功能不但可能改變, 更有可能被要求加入和先前設計完全不同的功能..這時就得輪到主管出馬了

總之問題的發生在於人對於"程式"的想法..如果有不能解決的, 還是得溝通一下...

謹記在心, 如果有天你發現加了新的功能要改到原有的code, 或是要改到很多地方的code...那你一定是違反了開放封閉原則了