クラスデザイン：何が良いですか？

投稿者： Denis Tsyplakov 、ソリューションアーキテクト、DataArt



何年もの間、プログラマーは時々同じ間違いを繰り返すことを発見しました。 残念ながら、開発の理論的側面に関する本はそれらを回避するのに役立ちません。通常、本には具体的で実用的なアドバイスがありません。 そして、私も理由を推測します...



たとえば、 ロギングやクラス設計に関して最初に頭に浮かぶ推奨事項は非常に単純です。 しかし、経験では、それだけでは十分ではないことが示されています。 この場合のクラスの設計は良い例です-誰もがこの質問を独自の方法で見るという事実から生じる永遠の頭痛。 したがって、基本的なヒントを1つの記事にまとめることで、多くの典型的な問題を回避し、最も重要なこととして、同僚をそこから救うことにしました。 いくつかの原則があなたにとって平凡に思える場合（それらは本当に平凡だからです！）-それで、それらはすでにあなたの皮質下に落ち着いており、あなたのチームは祝福されます。



私は予約をします。実際、単純化のためだけにクラスに焦点を当てます。 アプリケーションの機能やその他の構成要素についてもほぼ同じことが言えます。

アプリケーションが機能してタスクを実行する場合、その設計は良好です。 かどうか？ アプリケーションの目的関数に依存します。 展示会で一度表示する必要があるモバイルアプリケーションに非常に適しているものは、銀行が長年開発している取引プラットフォームには適さない可能性があります。 ある程度まで、この質問に対する答えはSOLID原則と呼ぶことができますが、それはあまりにも一般的です-同僚との会話で参照できる、より具体的な指示が必要です。

対象アプリケーション

普遍的な答えはないので、範囲を狭めることを提案します。 HTTPまたは別のインターフェイスを介して要求を受け入れ、それらの上にいくつかのロジックを実装し、チェーン内の次のサービスに要求を行うか、受信したデータをどこかに格納する標準のビジネスアプリケーションを作成しているとします。 簡単にするために、Spring IoCフレームワークを使用していると仮定します。これは現在非常に一般的であり、残りのフレームワークはかなり似ているためです。 そのようなアプリケーションについて何を言えますか？

• プロセッサが1つのリクエストの処理に費やす時間は重要ですが、重要ではありません-天候が0.1％増加してもそうではありません。
• テラバイトのメモリを自由に使用することはできませんが、アプリケーションがさらに50〜100キロバイトを使用する場合、これは災害にはなりません。
• もちろん、開始時間が短いほど良いです。 ただし、6秒と5.9秒の間に根本的な違いはありません。

最適化基準

この場合、私たちにとって何が重要ですか？



プロジェクトコードは、ビジネスで数年、おそらく10年以上使用される可能性があります。



コードは、互いになじみのない複数の開発者によって数回修正されます。

数年後には、開発者が新しいLibXYZライブラリまたはFrABCフレームワークを使用したくなる可能性があります。



ある時点で、コードの一部またはプロジェクト全体を別のプロジェクトのコードベースとマージできます。



マネージャーの中で、そのような問題はドキュメントの助けを借りて解決されることが一般的に受け入れられています。 もちろん、ドキュメントは便利で便利です。プロジェクトで作業を開始すると、5枚のオープンチケットがかかっているので、プロジェクトマネージャーから進捗状況を尋ねられ、約150冊を読んで（覚えて）ください。優秀な作家からはほど遠い文章のページ。 もちろん、プロジェクトに注ぐのに数日、あるいは数週間もありましたが、単純な算術演算を使用する場合は、一方で5,000,000バイトのコード、もう一方では、たとえば50労働時間です。 平均すると、1時間あたり100 KBのコードを挿入する必要がありました。 そして、ここではすべてがコードの品質に大きく依存します。 きれいな場合：組み立てが簡単で、適切に構造化され、予測可能である場合、プロジェクトに注ぐことは、それほど苦痛の少ないプロセスのようです。 これで最後の役割は、クラスの設計ではありません。 最後から遠い。

