物件導向的思想，先把現實中的對象轉化為程式上的對象。程式，是解決某個問題的相關步驟和次序。而實際很多時候，程式描述的是一個情境活動，首先是有主體，然後是相關活動。程式固有的含義，可能就比較關注活動，而不關注主體。物件導向，首先要確立活動情境中的主體，也就是對象，在分析主體所擔當的職責，也就是功能。過程性的開發方法，強調的是活動，那麼活動的主體是什嗎？是資料，也就是，在過程性的觀點下，程式只是資料的變換過程。而物件導向的觀點，則是對象之間職責的傳遞：“我把我的工作完成了，然後交給你接著做”。過程性的觀點是比較低層次的，比較接近電腦的層次，而物件導向，就比較人性化。但是物件導向也離不開過程性的觀點，因為程式註定還是要有人去做資料變換。一個活動情境：辦理工商執照。首先辦理工商執照需要有場地，資金，合伙人，生產經營必要的工人和工具，同時要經過工商部門的審批。這些就是對象。歸納了對象之後，往往很自然就會產生類。但是類和對象是不同層次的，對象是類的一個具體例子，類是對象的抽象。就好比3 和 x 在數學裡的關係，x這個變數抽象了具體的數字，大大提高了代數式的適用性。
原則上提倡提高抽象的層次來編程，這樣會提高程式的適用性。可惜，類還不是最高的抽象層次，因為類和對象是緊密捆綁的，一個類的所有對象的實現都是一致的，只是數值上有細微的不同。就比如每個工商所都是這個辦證流程，不同的只是名字。正因為這種局限性，所以才有了介面的出現。介面是不關注實現的，他只關注如何使用這個具體實現。當我們需要更大的靈活性時，不滿足只是數值上的差異時，想要結構上的，根本上的不同實現時，就要基於介面來編程。另一個方法是產生子類，子類把父類當作介面，但卻繼承了他的所有實現。有時候方便，因為畢竟你並不需要全盤推倒，只需要修改某些局部實現，但是有時候反而容易搞混。
我認為，當要用子類化的方法編程，首先就要規劃好整個類族結構，而不只是簡單的為了把父類當作介面。然後關於類的設計，只有一個簡單的原則，“名副其實”。活動情境中的主體，是為了活動而存在的，因此他也是職責的化身，在這個架構限制內設計對象便可。然後是活動，物件導向的活動是職責的傳遞，應該如何構建這個傳遞過程？是接下來的重點。活動是商務程序，而流程實際上是可以歸納成一種設計的模式，而不管具體的業務內容是什麼。流程傳遞的是資料，關於資料的處理，就是演算法的內容。可以把資料和演算法獨立出來，與主體和活動分離開來，單獨處理。總的來說，
對象可以分為三類：主體類，活動類，資料與演算法類。將他們區別開來，對程式的清晰性有協助，但是最終也要將他們融合進來，組成一個有機整體。
4.模型和架構，模式等內容5.實施策略和檢查效果的手段
