[CleanCode] -11. システム

💁🏻‍♂️ この章では、より高い抽象レベル、すなわちシステムレベルで清潔に保つ方法について説明します.
1.システムの作成と使用を分ける
作成は使用とは異なります.준비 과정と런타임 로직を分けます.
つまり、객체 생성と객체 사용を分けるべきです.

public Service getService() {
    if (service == null)
        service = new MyServiceImpl(...); // 모든 상황에 적합한 기본값일까?
    return service;
}

発生した問題

遅延初期化を使用すると、特定のタイプに依存するため、

をテストすることは困難である.

MyServiceImplは、すべての状況に適しているかどうか分かりません.
システム的で堅牢なシステムを構築したい場合は、モジュール性を破るためによく使われる簡単な方法ではありません.
主な依存性を解消する方法が必要です.

Main取り外し

工場

これは、両方が最終的にオブジェクトの作成と使用を分離することを意味します.

依存注入
使用と製作を分離する強力なメカニズムの一つは依存性を注入することである.
制御反転技術を依存性管理のメカニズムに応用する.
Control Stationでは、1つのオブジェクトが負う補助責任(オブジェクトの作成)がすべて新しいオブジェクトに転嫁されます.

依存性注入方法

ジェネレータ

フィールド

方法

2.拡張
成長するかどうかの期待から、ザグマン村で6車線を開通する費用を合理化することはできない.
同様に,ソフトウェアでは,最初からシステムを正しく作成できると信じていたのは迷信である.
逆に,今日与えられたユーザストーリに基づいてシステムを実装しなければならない.
明日は新しいストーリーに合わせてシステムを調整して拡張すればいい.
->これは漸進的な愛子の日方式を繰り返す核心である.
Kent Backの実装モデルでは,プログラミングにおいて追求される価値を紹介する.
不必要な複雑なモードは、不確定な将来の拡張をもたらします.
横断的な注目点
理論的には永続性やログのような独立した形式であるが,観点向けのプログラミング(AOP)を用いることが望ましい.AOPは,関心事項の横断に対応し,モジュール性を確保するための一般的な方法論である.
たとえば、javaエージェント、純java AOPフレームワーク、AspectJは、あまり理解していませんが.
永続性に関連する部分をクライアントとモジュール化して分離し、既存の機能を維持しながら拡張
プロキシモード
スポークスマン
実際のオブジェクトを直接使用するのではなく、仮想オブジェクトに宣言します.
実際のオブジェクトの機能と付加機能を使用して機能フローを制御する設計モード.
https://bamdule.tistory.com/154
例または説明を参照して、最終的にWrapperクラスとしてプロキシクラスを使用します.
間接アクセスマスタークラス(subject)の典型的なパターンのように見えます
ツールを利用した庇護の概念を見た後、SWIFTのPropertyWrapperを思い出し、AOPと同じように検索しました.
に示すように、属性Wrapperまたはターゲット-Cメソッドを使用してAOPをサポートできます.
残念ながら、SWIFTでProperty Wrapperを使ってAOPを真似->テクノロジーをメソッドに適用できません
Objective-CのDynamic Dispatchを使用してSWIFTからメソッドインタフェースを取得
SWIFTでは、
3.テスト主導システムアーキテクチャの構築
建築士は、物理構造が一旦構築されると重大な変更が困難になるため、BDDUF(実施前にすべての事項を設計する方法)を採用している.
しかし,ソフトウェアが観点を効果的に分離できれば劇的に変化する可能性がある.
異なる領域は、その領域コードに最も影響を及ぼす観点または類似のツールを用いて統合される.
この構造は、コードのようにテスト主導技術を適用することもできる.
4.システムはドメイン専用言語を必要とする
良いDSLはドメイン概念とその概念を実現するコードの間に存在する「コミュニケーションギャップ」を減少させる.
ドメイン専門家が使用する言語を使用してドメインロジックを実装すると、ドメインを誤って実装する可能性が低下する.
適切に使用される場合、DSLは抽象レベルをコード寛容または設計モードに昇格させる.
したがって,開発者はコード意図を適切な抽象レベルで表現することができる.
DSL:特定のカテゴリの言語
SWIFTは、自動レイアウト用のスナップそうちを提供する
n/a.結論
(コードと同じ)システムもきれいなはずです.
すべての抽象段階で意図を明確に表現しなければならない.
そのため、観点や観点と同様のメカニズムを採用し、各実施の注目点を分離しなければならない.