クラスのデザインから欲しいもの

上記のすべてから、一般的なアーキテクチャ、技術スタック、開発プロセスなどについて多くの興味深い結論を引き出すことができます。しかし、最初からクラス設計について話すことにしました。それに関して先に述べたことから学べる有用なことを見てみましょう。

• アプリケーションコードに完全に精通していない開発者がクラスを見て、このクラスの機能を理解できるようにしたいと思います。 そしてその逆-機能的または非機能的要件を見ると、アプリケーションがそれを担当するクラスのどこにあるのかすぐに推測できました。 さて、要件の実装はアプリケーション全体に「広がる」のではなく、1つのクラスまたはクラスのコンパクトなグループに集中することが望ましいです。 どういうアンチパターンなのか、例を挙げて説明しましょう。 特定のタイプの10のリクエストが、アカウントに20ポイント以上あるユーザーのみが実行できることを確認する必要があるとします（それが何であれ）。 このような要件を実装するための悪い方法は、各リクエストの先頭にチェックを挿入することです。 その後、ロジックは異なるコントローラーで10のメソッドに分散されます。 良い方法は、フィルターまたはWebRequestInterceptorを作成し、すべてを1か所でチェックすることです。
• クラスコントラクトに影響を与えない1つのクラスの変更が、他のクラスに影響を及ぼさないようにするか、実際に影響を与えないようにします。 言い換えれば、クラスコントラクトの実装をカプセル化します。
• クラスコントラクトを変更するときに、呼び出しのチェーンをたどって検索を使用することで、この変更が影響するクラスを見つけることができるようにしたいと思います。 つまり、クラスに間接的な依存関係がないようにします。
• 可能であれば、いくつかの単一レベルのステップで構成されるクエリ処理プロセスが、いくつかのクラスのコードによって塗りつぶされることはなく、同じレベルで記述されることを確認したいと思います。 このような処理プロセスを記述するコードが、明確な名前を持つ1つのメソッド内の1つの画面に収まる場合、非常に便利です。 たとえば、行内のすべての単語を検索し、単語ごとにサードパーティサービスを呼び出し、単語の説明を取得し、説明に書式を適用して、結果をデータベースに保存する必要があります。 これは、4つのステップからなる一連のアクションです。 これらの手順が次々に実行されるメソッドがある場合、コードを理解し、そのロジックを変更すると非常に便利です。
• コード内の同じものを同じ方法で実装したいのです。 たとえば、コントローラーからデータベースにすぐにアクセスする場合は、どこでもアクセスする方が良いでしょう（ただし、このような設計を良い方法とは呼びません）。 また、サービスとリポジトリのレベルをすでに入力している場合は、コントローラーから直接データベースに接続しないことをお勧めします。
• 機能的および非機能的要件に直接責任を負わないクラス/インターフェースの数がそれほど多くないことを望みます。 ロジックを備えた各クラスに2つのインターフェイス（5つのクラスからの継承の複雑な階層、クラスファクトリと抽象クラスファクトリ）があるプロジェクトでの作業は非常に困難です。

実用的な推奨事項

希望を定式化して、目標を達成するための具体的な手順を概説できます。

静的メソッド

ウォームアップとして、比較的単純なルールから始めます。 使用するライブラリのいずれかの操作に必要でない限り、静的メソッドを作成しないでください（たとえば、データ型のシリアライザーを作成する必要があります）。



原則として、静的メソッドを使用しても問題はありません。 メソッドの動作がそのパラメータに完全に依存している場合、実際に静的にしないのはなぜですか。 ただし、アプリケーションのコンポーネントをバインドするSpring IoCを使用するという事実を考慮する必要があります。 Spring IoCは、Bean（Bean）とそのスコープ（Scope）の概念を扱います。 このアプローチは、クラスにグループ化された静的メソッドと組み合わせることができますが、このアプリケーションを理解し、その中の何かを変更することさえできます（たとえば、メソッドまたはクラスにグローバルパラメーターを渡す必要がある場合）。



