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

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

代碼如下:

<?php

// this code does trigger a strict message

error_reporting( E_ALL | E_STRICT );

class cc extends c { function test() { return null; } }

class c { function test( $a ) { return 1; } }

$cc = new cc();

?>

< ?php

// this code does NOT trigger a strict message

error_reporting( E_ALL | E_STRICT );

class c { function test( $a ) { return 1; } }

class cc extends c { function test() { return null; } }

$cc = new cc();

?>

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

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

再看例子

代碼如下:

<?php

abstract class A {

// 方法無(wú)參數(shù)

public static function foo(){ echo 'bar'; }

}

abstract class B extends A {

// 方法有參數(shù)

public static function foo($str){ echo $str; }

}

?>

閃電似的

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

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

代碼如下:

<?php

abstract class A {

// 方法無(wú)參數(shù)

public static function foo(){ echo 'bar'; }

}

abstract class B extends A {

// 方法有參數(shù)

public static function foo($str = NULL){ echo $str; }

}

?>

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

真正原因：

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

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

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

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

更多信息請(qǐng)查看IT技術(shù)專(zhuān)欄