学習過程
Springframework 6.0.8 の学習には 4 か月近くかかり、ようやく終了しました。主な学習内容は図（赤枠）のとおりです。
この研究では、SF アプリケーションの初期化プロセスを軸として、Beans、Context、Core、SpEL (フレームワークから完全に独立しており、詳細な検討はありません)、AOP のコア モジュールに主に焦点を当て、Spring の理解を深めています。コアテクノロジーの依存関係注入、イベント、リソース、i18n、検証、データバインディング、型変換、SpEL、AOP。
学習方法のまとめ
1. 主にアプリケーション追跡方法を採用します。つまり、最も単純なアプリケーションを作成し、アプリケーション コンテナの ClassPathApplicationContext の初期化を開始点として使用して、初期化プロセス全体 (コンテナの初期化、リソースのロード、Bean 定義のロード、および Bean の初期化) を追跡します。同時に、初期化プロセスをさまざまなテクノロジと組み合わせます。クリックして開始し、特定のテクノロジの実装方法をフォローアップします。個人的には、この手法の最も効果的な点は、フレームワークの理解に役立つ実装と結果の検証であると考えています。
2. 学習プロセス中にソース コードを見るだけでは十分ではなく、次のことも行う必要があります:
2.1 UML ツールを使用してクラス図を描画し、関連するポイントの全体的な印象を確立しやすくします。
2.2 実行プロセスとジャンプ関係を明確にするために、主要なプロセスのタイミング図を描きます。
2.3 文書またはブログの形式でメモを取ります。特に、ソース コード内の 1 行ごとのコメントは、フレームワークを理解するのに非常に役立ちます。
2.4 2.1 ～ 2.3 で行ったことを何度も読んで修正します。
2.5 永続性: ソース コードを読むのは、最初は非常に不快です。連続的なジャンプが迷路に入り込んでいるように見えます。永続性だけが問題を解決できます。
Springframeworkの理解のまとめ
1. Springframework は 6.0.8 まで開発されており、クラス数からもわかるようにシステムの複雑度は非常に高くなります。 Beans: 313 クラス Context: 517 クラス
Core
:
634 クラス
SpEL: 110 クラス
AOP: 203 クラス
2. Spring は依存関係生成機能を提供しており、そのフレームワーク自体も依存関係の生成、つまりインターフェイスを優先することを主張しています。その具体的な利点は次のとおりです。
2.1 インターフェイス ファースト。これは、フレームワークが拡張機能を提供するための基本メカニズムです。フレーム自体の拡張機能をサポートしている間は、拡張機能によってアプリケーションがフレーム機能に介入したり、フレーム機能を使用したりすることはできない場合があります。
2.2 マーク付きインターフェイスの使用: マーク付きインターフェイスとは、メソッドを持たず、高度な抽象化で特定のタイプのもののみを表すインターフェイスを指します。たとえば、Aware インターフェイスは典型的なマーク インターフェイスであり、アプリケーションが特定のアプリケーション メソッド (ApplicationContextAware、EnvironmentAware、ResourceLoaderAware、MessageSourceAware など) を認識 (取得) する能力を表します。 2.3 インターフェイスは多重継承の問題を解決します。 : アプリケーション実行環境としてのアプリケーション コンテナ (ApplicationContext) など
、以下の図に示すように、インターフェイスを通じて統合できるさまざまなものを含める必要があります。
3. 深いクラス継承レベル: 5 つ以上のレベルを持つのが一般的で、9 つ以上のレベル (インターフェイスを含む) を持つことも珍しくありません。この利点は、OOD 原則との整合性が高く、変更や拡張が簡単であることですが、欠点は、プログラムの複雑さが大幅に増加することです。一般的な読み取りの障害は、継承階層の途中にあるメソッドの実装が抽象または空のメソッド本体であり、特定の実装が子孫クラスにあることです。この場合、実装メソッド本体を手動で見つける必要があります。画像の例は次のとおりです。
4. Spring によって提供される拡張メカニズムは、フレームワーク自体でも拡張のために使用されます。たとえば、Bean のインスタンス化および初期化プロセスには多くの拡張ポイントがあります。アプリケーションはこれらの拡張ポイントを使用してフレームワークの機能を活用できるだけでなく、フレームワーク自体もこの方法で使用されます。たとえば、BeanDefinition の解析実装では、 、標準の名前空間 (Bean) 解析がデフォルトであり、非標準の名前空間 (context、aop など) はカスタマイズされた入り口です。異なる要素の入り口は、異なる解析実装に対応します。たとえば、context:annotation-config および context:component -scan は異なる実装に対応しており、前者はパーサー AnnotationConfigBeanDefinitionParser に対応し、後者はパーサー ComponentScanBeanDefinitionParser に対応します。もちろん、この利点は、拡張メカニズムが非常にエレガントに実装されることですが、難点は、プログラムの可読性が大幅に低下することです。読者は、トレースしてデバッグしないと正しいパーサーを見つけることさえできない可能性があります。画像の例は次のとおりです。
学習効果
フレームワークのソースコードを体系的に読むことで、以下の能力が向上します。
1. 応用問題を解決する能力：フレームワークの理解が深まるとともに、フレームワークに基づいて応用問題を解決する能力が向上します。
2. 設計能力の向上: フレームワークの実装を学習し、その背後にある設計理由を探ることで、アプリケーション システムを設計および再構築する能力を向上させることができます。
3. 優れたコーディング スタイルを学びます。基本的にすべてのクラス、属性、メソッドにはコメントがあり、その中でインターフェイス コメントはより詳細です。すべてのコメントは JavaDoc 仕様に準拠しています。
4. 優れたフレームワークを学ぶことで、読者の技術的視野が広がり、業界の専門家がどのように問題を解決するかを直観的に体験できます。
この時点で、この研究は終了です。この研究では基本的に Spring フレームワークがどのように実装されているかを理解しましたが、限られた個人のエネルギーとフレームワークの複雑さのため、ソース コードの正確性については、ソース コードの約半分だけが広範囲に読まれ、わずか 4 分の 1 だけが集中的に読まれました。ご理解いただきますと、精度が 100% であることは保証できません。非常に残念だと言わざるを得ません。