同時に、IoCビンと比較した静的メソッドは、メソッド呼び出しの速度において非常にわずかな利点をもたらします。 そしてこれで、おそらく利点が終わります。



異なるクラス間で多数の超高速呼び出しを必要とするビジネス機能を構築していない場合は、静的メソッドを使用しない方が良いでしょう。



ここで、読者は「しかし、StringUtilsクラスとIOUtilsクラスはどうなのか？」と尋ねるかもしれません。実際、Javaの世界には伝統があります。 しかし、この伝統は私にはむしろ苔むしたようです。 もちろん、それに従えば、大きな害は予想されません。すべてのJavaプログラマーが慣れています。 しかし、そのような儀式的な行動には意味がありません。 一方では、StringUtils Beanを作成し、他方では、Beanおよびすべての補助メソッドを静的にしないのであれば、静的な傘クラスStockTradingUtilsおよびBlockChainUtilsをすでに作成しましょう。 静的メソッドにロジックを配置し始めて、境界線を描いて停止するのは困難です。 始めないでください。



最後に、Java 11では、開発者をプロジェクト間で何十年もさまよっていた多くのヘルパーメソッドが、標準ライブラリの一部になるか、たとえばGoogle Guavaのライブラリにマージされたことを忘れないでください。

アトミックでコンパクトなクラス契約

すべてのソフトウェアシステムの開発に適用される簡単なルールがあります。 任意のクラスを見ると、長い発掘調査に頼ることなく、このクラスが何をするのかを迅速かつコンパクトに説明できるはずです。 説明を1つの段落に収めることが不可能な場合（ただし、必ずしも1つの文で表現されるとは限りません）、このクラスをいくつかのアトミッククラスに分けて考える価値があるかもしれません。 たとえば、「ディスク上のテキストファイルを検索し、それぞれの文字Zの数をカウントする」クラス-「ディスク上の検索」+「文字の数をカウントする」分解の良い候補です。



一方、それぞれが1つのアクション用に設計されたクラスを小さくしすぎないでください。 しかし、クラスはどのサイズにする必要がありますか？ 基本的なルールは次のとおりです。

• 理想的には、クラスコントラクトがビジネス機能（または要件の配置方法に応じてサブ機能）の説明と一致する場合。 これは常に可能であるとは限りません。このルールを順守しようとすると、面倒で非自明なコードが作成される場合、クラスを小さな部分に分割することをお勧めします。
• クラス契約の品質を評価するための優れたメトリックは、契約の複雑さに対する固有の複雑さの比率です。 たとえば、非常に優れた（とはいえ素晴らしい）クラスコントラクトは次のようになります：「このクラスには、入力時にロシア語で主題の説明を含む行を受け取り、結果として特定のトピックのストーリーを作成するメソッドが1つあります。 ここでは、契約はシンプルで一般的に理解されています。 その実装は非常に複雑ですが、複雑さはクラス内に隠されています。

このルールが重要なのはなぜですか？

• まず、各クラスが何をするのかを自分自身に明確に説明する能力は常に役立ちます。 残念ながら、すべてのプロジェクト開発者がこれを行うことはできません。 「よく、これはPathクラスのラッパーです。何らかの理由でPathの代わりに使用しました。 彼女には、すべてのFile.separatorパスを2倍にできるメソッドもあります。レポートをクラウドに保存するときにこのメソッドが必要であり、何らかの理由でPathクラスになりました。
• 人間の脳は、5〜10個までのオブジェクトを同時に操作できます。 ほとんどの人は7人以下です。 したがって、開発者が問題を解決するために7つ以上のオブジェクトを操作する必要がある場合、何かを逃すか、1つの論理的な「傘」の下に複数のオブジェクトを詰め込まなければなりません。 まだ梱包する必要がある場合は、すぐに意識して、この傘に意味のある名前と明確な契約を与えてください。

