ood對現在的程式設計師來說並不陌生，甚至在不知不覺中使用著。
ood，物件導向設計，關鍵在於物件的「設計」。乙個物件，通常是資料+方法的封裝，public對外介面，private或protect內部實現細節，必要情況下public出readonly內部成員狀態。
物件設計的過程，會碰到各種場景、問題。從而總結出各種「設計模式」。對於具體的各種設計模式和物件設計原則。這裡就不作細說了。談談這個月來，碰到的一些問題。
最近在實現一種比較符合目前產品狀況的撤銷重做，是一種基於記憶體狀態的撤銷重做。這種撤銷重做，只要求監視業務模型物件即可。所以要求程式架構要能滿足mvp設計模式——model-view-present。model只純粹提供業務方面的物件資料，view為表示層提供各種展示方式，相當於關聯式資料庫提供的表檢視，而present則是人機互動介面。
可能是因為實際實現過程中，並沒有人嚴格意識到，model-view之間的嚴格界限；又或者是「偷懶」緣故。很多本來應該是在view層面體現的東西，放在了model。這種會造成什麼影響？第一，首先的model的可重用性，因為與具體的展示view產生了「依賴」；第二、view要求的變化，會影響到model；第
三、影響後續功能擴充套件，比如這次的撤銷重做，不得不把這個view層面的東西，也納入記憶體監視範疇。
總結，1、組內成員必須都能意識到整體的架構設計原則，清晰認識物件職責；2、**評審，要能做到：檢查每天提交的單元。
另外乙個問題，這個比較細點——關於物件設計。很多時候，實現乙個物件時，通常是把這個物件需要的東西，都作為其成員存在；destroy時，再釋放這些成員。咋看沒什麼問題。但是從另乙個角度看的話，還是可以發現可以改進的空間——記憶體。
細緻分析物件成員，原則上，只有反應物件狀態的資料，才可以成為物件成員；而對於那些，在某幾個方法內使用的，甚至只在乙個方法內使用的，不應該提公升為物件成員。有些程式設計師為了方便，把在幾個方法內使用的資料，定義在類中，這樣不必給每個方法定義引數。這樣做不好的影響，首先太佔記憶體了；有些子物件，本可以考慮作為單例模式提供服務的，卻在物件內部建立出來；有些只需要特定方法內產生的，也被提公升為物件成員，建立出來。其次，隨著業務擴充套件，業務物件開始變得「臃腫」了。
目前，程式單元還存在幾個「超級類」,基本是這樣累積下來的。當然，這裡面一部分原因是，架構的「迭代設計」一直沒有執行。
關於平面最近兩點問題
最簡單的思想是直接進行遍歷，也就是n n 1 的複雜度 如果採用分治的思想會簡單很多 看了好幾篇blog，發現都不怎麼講人話，其實本質上是通過一維分治推出來的 對於一維數軸下找最近兩點，可以按照座標點進行分治 直接遞迴二分區域，使得細分為左右各有乙個點或者兩個點的區域 但是有可能發生以上的情況 左半...
關於區塊鏈的兩點澄清
1.萬物皆可上鏈？區塊鏈是分布式資料庫？區塊鏈不是分布式資料庫 至少公有鏈不是 很多東西不適合上鏈。區塊鏈可以用於資訊共享，其核心優勢在於可溯源 防篡改 共監督 去中心化 能在不可信的環境中創造信任。所以絕非 分布式資料庫 可以概括，應該突出其嶄新特徵。區塊鏈也有一些問題。位元幣是區塊鏈最成功的應用...
關於建構函式繼承的兩點注意
1，如果基類沒有提供預設建構函式，派生類必須使用base顯式呼叫基建構函式。這是從msdn上看到的一句話 參考http msdn.microsoft.com zh cn library ms173115 v vs.80 aspx 一開始還真沒太引起過注意，最近才發現這個問題，例項如下 class b...