| |
![]() |
 |
| |  | | | |  |
| |
![]() |
| 專欄 | | ![]() | ![]() | 思考物件導向(1)物件導向與封裝
OO的三大基礎是封裝、繼承、多型。用現實生活的物件做OO解說上的比擬，通常不會太恰當，因為只能解釋封裝和繼承，卻無法解釋多型。而多型卻是OO真正的重點，也是學習OO的門檻。
十多年前讀大學時，我對於OO（Object-Orientation，物件導向）興致正濃，看了不少OO的書，有外文書，也有中文書。其中，中文書為了幫助讀者理解，都會用現實生活中的物件做比擬，比方說：哺乳動物、交通工具，我記得我讀過的一個範例中提到：「斑馬」繼承自「馬」。
學習OO的重點：封裝、繼承、多型
在工研院當實習生時，老闆要我報告OO，於是我舉了書上的例子，當老闆聽到我宣稱「斑馬繼承自馬」時，他開玩笑地說：「那麼馬子（女朋友）應該也是繼承自馬。」我深受羞辱，感覺被IT中文書荼毒了。
封裝
封裝（Encapsulation）的目的，是將程式碼切割成許多模組（Module），使各模組之間的關連性降到最低，這麼一來比較不會產生「牽一髮而動全身」的狀況，降低模組間相互依賴的程度，也等於是降低複雜度，讓開發與維護更容易。
全文>> | |
| 專題報導 | | ![]() | ![]() | F5跨入檔案虛擬化市場
F5透過併購Acopia，跨入檔案虛擬化的市場，目前並沒有計畫推出新的檔案虛擬化產品，但是將整合F5與Acopia的管理工具。
F5日前併購檔案虛擬化廠商Acopia，這等於正式宣示F5跨入檔案虛擬化的市場。對於F5來說，進入檔案虛擬化市場，將可以補足F5原本的應用程式傳輸優化方案所缺乏的一塊，進而提供企業由資料中心至終端的完整傳輸優化方案。
將維持Acopia原有產品線，且整合管理工具
Acopia原本是檔案虛擬化市場上少數幾家僅存的獨立廠商，是由華人創業家吳錦城所成立，隨著F5將之併購，其旗下的檔案虛擬化產品ARX系列，也將納入F5的產品方案中。F5亞太區副總裁宋丹昱表示，過去F5有辦法提供應用程式加速與負載平衡，提升企業應用的效能，但是卻沒有辦法在儲存資料效能提供改善的解決方案，而透過Acopia的併購，現在將也有能力提供此一領域的方案。
網路傳輸廠商開始跨入虛擬化市場
值得注意的是，近來除了F5以併購Acopia為手段，增強在傳輸效能的解決方案上的完整性，另一家網路傳輸效能優化的廠商Citrix，也同樣的透過併購伺服器虛擬化廠商XenSource，跨入伺服器虛擬化的市場。而兩家廠商所鎖定的目標也雷同，同樣希望透過提供虛擬化的方案，補足自己原本無法改善的伺服器與儲存效能問題。
全文>> | |
| 產品評測 | | ![]() | ![]() | SSL VPN－合勤ZyWALL SSL 10
ZyWALL SSL 10本身提供多種認證方式，可依據需求自行選擇，最多可同時允許10位使用者建立通道與企業內部建立連線，此外，設備亦提供了SPI防火牆、NAT，以及DHCP伺服器的功能。
 ZyWALL SSL 10是桌上型的SSL VPN設備，最多可同時允許10位使用者建立通道與企業內部建立連線。此外，設備亦提供了SPI防火牆、NAT，以及DHCP伺服器的功能，5組網路埠當中，包含了1組WAN埠，以及4組LAN埠，理論上，透過單一設備就可以應付企業建置網路的需求，不需再額外採購其它的閘道端硬體。
設備的基本設定相當容易，透過設定精靈的輔助，基本上，用戶可以在2、3分鐘內完成6大項的操作步驟；接著可以在設定介面自行新增服務類別，如HTTP、遠端桌面、郵件以及檔案共享等，並依據需求將服務指派給特定的帳號或者是群組，僅允許特定的使用者可以存取特定的應用程式服務，以維護企業內部資料的安全。
提供多種認證方式，可依據需求自行選擇
除了手動建立使用者帳號之外，我們也可以讓設備AD、RADIUS等伺服器查核使用者身份，讓使用者僅憑一組帳號密碼就可以存取企業內部的大多數網路資源，達成所謂單一登入（Single Sign-On）的目的。
提供端點檢查的安全功能
為了防止有害內容透過VPN進入企業內部，許多SSL VPN設備都有提供端點檢查的功能，一旦發現電腦的安全性未能符合需求，設備就會拒絕建立連線，直到問題解決之後才會准予放行。ZyWALL SSL 10在這方面提供相當精細的檢查項目，從作業系統（以Windows為主，但不支援Windows Vista）、Service Pack、防毒軟體，以及目前所使用的瀏覽器之外，其它像是背景程式、註冊機碼等項目，皆可列入檢查的範圍。
全文>> | |
| 專欄 | | ![]() | ![]() | 物件導向程式設計常見的錯誤(3)立體的系統架構，可降低修改的影響
適當分層的系統，有助於降低組件之間的相依性，及縮小未來系統修改或擴充時所影響的範圍。
在著手設計系統前，有一個更重要的工作，就是決定系統的架構。設計完成的類別也許已形成一個架構，也許沒有。其中的關鍵在於這些類別是否具備特定的角色，以及不同角色的類別之間，是否存在特定的互動關係。
設計者最常犯的錯誤，是沒有在設計類別之前，就先設計系統中可能會有的類別角色、每一種角色應該提供的特定作用，以及不同的角色之間互動的方式。
在這種情況下，設計者就像是煮了一碗牛肉麵，而碗裡的麵條彼此相互糾結，關係十分複雜。相形之下，有個舉世聞名卻又簡單清晰的軟體架構，就是Unix的系統架構，它是最佳示範。
Unix的系統架構設計，是最簡單清晰的示範
Unix將系統的運行畫分為核心（Kernel）以及外殼（Shell）。系統核心提供所有應用程式共通、需要作業系統提供服務的系統呼叫（System Calls），而處於外殼的應用程式除了執行自身的程式碼之外，同時利用作業系統所提供的系統呼叫，達成應用程式的用途。
有層次的架構使軟體像房子，有了立體的高度
在Unix上使用C語言開發應用系統的人，對於圖三的架構絕不陌生。
相較於上述的架構，這個架構將核心之外的外殼部份拆成了兩層：應用程式及執行時期程式庫（Run-Time Library）。執行時期程式庫萃取應用程式在開發時常見的需求，將這些需求畫分到執行時期程式庫負責的範圍，使得程式人在開發時不需要浪費心力，撰寫相同或相似的程式碼。
全文>> | |
|
![]() ![]() | PChome ePaper 電子報版權所有，關於電子報發送有任何疑問，請聯絡 客服
台北市敦化南路二段105號11樓 ，TEL：(02)2708-8038，FAX：(02)27094848。 | ![]() |
沒有留言:
張貼留言