其他

【GOF95】在提出橋樑模式的時候指出，橋接模式是"將抽象化(Abstraction)與實現化(Implementation)脫耦，使得二者可以獨立地變化"。這句話有三個關鍵詞，也就是抽象化、實現化和脫耦。抽象化:存在於多個實體中的共同的概念性聯絡，就是抽象化。作為一個過程，抽象化就是忽略一些資訊，從而把不同的實體當做同樣的實體對待

以下是格式化int,float,double和long型的樣本  ////  PrintFormat.h//  DataTypes////#import <Foundation/Foundation.h> @interface PrintFormat : NSObject{}-(void)

關於Sharepoint的伺服器端物件模型的內容很龐大很繁雜，而事實上，我們在這裡只把最關鍵的對象梳理一下，我們會從三個體系來大致描述它們。   這三個體系分別是：    1、物理對象階層(Physical Objects Hierarchy)    2、內容階層(Content Hierarchy)    3、服務層次結構(Services Hierarchy)。   希望通過我們的大致描述能讓你對Sharepoint的伺服器端物件模型能有一個大致的瞭解。下面進入主題。

              1.Design Patterns              2.敏捷式軟體開發 (Agile Software Development)              3.Expert one on one J2EE development without EJB EN                 Expert one on one J2EE development without EJB CN              4.net本質論第1卷：公用語言運行庫   

       在程式開發中，對變數的命名有一個好的標準是必要的。它不僅對開發人員有協助，也對讀代碼的人有協助。通過在變數名前加適當的首碼，使該變數能儲存什麼類型的資料變得一目瞭然了。本文要介紹的是在使用ActionScript編碼時給變數命名的一個標準，一個專門為ActionScript設計的匈牙利命名法。      

　　　本文引自<Flash 8 ActionScript 寶典>第30章節 建立自訂群組件.            本例實現的是一個滑動條的小列.                    step 1.建立名為Slider.fla的Flash文檔.將其儲存在Slider001目錄中            step 2.在文檔中建立名為Slider的MovieClip元件.            step

出處：袁峰 譯作者：Alistair Cockburn介紹 首先我要解釋一下為什麼會寫這封公開信。這似乎已經成了一種習慣，但這個步驟還是需要的。過去6 年中，

  一、何為代理     顧名思意，所謂代理模式就是通過增加一個中介層（代理類）來操控我們實際要操控的另一個對象，就像一個歌星或專業運動員的經紀人一樣，被操控的對象或者是因為很複雜，或者是因為需要較長的時間才能進行構造，也或者是因為分布在網路的其它位置，這些都需要我們通過代理來解決如何使用這些對象的問題。   二、 我們的例子 

Decorator裝飾模式：主要用於動態地給一個對象添加一些額外的職責。就擴充功能而言，它比產生子類方式更為靈活。先進入我們的例子: 程式如                        定義抽象基類 AbsCar，此處它代表一個抽象的“車”,它既是裝飾類的基類，也是被裝飾類的基類，其代碼如下CodeCode highlighting produced by Actipro CodeHighlighter

       本篇只是簡單的對朱偉大哥開發的DataRabbit ORM資料持久化架構的一次簡單體驗，小例的為：DataRabbitSimpleDemo       有關這個程式的需求請在此處下載:教務管理系統業務描述       本例是DataRabbit 輕量的資料訪問架構（04） －－ IEntityRelationLoader 這篇文章的參考實現．       如果朋友想對DataRabbit架構有更深入的瞭解請關注朱偉大哥的Blog．      