すべてが十分にきめ細かであることを確認する方法は？ 同僚に5分（5分）与えるよう頼んでください。 現在作業中のアプリケーションの一部を担います。 各クラスについて、このクラスが正確に何をするかを同僚に説明します。 5分以内に収まらない場合、またはこのクラスが必要な理由を同僚が理解できない場合は、おそらく何かを変更する必要があります。 まあ、または変更せずに、別の同僚と実験をやり直してください。

クラスの依存関係

ZIPアーカイブにパックされたPDFファイルのリンクされたテキストセクションを100バイトより長く選択し、それらをデータベースに保存する必要があるとします。 このような場合の一般的なアンチパターンは次のようになります。

• ZIPアーカイブを開き、その中のPDFファイルを探してInputStreamとして返すクラスがあります。
• このクラスには、テキストのPDF段落を検索するクラスへのリンクがあります。
• 次に、PDFで機能するクラスには、データベースにデータを保存するクラスへのリンクがあります。

一方では、すべてが論理的に見えます。チェーン内の次のクラスと直接呼ばれる受信データ。 ただし、同時に、チェーンの最上位にあるクラスのコントラクトは、その背後にあるチェーンに含まれるすべてのクラスのコントラクトと依存関係に混在します。 これらのクラスをアトミックかつ相互に独立させ、これら3つのクラスを相互に接続して処理ロジックを実際に実装する別のクラスを作成する方がはるかに正確です。



それをしない方法：







ここで何が間違っていますか？ ZIPファイルを処理するクラスは、PDFを処理するクラスにデータを渡し、次に、データベースを処理するクラスにデータを渡します。 これは、結果として、何らかの理由でZIPで機能するクラスがデータベースで機能するクラスに依存することを意味します。 さらに、処理ロジックは3つのクラスに分散しているため、それを理解するには、3つのクラスすべてを調べる必要があります。 REST呼び出しを介してサードパーティのサービスに渡すためにPDFから取得したテキストの段落が必要な場合はどうなりますか？ PDFで動作するクラスを変更する必要があります。また、その中でRESTを使用する必要があります。



方法：







ここには4つのクラスがあります。

• ZIPアーカイブでのみ動作し、PDFファイルのリストを返すクラス（ファイルを返すのは悪い-ファイルは大きく、アプリケーションを壊すでしょう。しかし、この場合の広い意味での「戻り」という言葉を読んでみましょう。例えば、InputStreamからStreamを返します）
• 2番目のクラスは、PDFの操作を担当します。
• 3番目のクラスは、データベースに段落を保存する以外、何もできません。
• そして、文字通り数行のコードで構成される4番目のクラスには、1つの画面に収まるすべてのビジネスロジックが含まれています。

2019年のJavaには少なくとも2つの良い点があることを強調します

良い）ファイルとすべての段落の完全なリストをメモリ内のオブジェクトとして転送しない方法。 これは：

1. Java Stream API
2. コールバック つまり、ビジネス関数を含むクラスはデータを直接転送しませんが、ZIP Extractorを使用します：ここにコールバックがあります。ZIPファイルでPDFファイルを探し、各ファイルのInputStreamを作成し、転送されたコールバックを呼び出します。

暗黙の動作

