一般對購物車簡單的描述會是這樣的（其實就是awdwr中的那個depot）：
乙個容器，可以放很多商品，可以隨時檢視購物車中的商品列表，這個列表能列出商品名稱，單個商品購買的數量，商品單價，以及總**。
我的思考過程是這樣的，首先，它是個容器，可以放很多商品，那就是個陣列吧，至於數量，檢視的時候不是要遍歷嘛，順帶計算一下就好。
想了一會，我覺得這種思考習慣，或者說設計過程是屬於自底向上的，一開始就脫離上層的需求，去思考最底層的實現。我覺得這樣會帶來問題。需求是最高層的，而這時候的設計卻是最底層的，中間全脫節了。什麼？沒有脫離需求？沒錯，這樣的做法[b]最終[/b]確實[b]能[/b]實現乙個購物車，沒有脫離最終的使用者需求，但在開發過程中會帶來很多麻煩。就從我上面的例子來說，最後的購物清單頁面不得不塞入大量計算數量、**等等的業務邏輯**。
如果一開始就設計頁面的**呢，寫好像這樣的
<%for item in @cart.items%>
<%=item.title%>
<%=item.quantity%>
<%=item.price%>
<%end%>
<%[email protected]_price%>
那接下來下面需要些什麼不是很清楚了？也許一開始想不出什麼@cart.item，但至少知道是個容器，裡面的東西取出來之後，不需要寫其它邏輯，不需要經過一系列計算就可以直接訪問它的title、quantity、price屬性。這樣就明確了session裡存放的應該是個容器，這個容器不會是個赤裸裸的陣列，因為它得有個total_price方法，陣列應該是它內部的乙個屬性。並且這個陣列裡不應該是直接存放book、cd啥的，或者存放一堆的抽象類product，不應該直接是這些……怎麼稱呼來著……entity吧——不應該直接放這些東西，而是上層（頁面）直接需要的東西——頁面需要的是乙個包含了title、quantity、price屬性的物件，最後差的只是給它起個名字了，嗯，就叫cartitem吧。
前面提到的"脫離需求"，不是指脫離最高層的需求，不是指脫離最終的使用者需求，而是指下層脫離上層的需求。合理而自然的做法應該是下層的實現依賴於上層的需求，一層一層往下走，不知道這樣描述夠不夠清楚。
嗯，搜尋到ajoo的一篇：[url]
看了一遍，其中有一句：
[quote="ajoo"]但是，有一點從oo的前驅po那裡開始到現在都沒有變化，那就是，它們始終都是自頂向下的逐漸細化求精的方**。 [/quote]
看來我的想法沒有錯。「不能讓下層脫離上層的需求「就是指應該逐層地」自頂向下的逐漸細化求精「。
寫得有些混亂，只是當筆記記錄一下今天的領悟。
又見日誌 從日誌中的思考
煮酒品茶 文章寫的比較爛，如果有更好的方案或者有啥錯誤的話請指出來，品茶在此謝過了。前記 換新工作後，這邊有另乙個部門的同事打 過來要協助。說作業系統啟動不了。報錯duplicate or bad block in use 詢問過程 1 穩定對方，問題發生了咱們不急慢慢解決，別腦袋短了思路。2 詢問...
從工作的維度思考快思考慢思考
快思考的執行是無意識且快速的，不怎麼費腦力，沒有感覺，完全處於自主控制狀態，主要根據我們得記憶 經驗 潛意識對問題快速判斷。慢思考將注意力轉移到需要費腦力的大腦活動上來，例如複雜的運算，通常與行為 選擇和專注等主觀體驗相關聯。面對乙個問題時，我們的腦海中最先出現的想法來自於快思考，它在熟悉情境中採取...
批判思考 從有效論證中收穫新知
怎麼樣去面對不同的聲音？在開始討論之前呢，大家找到的答案和蒐集的資訊是怎麼樣的呢？但這裡由於時間的關係。我不能給大家具體的資料，但是我只能給大家講一講可能大開眼界的乙個訊息。孕婦一般要穿防輻射衣，可是防輻射衣真的能夠防輻射嗎？那答案是什麼呢？答案可能跟大家設想的不太一樣，防輻射衣它為什麼不會在美國流...