最後のブログのOOの仕事としてこの記事では、主に建築や学期の第4群の設計の考え方を検討しました。
このモジュールアーキテクチャ設計
UML1
最初の仕事の主な内容は、クラス、プロパティおよびメソッドなどのクエリ機能をサポートするために特定のデータをMDJ入力フォーマットを解析し、記録することです
私はハッシュマップでそれらを整理するために、階層関係のクラスで設定属性およびオブジェクト・クラスのメソッド、UML要素の要素IDに入力され、第一解析クラスとインタフェースを解析UMLInteractionキーである、MyClassの/ MyInterfaceオブジェクト値その後、今度は、既存のMyClass / MyInterfaceインスタンスに他の要素を解決します。会合のため、IDがMyClassの中に格納するための関連assoList端末に提供されます。継承関係のために、基準点のMyClass MyClassのは、MyClassの親クラスであり、ハッシュマップは、インタフェース内のすべてのインターフェイスのレコードがMyInterfaceを継承しています。
クラスの最初のクエリを、父は親クラスのヌル再帰呼び出しのクエリーメソッドでない場合：このようなデータ構造は、メソッドのほとんどを達成するための組織は、再帰的で実現することができることができます。
また、クラスと同じ名前に対処するためには、同じ名前の異常な性質は、回数は、私はMyClassのとMyAttributeに登場する名前と他のクラスのHashMapのレコードを使用している、とクエリ時にチェック。
クラス/インタフェース内の基準設定点の父は、後でコーチング人々を改善している対象であることを言及する価値があります。私はすべてがでUMLInteractionにする必要が不透明、クロス級動作のクラス間相互に設定されたクラスを開始したいです。実際には、中に「低カップリング、セキュリティが」あまり必要ありません：データのほとんどは、親クラスがサブクラスにアクセスすることが可能です。クラスが自分を保存し、すべてのプロパティを継承し、に関連し、同じデータを複数回のストレージがある必要があります。また、これはまた、クラスによって占められるストレージ容量を増加します。
UML2
第二のジョブ処理状態図、シーケンス図、及び検査ルールを増加させます。
領域 - は、状態 - 解決遷移を解決解決stateMachine-の解析：処理状況マップについては、私は同様の組織のMyClassの方法を使用していました。状態番号は、転送の数がステートマシンはカウント関連するクラスによって達成することができる、後継者の数は幅優先アルゴリズムを必要とされる状態、現在の状態番号からの逸脱の状態に達すると判定されます。
- LifeLine-の解決メッセージの後、再び分析クエリリストMyInteractionを確立しますと同様の処理シーケンス図の場合。
3つのルールは、ジョブ難しい部分をチェックされます。多くの場合、1より大きく表示される名前がある場合には、ルール001の場合は、最後の属性数、および団体の統計のみすべての名前が表示されることができ、我々はすべての繰り返しの名前を渡して、例外をスローする必要があります。ルール002の場合は、クラス継承とインターフェイスがリング状に連続して検討する必要があります。私は、クラスとインタフェースの深さ優先アルゴリズムの継承チェーン、チェーン内の次のノードが既に存在する場合、検索を停止し、リングの継承に戻すを使用します。深さ優先アルゴリズムのためのルール003は、すべての時間と継承されたオブジェクトは、クラス/インタフェースは、オブジェクトは、オブジェクトが戻って2倍以上の数のクラス/インタフェースを表示されてい継承したときに表示されます。
階層が明確にするために、私はカプセル化されている（この関数の独立した）の最後のデータ構造および方法を実現します。
アーキテクチャの設計とOO手法の進化の理解
1）アーキテクチャ
アーキテクチャの設計の進化は、主にクラスの数の増加、低いクラスの複雑さと設計パターンの大きい使用に反映されます。
最初のユニットの終了後、私は複雑な機能分解は、クラスとクラス間のコラボレーションで、階層的に組織のクラスのことを学びました。第二ユニットは、私は、スレッドの安全性の問題を心配する必要はありませんので、作業スレッドモード、私はデザインパターンの甘さを味わってみましょうです。本来の機能を備えた新機能に起因する第3の処理装置の図は、独立して、私はより多くのカプセル化、継承を払って開始し、試してみました。データ型の多数の顔の第4群は、私はクラスや組織間のより構造化されたコラボレーションが始まったんです。
理解する2）の方法
OOシンプルである3つの原則：継承、カプセル化および多型が、実際にこれらの単語を理解するためには、実践的な練習に依存することです。
OO方法の私の理解では、前のジョブ私は内部の複雑性クラスが高い書いて以来「データ構造の機能と同様のパッケージ」として始まった、クラス間の関係が主な関係、あるいは元と同等のものを呼び出すことですC言語、クラスの外でする機能パッケージのちょうど同じ種類の考え方。私も容易にするための静的メソッドの多くを使用し、「関数呼び出しを。」
最初のユニットの最後のジョブに、デュー・プロセスは非常に複雑で、私は再帰関数派生問題に対処することを決めたので、非常に現実的な問題は、私が階層的に異なるオブジェクト整理しなければならないということである：表現、用語、要因を。この組織のプロセスでは、私は思考のこの種の「比較的単純なオブジェクトとの間のいくつかの複雑なステップのコラボレーションの分解」を学びました。
第二のエレベーターユニットは、私は慎重にコースのグループは、入力処理をデザインパターンをお勧め採用し、自分の走り書きプロデューススレッド安全性の問題を恐れ、OOの私の理解を促進するために聞かせている - スケジューラ - エレベーターアーキテクチャになりました宿題のガイドライン。このフレームワークの実装では、Iは、オブジェクト指向設計は、必ずしも最初の工程は複雑に分解されない、オブジェクト間次いで組織連携プログラム、オブジェクト設計要件のロジックを分離することであることに気づいオブジェクト間の関係の役割。
第三のユニット、第四単位、データタイプとプログラムの機能は、機能を実装する必要がありますか？何を必要とするオブジェクト」「どのようにこの事を完了するためにプログラム」宿題開始点はもはや行うものではありませんこれは、多くのですが、オブジェクト間の連携は？「私はプログラムのロジックにとのインターフェースの規定に基づいてオブジェクトを整理して、実装する必要性を認識し始めました。
進化のテストの理解と実践の
フェーズワン：ハンドメイドデータ
このフェーズでは、反例を構築し、慎重に、他の人の正規表現を読み取るために最初のユニットを含む、第一および第二の単位データのテストに自分の手で作られ、他の人のコードを含んでいます。
手作り問題のデータは非効率的で、効果的に自分自身の問題のコードを公開することはできません。
フェーズII：ブラックボックステスト
この段階では、主にデータ・ジェネレータに依存して打つために、ランダムなデータは、手続き上の問題にさらされています。利点は、データをより包括的生成することで、効率的で、不利な点は、問題は、すべてのコードに露出されないことであり、予測不可能な不正入力が適切に処理されます。
Iは、第2および第3の単位で第二段階で基本的でした。
フェーズ3：UMLテスト
この段階では正式に直接試験問題よりも多くの露出、プログラムの正しさを検証するOpenJMLすることができます。欠点は、少し不便JML書き込み用の一定の要件があるということです、そして文法OpenJML。
フェーズIV、ユニットテスト
よりターゲットを絞ったブラックボックス、組織の透明度に比べて、一度使用。枝の場合、コードの完全なカバレッジを確保するために正しいです。
コースの収穫
- コードの最適化のスタイル
- アーキテクチャの設計は、異なるレベルより明確です
- オブジェクト指向の設計プロセスのアイデアを開始
- 自己学習プログラムツール
- マルチスレッドプログラミングとデバッグ
- 理解し、標準化された設計に参加
gitのヒント- 自動テストツール、単体テスト
コース
1）
時には強いが、合併の爆撃それは修理修正しました。（おそらく当然のことながら、より基本的なエラーをした）を測定し、さらに強力なポイントの評価基準を改善することを推奨し、または増加した強度測定データは、ランダムに設定されます。
2）
セミナー実際の貧しい経験と高速/一般的な何かを学ぶために話して学生を共有し、このユニットのパフォーマンスは非常に良いではない場合となかった、小さな観客のフィードバック、人々は乾燥品を服用しないと感じた場合は、軽蔑されますサインアップしてみろ。
総合的な経験：「彼らは生き生きしている、と私は何もありません。」
私たちは、セミナーの既存のパターンを変更したいです。
3）
勧告は、より洗練されたPPT作り、教育コンテンツを強化します。今（コメントの欠如）の概念を重ねるようなコースウェアビットは、一般的に実際の読みやすさは、感情と雇用の関係は大きくありません。さらに、第4群（特に第4群）における第三のユニット、理論的なコンテンツのジョブクラス内容と少し離しておきます。