以前は誰も解決していなかったまったく新しい問題を解決しようとせず、他の開発者がすでに数百（または数十万）回行ったことがある場合、チームメンバー全員がソリューションの循環的な複雑さとリソース集約性に一定の期待を抱いている。 たとえば、ファイル内で文字zで始まるすべての単語を検索する必要がある場合、これはディスクからブロック単位でファイルを1回だけ連続して読み取ることです。 つまり、 https：//gist.github.com/jboner/2841832に焦点を合わせた場合、そのような操作には1 MBあたり数マイクロ秒かかります。おそらく、プログラミング環境とシステム負荷によっては、数十または100マイクロ秒にもなりますが、一秒でもありません。 数十キロバイトのメモリが必要になり（結果をどうするかという質問は省きます。これは別のクラスの関心事です）、コードはおそらく1画面程度かかります。 同時に、他のシステムリソースが使用されないことが予想されます。 つまり、コードはスレッドを作成せず、データをディスクに書き込み、ネットワークを介してパケットを送信し、データベースにデータを保存しません。



これはメソッド呼び出しの通常の期待です：

zWordFinder.findZWords(inputStream). ...
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

たとえば、単語をzではなくzに分類するなど、何らかの理由でクラスのコードがこれらの要件を満たしていない場合、毎回RESTメソッドを呼び出す必要があります（これが必要な理由はわかりませんが、これを想像してみましょう）クラスコントラクトには非常に慎重に記述する必要があります。また、メソッドの名前が、参照するメソッドがどこかで実行されていることを示している場合は非常に便利です。



暗黙的な動作の合理的な理由がない場合は、クラスを書き換えます。



メソッドの複雑さとリソース集約度への期待を理解する方法は？ 次の簡単な方法のいずれかに頼る必要があります。

1. 経験を積むと、かなり広い視野が広がります。
2. 同僚に尋ねる-これはいつでもできます。
3. 開発を開始する前に、チームメンバーと実装計画について話し合います。
4. 次の質問を自問してください。「しかし、この方法では冗長なリソースを使いすぎないのですか？」通常、これで十分です。

最適化にも関与する必要はありません。クラス100,000で使用するときに100バイトを節約しても、ほとんどのアプリケーションではあまり意味がありません。



このルールは、「エンジニアリングに10 GBを必要とするアプリケーションで10バイトのメモリを節約するために1か月を費やすべきではない」などの質問に対する答えを隠し、オーバーエンジニアリングの豊かな世界への窓を開きます。 しかし、ここではこのトピックを作成しません。 彼女は別の記事に値します。

暗黙的なメソッド名

Javaプログラミングでは、現在、クラス名とその動作に関する暗黙的な規則がいくつかあります。 それらの多くはありませんが、それらを壊さない方が良いです。 私の頭に浮かぶものをリストしてみます：

• コンストラクター-クラスのインスタンスを作成し、かなり分岐したデータ構造を作成できますが、データベースで動作せず、ディスクに書き込みをせず、ネットワークを介してデータを送信しません（組み込みのロガーはこれをすべて実行できますが、これは別の話ですいずれにせよ、それはロギング設定者の良心にあります）。
• Getter-getSomething（）-オブジェクトの深さから何らかのメモリ構造を返します。 繰り返しますが、ディスクへの書き込み、複雑な計算の実行、ネットワークを介したデータの送信、データベースとの連携は行いません（遅延ORMフィールドである場合を除き、これは遅延フィールドを細心の注意を払って使用する理由の1つです） 。
• Setter-setSomething（何か）-データ構造の値を設定し、複雑な計算を行わず、ネットワーク経由でデータを送信せず、データベースで動作しません。 通常、セッターは、重要なコンピューティングリソースの暗黙的な動作や消費を想定していません。
• equals（）およびhashcode（）-データ構造のサイズに線形に依存する量での単純な計算と比較を除いて、何も期待されていません。 つまり、3つのプリミティブフィールドのオブジェクトに対してハッシュコードを呼び出すと、N * 3の単純な計算命令が実行されることが予想されます。
• toSomething（）-このメソッドは、あるデータ型を別のデータ型に変換し、変換には構造体のサイズに匹敵するメモリ量と、構造体のサイズに線形に依存するプロセッサ時間のみが必要であると予想されます。 型変換は常に線形に実行できるとは限らないことに注意してください。たとえば、ピクセル画像をSVG形式に変換することは非常に簡単なアクションになる可能性がありますが、この場合はメソッドに別の名前を付ける方が適切です。 たとえば、computeAndConvertToSVG（）という名前はやや厄介に見えますが、内部で重要な計算が行われていることがすぐにわかります。

