如果你碰到php 方法重寫,參數(shù)不同,報(bào)錯(cuò):Declaration of should be compatible with that這種問題不防進(jìn)入?yún)⒖家幌陆鉀Q辦法吧.

上網(wǎng)搜索了一下,發(fā)現(xiàn)許多帖子基本都抄的一樣,說什么這是由于 php5.3版本后,要求繼承類必須在父類之后定義,如果父類定義在前,繼承類在后，就不會(huì)出現(xiàn)這個(gè)錯(cuò)誤,尤其是http://bugs.php.net/bug.php?id=46851上面還煞有介事的給出了正反例,代碼如下:

1. <?php 
2. // this code does trigger a strict message 
3. error_reporting( E_ALL | E_STRICT ); 
4. class cc extends c { function test() { return null; } } 
5. class c { function test( $a ) { return 1; } } 
6. $cc = new cc(); 
7. ?> 
8. <?php 
9. // this code does NOT trigger a strict message 
10. error_reporting( E_ALL | E_STRICT ); 
11. class c { function test( $a ) { return 1; } } 
12. class cc extends c { function test() { return null; } } 
13. $cc = new cc(); 
14. ?> 

并且討論了出錯(cuò)的情況多半是由于用_autoload()對(duì)類進(jìn)行自動(dòng)的include,導(dǎo)致基類的定義在后面,子類定義在前面.

我看了下自己的代碼,雖然確實(shí)也用到了autoload,但是都是顯式的先導(dǎo)入了幾個(gè)基類,并不存在這樣的情況,而且將上面的正反例子試了一下,都會(huì)出現(xiàn)E_STRICT的警告.

再看例子,代碼如下:

1. <?php 
2. abstract class A { 
3. // 方法無參數(shù) 
4. public static function foo(){ echo 'bar'; } 
5. } 
6. //開源軟件:Vevb.com 
7. abstract class B extends A { 
8. // 方法有參數(shù) 
9. public static function foo($str){ echo $str; } 
10. } 
11. ?> 

如上面的代碼,類A中的foo方法無參數(shù),類B在繼承A后重寫foo方法時(shí)加入了參數(shù),因此會(huì)產(chǎn)生一個(gè)類似下面E_STRICT級(jí)別的警告:

Strict standards: Declaration of ... should be compatible with that of

1. <?php 
2. abstract class A { 
3. // 方法無參數(shù) 
4. public static function foo(){ echo 'bar'; } 
5. } 
6.  
7. abstract class B extends A { 
8. // 方法有參數(shù) 
9. public static function foo($str = NULL){ echo $str; } 
10. } 
11. ?> 

類B在重寫foo方法時(shí)為新加入的參數(shù)指定一個(gè)默認(rèn)值即可.

真正原因:其實(shí)如果子類重寫方法的參數(shù)和基類不一樣,只要給參數(shù)個(gè)默認(rèn)值,使得編譯器認(rèn)為參數(shù)可以為空,保持重寫方法與基類方法的函數(shù)簽名相同就可以了.

經(jīng)常用JAVA的同學(xué)肯定知道,在JAVA或者C++中,重寫方法的函數(shù)簽名本應(yīng)該就和基類函數(shù)是一致的,我認(rèn)為這也是符合自然規(guī)律的,因?yàn)閛verride本來就是覆蓋的意思嘛,既然覆蓋了,那么就應(yīng)該和原函數(shù)一致,不然怎么能“蓋”的住呢~并且方法的重寫多用在重寫虛函數(shù)或者更明白的說就是重寫接口的函數(shù),如果重寫的時(shí)候函數(shù)簽名都不一致了,還要接口干嘛呢.

所以PHP的新版本中,我覺得定義這個(gè)E_STRICT的警告錯(cuò)誤是很有用處的,要提醒程序員自己的重寫方法到底對(duì)不對(duì).

最后還是鄙視一下上面那些抄來抄去的帖子,如果某個(gè)語言連基類和子類定義的順序都不能打亂,說明這個(gè)編譯器非常有問題了,顯然是bug.