私は手作りのフレームワーク/ライブラリ（セッション、DB、キャッシュ、設定タイプのクラス）とセクションのフォルダを含む "modules"フォルダを含む "library"フォルダを持つアプリケーションに取り組んでいます依存性注入の代わりにコアPHPクラスを拡張しますか？
ほとんどの私のモジュール（ブログ、フォーラムなど）では、キャッシュ、データベース、ロガー、設定オブジェクトのような複数のオブジェクトが必要になります。私はこれに依存性注入を使用することを計画していましたが、私は興味があります、私はデータベース、キャッシュ、ロガー、時間、メソッドのようなものを行うことができるコアクラス/オブジェクトを持っていないだけで、モジュールクラスを作成し、それらを注入する必要なしにこれらすべてのものにアクセスできますか？
私はクラス/オブジェクトを使い慣れていないので、私はここにいるかもしれません。説明してください。
クラスにはsingle responsibilityが必要です。キャッシング、dbアクセス、ログと時刻などを行うCoreクラスは、実質的にはGod Objectという別名The Blobです。それはAntiPatternです。それをしないでください。それらをSOLIDにする。
がクラスを特化している場合は、拡張クラスが意味を持ちます。は、を拡張します。
拡張子が基本クラスの本来の目的とは何の関係もない場合、それは意味をなさず、通常は乱雑になります。
はたとえば、DbMySqlクラス（特殊）とDbBaseクラスを拡張することができる、またはHtml5Helper（拡張子）とHtmlHelper。
DbClassをProductsModuleに拡張しないでください。どちらもお互いに関係ありません。 ProductsModuleは本質的にデータベースにバインドされていないため、お互いに関係のない責任が混在しています。
CANは、必要なオブジェクトをインスタンス化して提供するFactoryクラスを作成しています。何かのように：
$db = myFactory::getDBO();
$conf = myFactory::getConfig();
$session = myFactory::getSession();
など。
また、私はゴードンに同意します。
個人的に私はFactory静的メソッドのアプローチを避けます。本質的には、グローバル変数の使用と同じです。それはサービスロケータの反パターンです。
提案されているDIコンテナに加えて、私は貴重なアプローチであるために手動依存注入（DIコンテナを使用）を行っています。クラスを疎結合するように設計できるツール（コンテナ）はありません。手動DIを使用すると、それに重点を置くと便利です。
[P.S.私はこれをコメントとして追加しましたが、私は新しくコメントできません]
DI容器がより適しています。 http://components.symfony-project.org/dependency-injection/ – Gordon
@Gordonこれは私の言うことです。 Joomlaのフレームワークでは、このサービスを提供するFactoryクラスです... JFactoryとも呼ばれます:) –