ここで言う「入力」とは、送られてくるフォームデータのことです。
ＰＨＰの場合はすでにグローバルな配列（$_GET $_POST $_REQUEST）にセットされて食べやすい状態にされています。
が、データを受け取って処理を行うにはめちゃめちゃ食べやすい状態にしておかないといけません。
[食品汚染を取り除く]
こちらで処理を行う時の文字コードになっているか
バイナリコードのような不純物が混入してないか
前後空白のトリミングが必要か
以上のようなことを処理しておくようにコンストラクタに書いておけばあとはオブジェクトを作成した時点でデータがめちゃめちゃ食べやすい状態になっているということになります。
その他、オブジェクト作成時に自動的に処理できていたら後のコーディングの手間が省けそうなものがいろいろ考えられます。
[後のコーディングが楽になりそうなもの]
セッションを使った処理か（ユーザ側か管理者側か）（ユーザ設定値の読み込みなど）
テンプレートをどれに指定するか配色をどのタイプにするかなどの情報取得
以上のような処理をコンストラクタに書いておけばあとはオブジェクト作成時のパラメータで必要な処理を指定できるようにすることで便利になりそうです。
■コンストラクタ記述例（inc_std.php）
class std
{
var $data;
var $opt;
function std($opt=array())
{
//オブジェクト作成時のオプションをセット
foreach ($opt as $key=>$value) $this->opt[$key]= $value;
//食べやすくする
foreach ($_REQUEST as $key=>$value){
if (is_array($value))
foreach ($value as $key2=>$value2)
$this->data[$key][$key2]= strtr(mb_convert_encoding(preg_replace('/[\x00-\x08\x0b\x0c\x0e-\x1f\x7f\xff]/', "", $value2), "EUC-JP", "SJIS,EUC-JP,UTF-8,JIS"), array("\x0d\x0a"=>"\n", "\x0d"=>"\n", "\x0a"=>"\n"));
else $this->data[$key]= strtr(mb_convert_encoding(preg_replace('/[\x00-\x08\x0b\x0c\x0e-\x1f\x7f\xff]/', "", $value), "EUC-JP", "SJIS,EUC-JP,UTF-8,JIS"), array("\x0d\x0a"=>"\n", "\x0d"=>"\n", "\x0a"=>"\n"));
}
//セッションモードなら
if (!empty($this->opt['session'])){
//ここにセッション処理を
}
//アップロードあれば
if (!empty($this->opt['upload'])){
//ここにアップロード処理を
}
}
}
?>
■オブジェクト作成例
$obj= new std;
//コンストラクタでセッション開始
$obj= new std(array('session'=>1));
//コンストラクタでアップロード処理をさせる
$obj= new std(array('session'=>0, 'upload'=>1));
std($opt=array())のようにしてデフォルトで空の配列を代入しないとオブジェクト作成側でなにも渡さなかったときエラーになります。
コンストラクタで受け取ったオプションはコンストラクタ終了と同時に消滅してしまうので外側の空間に退避させておきます。
こうすることでオブジェクト作成後も他の関数を呼んだときに値参照ができることになります。
$_GET、$_POST、$_COOKIEの値をすべてまとめて持っている$_REQUESTを使用しましたが、中にはこの$_REQUESTを使うとセキュリティの面から言って危険だとか言う人（解説本のたぐい）もいます。
具体的にどう危険かを指摘していなくてただ危険だから使うなとだけ書いてるものがあったりします。これこそが危険です。
確かに$_GETに思いもかけない値がセットされてくることがあるかも知れません。
が、それは$_POSTも$_COOKIEも同じことです。どうとでも送ろうと思えば送ることができてしまいます。
したがって肝心なことはこちら側の処理上どうしても困る送り方があるなら個別にオブジェクト作成側で
if (isset($_GET['hoge'])) die("エラー終了");
などとやればいいだけです。