spl[標準PHP類庫]

spl，指SPL - Standard PHP Library 標準PHP類庫。

SPL - Standard PHP Library SPL is a collection of interfaces and classes that are meant to solve standard problems and implements some efficient data access interfaces and classes. You'll find the classes documented using php code in the file spl.php or in corresponding .inc files in subdirectories examples and internal. Based on the internal implementations or the files in the examples subdirectory there are also some .php files to experiment with.

The .inc files are not included automatically because they are sooner or later integrated into the extension. That means that you either need to put the code of examples/autoload.inc into your autoprepend file or that you have to point your ini setting auto_prepend_file to that file.

Below is a list of interfaces/classes already availabel natively through the SPL extension grouped by category.

全面剖析

SPL(Standard PHP Library) IN PHP5

下一步中大型PHP商業套用的主流的開發將會是以OO,OA軟體開發模式主領潮流,從PHP5到PHP6,google Trends足以證明這一點,過去傳統的面向過程的開發模式將會被棄之,如果你是一位真正合格程式設計師,你會發現OO所帶來的好處是深遠的,不僅是軟體工程所帶來的收益,而且此種思維理念對個人思維方式定有大的變革,你會發現你做事情開始OO方式,^_^,OO無處不在.

當然筆者不想去論述用面向過程寫PHP代碼所帶來的好處(如簡單的套用),那種單人時代的開發方式如兒童時代已不適合需求複雜,變化過快的現代商業環境.筆者發現,如今支持面向過程的開發者大多知識不夠全,不夠廣.還不足以用OO來解決商業開發.當然這不是絕對,但一位有著C++,JAVA, Smalltalk、EIFFEL等開發語言背景的程式設計師,他會無一不支持OO開發模式,相反網路知識框架基礎較少,各種協定一知半解,只會PHP的開發人員他們會覺得面向過程最適合他們.

前景

a.文檔的完善與標準如何?

b.背後商業公司或是財團支持如何?

c.採用OO還是面向過程?

d.業務與顯示是否分離與清晰?C OR VC OR MVC

e.數據結構如何,數據表最佳化如何?數據驅動支持?

f.開發進度如何?目前核心開發成員水平如何,要注意原核心團隊的去留?

g.代碼內置調試如何,代碼糾錯處理過程怎樣?

h.有無自己核心開發框架?有無採用流行的框架?

i.許可權管理等基礎CMS功能如何?可擴展,或開發程度如何?

j.現在用戶群如何?可通過google trends來找答案

綜上所述,我們怎樣選擇CMS做二次開發.當然還有諸合目前本身團隊的水平等等因素要想進去,希望決策者不要失誤,以免將來損失慘重.

不管是二次開發,還是自己全部重新設計,我們都得要有一個大前提,那就是最大化提高系統平台生命周期,國內很多phper開發者,很多項目的生命周期短得可憐,閱其代碼堅酸難懂,接手的開發人員像被強姦的感覺, 筆者認為合格的PHP程式設計師應把代碼看成是一種藝術, 一個好不好的操作平台是否擁有良好的可擴展性,布局,可維護性是其根本的基礎.其核心框架必需高度抽象化,有良好的命名空間與對象接口, 這樣才能算是進入貴族藝術編程世界.

一個項目的成功不是決定於技術的先進度如何,它有很多因素決定.在此,筆者就不在這裡談論如何運作網路商業,只談PHP極限編程藝術世界.

PHP之旅

Standard PHP Library(PHP標準庫,PHP5以後編譯後自帶的框架)為解決一些在Web開發中普遍的問題，提供了一系列的接口(interface)和類庫(classes)的。這些所有類庫,你都可以在PHP編譯本中找到(ext\SPL下的資料夾),基類檔案在SPL.PHP等檔案內,SPL提供了疊代器(Iterator)、數組對象(ArrayObject)、運行期違例(RuntimeException InvalidArgumentException……)、觀察者模式(Observer Pattern)等一些解決方案。詳情可參考官方的API.

查看命令

查看SPL所有類與方法,我們可以用以下語句:　print_r(spl_classes());

我會詳細說明此這10大接口的設計理念.PHP所有編程萬變不離其宗.

SPL有以下接口(10大接口)

1.ArrayAccess 其功能是使類可以像PHP中的數組一樣操作。有點類似於.net平台的index操作。

2.Traversable 是Zend引擎的內置接口，它是能讓類用於foreach語句的接口，但是在PHP中並不能直接實現Traversable。只能間接地通過Iterator或IteratorAggregate接口實現。

3.IteratorAggregate(繼承Traversable,是他的兒子)是除Iterator之外另一個從Traversable接口中繼承而來的。其接口也很簡單，只有一個函式。就是返回一個疊代器實例

4.Iterator(也是繼承Traversable,是他的兒子)，SPL中大部分接口和類都是從這個接口繼承而來的。

5.RecursiveIterator (繼承Iterator,為Traversable的孫子)，遞歸疊代器，通過hasChildren()和getChildren()兩個函式實現遞歸遍歷子元素。

6.Countable 這接口就一個count()函式，返回結果集的數量。實現這個接口的類可以用count()函式查詢其結果集。

7.Serializable 該接口實現序列化和反序列化的接口。在沒有SPL之前，可以通過__sleep() 和__wakeup()實現相同的功能，若同時實現了Serializable 接口和_sleep() 和__wakeup()，則只有Serializable接口的函式啟作用。

8.SplObserver Observer觀察者模式的中的觀察者。

9.SplSubject Observer觀察者模式的中的發布者。

10.OuterIterator 它的實現者可以包含一個或多個疊代器成員，即可以通過getInnerIterator()接口函式獲取內部的疊代器，也可以直接通過類本身實現的Iterator接口遍歷內部的疊代器數據。這在SPL是一個非常重要的接口，SPL中很多內置的疊代器實現了這個接口。

(接口分析未完成,更新中...)

SPL中已經聲明的類。

1.DirectoryIterator 這個類用來查看一個目錄中的所有檔案和子目錄

2.FilterIterator 這是一個抽象類，它實現了OuterIterator接口。它包裝一個已有的疊代器類，通過抽象方法accept()過濾掉不需要的內容，形成一個新的疊代器。

3.LimitIterator 這也是一個實現OuterIterator的類。它有點類似於SQL中的LIMIT語句。它通過包裝一個已有疊代器，然後截取其中某一段數據形成一個新的疊代器。

4.RecursiveDirectoryIterator 遞歸查看一個目錄中的所有檔案的子目錄。

5.SimpleXMLIterator 一個遍歷XML內容的類

6.IteratorIterator 實現對疊代器的包裝，這也是SPL中對OuterIterator默認實現。

7.InfiniteIterator 從字面意思就知道，這是個無限循環的疊代器，當next()到達最後時，會自動調用rewind()函式，又從頭開始。

8.AppendIterator 它實現了對一系統疊代器的包裝，並且可以在運行過程中添加新的疊代器。

9.SplFileObject 檔案操作類，可以按行的方式遍歷檔案內容。同時還能獲取檔案的大小及其它詳細信息。

10.SplFileInfo 獲取檔案信息類。SplFileObject 從該類繼承。

錯誤處理是一大塊:

下面來我講講PHP->SPL 關於錯誤處理方面的架構:

Exception 這是錯誤處理的接口,這是個值得一提,在所有程式中都會用到的父類.

筆者也想不通，為什麼作者不作Exception做為一個接口呢???我得想想.

下面分為兩大基類

一個是LogicException (邏輯錯誤處理類)

一個是RuntimeException(實時錯誤處理類)