Object Oriented Design Cracking the Code Interview Study Group 9

C++(Object-Oriented)軟體樂高

把石頭拿掉還可以走(橋梁)

>> 拿掉跑不動了

#> C++ compiler >> 執行速度 >> 執行大小(output) >>> 手機空間受限(1、2M一個考量) >> 沒有很多CPU可以用，無法concurrent(早期語言的問題)

Object and Classes

>> 物件和類別(抽象一層裝水的容器、水瓶)
>> 不同的實體，特性和功能
>> attribute:表示特性(容量多少、顏色、大小)
>> methods(大腦認知，就直接拿來喝，這有甚麼問題嗎?直接拿來用)

重點是封裝

>> 包裝在自己的單元裡面，從外面看不到
>> 其他資訊可能看不到(電話和名字)
>> 例如:遙控器(abilities去解釋)
>> Interface(提供那些讓外面可以互動)
>> Attribute可能外顯或隱藏屬性(不知道成本多少)
>> 切成獨立不互相影響的單元(會喝，都可以喝各種東西)
>> 出新的水壺還是可以拿來喝(Interface)

多形(Polymotism)

>> 一手把的門(只要知道開關就好了)
>> 符合條件就是門，Generic開或關
>> 按了開，不管是手推還是自動開

混在一起講

>> 繼承有些特性可以帶到子類別去的
>> 可以上鎖的門(lock或unlock功能)
>> 指紋鎖

GUI Widget

>> 很多東西都是一層一層的
>> 一個graphic一個graphic(display和hide)
>> 方形的，視窗或按鈕(有圖有文字有按鈕的按鈕)
>> 熟悉C++可以看QT(歷史悠久，千錘百鍊)

Desigin類型，題目不是很清楚

>> 商店的管理系統(有額外的考量)
>> 百貨公司(各種折扣)、超商等級(是否可以寄杯)

Identify Core Objects

>> 和真實世界的東西，互相獨立，有清楚的interface
>> 判斷關係
    >>> is/in a:上下關係
        >>>> 可以打字不一定是電腦
        >>>> 自動門(censer、馬達)
        >>>> 同一個東西解釋兩種概念(一個願望一次滿足)
        >>>> 取決於design(螢幕，依照不同的情境去設計)
        >>>> 不一定這麼絕對(是不是繼承觀念)
    >>> has a(one-to-one)
        >>>> DB的東西(connection有一定的數量)
    >>> 設定attriubte和method有關係
>> 檔案系統(檔案和目錄)
    >>> 相似性?
    >>> 設計一個class，大class底下子類別
>> 電腦
    >>> 螢幕裝置、儲存裝置(硬碟)、輸入裝置(鍵盤滑鼠)
>> 可不可以多個繼承(C#、Java)
    >>> Interface多重繼承
    >>> 沒有實體(只有屬性和方法)
    >>> 使用的人來說只要可以看就好了(interface)
    >>> 只要會看兩邊都可以進行抽換(還是要用實際的例子會比較清楚)
>> 關係變太複雜了

四位大師不容易看懂

>> 很多人幫他寫(葉秉哲)，不好入手
>> 適合有經驗的人閱讀(字典的概念，應該注意甚麼)
>> 要有足夠的經驗去看(clean code:不單是design，寫code習慣)
>> 一般的人Learning(不適合寫過幾年的人，變成教條)

設計模式之禪(English)

>> 用說故事的方式去連結(西門慶)
>> 對岸出的(OO使用)
>> 重構對初學者太難了

Singleton

>> 不會去生出第二個實體
>> 某些東西希望只有一個個體
>> 有其他變形可以參考

Factory Method

>> 透過工廠生出物件
>> 不是自己去new(重複使用的東西可以運用)
>> 檔案總管視窗(視窗物件，經常要生出一些區塊、排序也不用自己在寫)
>> 只要給參數就會自動產生(open、close handle)
>> 只要說要甚麼口味，機器自己會調配出來，你要的東西
>> lazy loading?(想聽忘記問了XD)

Delegate

>> 把別人要我們做的委派給真正要做的人
>> framework只要叫別人show出來就好了(自己畫東西出來)

State

>> 挺複雜的，跳過

Software Engineer

>> 有空的時候翻過一遍
>> 不一定面試的時候可以派上用場
>> 比較困難碰到，coding重複性高，attribute(分類方式?)
>> 比較少是嗎?(領域的關係)
>> 書就像是一本目錄而已(一個產業碰到所有東西是很困難)
>> 可以用來改善現有程式，或用到新的desigin(反覆遇到相同的pattern是很正常的)
>> 因為領域相同，自己偷偷改code(自己重新改過)
>> 不能偷偷改，要有review(這種東西怎麼會過?)

提完design，實作之後又有不一樣的地方

>> 一群人昏頭(修以前的bug修不完)
>> 總要有人維持

File system

>> 目錄和檔案(現代系統)
>> 視為同樣的東西(可以Open/close/data/write/read)
>> 檔案data(代表目錄的file)
>> 加新的目錄(Linux)
>> 各種屬性(隱藏或是其他，access right)
    >>> 有目錄的屬性就是目錄
>> Link
    >>> link data指向的東西(一種Interface代表不同的東西)
>> Memory
    >>> 指向哪一塊Memory(對應記憶體)
>> 簡化後只需要用到一種Interface

黑白棋

>> 主要class(game、board、chess、player)
>> 看一下個別的東西是否足夠的獨立(關係可以切開來)
>> 不會有互相參考的狀況(夠乾淨)
>> 棋盤是平的，這樣就可以玩了(in a)
>> 一場game兩個人、64個旗子(一些旗子)
>> factory(傳兩個player進去就可以開始玩了)
    >>> 把關係決定了(初始化)
    >>> support那些method(new game)
    >>> 可以屬於board也可以屬於game(沒有絕對答案)
    >>> user只要看到game(public/private)
    >>> delegate board去做事(分別做甚麼事情)
    >>> 封裝(不需要傳board進來，讓外面的人可以修改)
    >>> board下棋子(自己控制好就好了)
>> 狀態和實體分開可以減少記憶體的用量
    >>> 分別下到甚麼狀態
    >>> 保存或切開(board放到資料庫中)
    >>> 可以Save遊戲(不同game之間)
    >>> code邏輯一樣
    >>> 樣板方法?(State和Object切開)
    >>> 單獨做成一個object(save and load這個Object)
    >>> 東西可以分別切開(前後端可以切開，分別升級)
    >>> interface(可以seperate不同東西)
    >>> 棋盤有一個array可以放，保存board的狀態
    >>> 把不變和會變的東西抽開(前後層)
    >>> 資料庫(後端)
    >>> configuaration變成一個file(在抽象化一次)
    >>> save/load configuartion
>> 檔案不在就去download
    >>> 雲端(本機)
>> 對外面的人不知道
    >>> 實際已經call到不同人身上了
    >>> strategy(排序、quick/bubble sort、sorter interface)
    >>> 追加sorter在另外定義
>> IOT state
    >>> 放DB，SQL(前端service就是負責運作)
    >>> 不存任何state，只做operation
    >>> 重開，scalable(momemto)
    >>> 東西的狀態和實體切開就可以保存了(可以serialize存下來)
    >>> 設計沒有考慮就比較麻煩(避免以後麻煩，解決眼前問題沒那麼難，很多東西都可以達成)
    >>> desigin不好的東西就有感覺
>> 甚麼時候使用重構(半年/一年)
    >>> 想加新東西加不進去，技術債，不趕快還就會越來越難處理
    >>> 不見得每個人，變比較彈性