物件導向程式設計基本原則 - SOLID
物件導向程式設計基本原則 - SOLID 在物件導向程式中，遵循 SOLID 這五項基本原則，可以幫助程式設計師寫出好維護、易擴充的程式架構： S: Single responsibility principle(SRP) 單一職責 所謂的單一職責是指一個類別只負責一件事情，阿文18歲生日那天取得汽車駕照，爸爸買一台車可以在天空上飛、在路上走、在水下游的車給他當生日禮物，是不是很酷的事情!? 可是阿文想開這台車，就必須要有機師職照、汽車駕照、潛水艇駕駛證照才能上路，如果哪天這台車故障了，可能要修飛機的技師、修汽車的技師、修潛艇的技師三種專業人員一起查看問題在哪邊才能排除故障。 如果一個類別負擔太多工作，就會像上面的超級汽車一樣，不論是使用上或是後續的維護工作都可能會帶來很大的困擾。要注意單一職責不是指一個類別裡面只有一個方法，在這邊，我們這台車責任是要可以在路上行駛，不過這不代表這台車只會擁有在路上行駛這個方法，實際上，行駛是由前進、後退、左轉、右轉、剎車等等基本功能組合而成的。 但從另外一個角度來看，又要注意功能被切的太細碎造成過度設計（over design）的情況，一台車雖然可以拆成方向盤、大燈、引擎、汽缸等等零件，每一個零件也都有不同的功能，但對汽車駕駛人來說，只要知道車子怎麼開就夠了，不需要去理解車子內部詳細的構造。對維修技師來說，了解細部零件的功能反而才是必要的，因此要怎麼規劃一個類別的責任，就要視實際的需求而定。如何定義一個類別（物件）的責任是一個很抽象也很難釐清的事情，我們在這邊只是略為簡介一下，這部分就先到這裡就好。 O: Open/close principle(OCP) 開放/封閉原則 物件導向程式設計最重要的開放（擴充）封閉（修改）原則。一套軟體應該要保留彈性，可以擴充新功能，但如果裡面程式碼的耦合度（Coupling）過高，新增功能時可能會影響舊功能，甚至會造成程式Bug，因此增新功能時就必須很小心仔細以原本正常程式碼被改壞了，另外高耦合的程式碼在有Bug需要維護修改也是同樣的麻煩。有鑑於此，舊程式碼應該是封閉修改的，或是某個舊功能需要調整，也不應該取影響到其他功能。 以阿文的車來說，我們在設計時就要針對車上不同的功能做模組化，例如說想將大燈改成又白又亮刺瞎別人的眼睛，汽車技師只要更換燈泡，不需也不能動到...