例を挙げましょう。 私は最近、アプリケーション監査を行いました。 作業のロジックにより、コード内のどこかのアプリケーションがRabbitMQキューをサブスクライブすることがわかります。 私はコードを歩いています-この場所が見つかりません。 私はウサギへのアピールを直接探しており、登り始めています。サブスクリプションが実際に行われるビジネスフローの場所に行きます-私は誓います。 コードでの表示：

1. service.getQueueListener（tickerName）メソッドが呼び出されます-返された結果は無視されます。 これは警告するかもしれませんが、メソッドの結果が無視されるようなコードは、アプリケーション内の唯一のコードではありません。
2. 内部では、tickerNameのnullがチェックされ、別のgetQueueListenerByName（tickerName）メソッドが呼び出されます。
3. その中で、QueueListenerクラスのインスタンスは、ティッカーの名前によってハッシュから取得され（そうでない場合は作成されます）、getSubscription（）メソッドが呼び出されます。
4. そして今、getSubscription（）メソッド内で、サブスクリプションが実際に行われます。 そして、それは3画面のサイズのメソッドの途中で発生します。

率直に言って-チェーン全体を実行せず、注意深い数十のコード画面を読むことなく、サブスクリプションがどこにあるかを推測することは非現実的でした。 メソッドがsubscribeToQueueByTicker（tickerName）と呼ばれた場合、時間を大幅に節約できます。

ユーティリティクラス

「Design Patterns：Elements of Reusable Object-Oriented Software（1994）」という素晴らしい本がありますが、これは多くの場合、GOF（作者の数では4人のギャング）と呼ばれています。 この本の有用性は、主に、さまざまな国の開発者にクラスデザインテンプレートを記述するための単一の言語を提供したという事実にあります。 現在、「クラスは1つのインスタンスにのみ存在し、静的アクセスポイントを持っていることが保証されている」の代わりに、「シングルトン」と言うことができます。 同じ本は、脆弱な心に顕著な損害を引き起こしました。 この害は、フォーラム「同僚、Webストアを作成する必要があり、どのテンプレートから始める必要があるかを教えてください」の1つからの引用でよく説明されています。 言い換えれば、一部のプログラマーは設計パターンを乱用する傾向があり、1つのクラスで管理できる場合はいつでも、「柔軟性を高めるため」に5つまたは6つを一度に作成します。



抽象クラスファクトリ（またはインターフェイスよりも複雑な別のパターン）が必要かどうかを判断する方法 いくつかの簡単な考慮事項があります。

1. Springでアプリケーションを作成している場合、99％の時間は必要ありません。 Springは、より高いレベルのビルディングブロックを提供します。 役に立つと思われる最大値は、抽象クラスです。
2. ポイント1でもまだ明確な答えが得られない場合は、各テンプレートがアプリケーションの複雑さを+1000ポイント示していることに注意してください。 テンプレートを使用するメリットが、その害を上回るかどうかを慎重に分析します。 メタファーに目を向けると、それぞれの薬が治癒するだけでなく、わずかに害を与えることを忘れないでください。 すべての薬を一度に飲まないでください。

不要な方法の良い例は、 こちらをご覧ください 。

おわりに

要約すると、最も基本的な推奨事項がリストされていることに注意してください。 私はそれらを記事の形で作成することさえしません-それらはとても明白です。 しかし、過去1年間で、これらの推奨事項の多くが違反されているアプリケーションに頻繁に出くわしました。 読みやすく保守しやすいシンプルなコードを書きましょう。