1.緣起：我們經常需要對一些動態對象進行管理，最常見的例子就是線上使用者管理。當一個使用者成功登陸到伺服器後，我們就需要將其管理起來；當他退出後，就不再需要再管理他了。這就是所謂動態對象的含義，這些對象並不是一直需要被管理，只有當其被啟用後，才需要被管理。它們總是在“啟用”狀態和“非啟用”狀態之間不斷地切換。我設計了對象管理器ESBasic.ObjectManagement.Managers.IObjectManager來管理類似的動態對象。這個類是ESBasic提供的眾多個物件管理容器中的非常

  1.緣起：

          （如果您能對照著源碼來閱讀本文，效果會更好。） 1.緣起：       假設我們的員工打卡系統，需要設定公司規定的上班時間、下班時間、以及還要對員工是否遲到早退等這些情況進行判斷。       我們以什麼方式來記錄類似上下班時間這樣只有時分秒沒有年月日的時間了？你說可以使用DateTime，但是合適嗎？總是覺得用DateTime來表示上下班的時間很彆扭，因為我們的上下班時間並需要指定到具體的哪一天啊。      

  1.緣起：    假設我們要開發一個多人跳棋遊戲。在跳棋遊戲中，當一個人走一步棋之後，控制權就輪到下一家，如此輪詢，一圈之後控制權又回到自己，然後再繼續輪圈下去。我們可以使用數組或列表等資料結構來解決這種轉圈圈的問題，但是始終都不夠直觀。    我設計了Circle來對“圈”這種資料結構進行抽象，我們在類似跳棋這樣的遊戲中可以非常方便地直接使用它。Circle的形象如下:      2.適用場合：      

 1.緣起：     假設我的訂單處理系統有這樣的需求：將一天24小時分為4個時段，淩晨2:15到8:30採用A類型的處理器處理接收到的訂單，8:30到14:00採用B類型的處理器，14:00到20:00採用C類型的處理器，20:00到第二天淩晨2:15採用D類型的處理器。    即我們的訂單一處理器需要在任一天的2:15、8:30、14:00、20:00這四個時刻發生切換，這就是一個迴圈切換器所要做的工作。    我設計了ESBasic.Threading.Application.

 1.緣起：     舉個例子也許就能夠說清楚回調定時器的用途。假設我的訂單系統接收各種不同類型的訂單，當訂單A進來時，系統根據訂單的類型和其它特徵進行綜合判斷後，決定A訂單要在2秒之後被方法M1處理；接下來收到的B訂單經過同樣的判斷後，決定要在10秒後被方法M2處理，……。這時候就可以用回調定時器來管理這些將要被延遲一定時間再執行的任務。   

1.緣起：    假設我們的報表系統需要在每天的00:05:00統計前一天的報表資料，需要在每周一的00:30:00統計上周的報表資料，又需要在每月1日的00:30:00統計上月的報表資料。這些報表統計任務是很常見的系統需求，對於類似這樣的在指定時刻執行的定時任務，我使用ESBasic.Threading.Timers.TimingTaskManager（定時工作管理員）來處理它。TimingTaskManager與前面講的回調定時器CallbackTimer的區別在於，CallbackTime

1.緣起：    假設我們的C/S系統中服務端與用戶端之間採用UDP進行通訊，那麼服務端如何知道每個用戶端當前是否仍然線上了？有可能某個用戶端一直沒有退出，但是在很長一段時間內都沒有與服務端作任何通訊，那麼服務端就應該認為這個用戶端已經離線了嗎？為了能讓服務端掌握每個用戶端是否線上的狀態，我們可以這樣做，只要用戶端一啟動起來，就每隔一段時間間隔（如10秒）就向服務端發一個“我還線上”的訊息，以表明自己的狀態。而服務端如果在一個更大的時間間隔內（如20秒）都沒有收到某個用戶端的任何訊息，則可以判定

1.緣起：   

1.緣起：    假設我們的使用者管理系統要求使用者的ID和Name都必須是唯一的，並且使用者的ID和Name一經確定就不能被修改。而且管理系統經常需要根據ID來尋找Name，也經常需要根據Name來尋找ID。根據這樣的需求，我們可以考慮使用一個Dictionary來將ID和Name緩衝起來，通常ID作為Key，Name作為Value。這樣便可實現通過ID查詢Name的快速尋找，但是，通過Name尋找ID就不是那麼快了，因為涉及到對Dictionary的Values做遍曆的操作。那麼，有可能使得