SOLIDの原則を使用する場合、開発者の発見可能性は問題ですか？

他のすべての開発者が基本的なCRUDアプリを実行することに慣れているか、かわいらしい/機能的なインターフェイスを作成することに専念している基幹業務アプリを実行しており、次のことをたくさん得ています。

「私たちがそれを行うために使用する方法で、従業員はあなたが従業員に対しておそらくできるすべてのことをするでしょう。」そしてそれは本当でした。その1つの「クラス」には数千行のコードがあり、従業員に対して実行できることは何でもありました。または、さらに悪いことに、従業員データのテーブルがあり、各開発者がイベントハンドラーで実行したいことを実行する方法を見つけました。

そのアプローチのすべての悪い点は真実でしたが、少なくとも従業員を使用する開発者は、他のドキュメントに行かなくても、従業員をヘルスプランに登録し、昇給、解雇、雇用、異動などを行う方法を見つけることができました。マネージャーと他のすべての主要なアイデア。または、従業員が他の必要なデータテーブルを使用している場合は、必要なことを実行できます。

はい、多くの重複したコードがありました。はい、それは非常に壊れやすいコードでした。はい、テストは必要以上に困難でした。はい、機能の変更は恐怖を誘発するものであり、コピーペーストはそのアプローチにより当然のことでした。

しかし、少なくとも1つのクラスを作成することで何が利用可能であるかを発見したり、インターフェイス、抽象クラス、具象クラスなどの違いを理解しなくても、必要なことを実行したりできます。 intellisenseによって返されるメソッド、またはデータが存在するテーブルを知っているメソッド。

googled / bingedやyahoo！dも行っていますが、この問題の確認はありません。

だから問題はないかもしれないし、何か足りないだけなのかもしれない。実際の動作やデザインに対応していない開発者が、外部ドキュメントを参照したり、さまざまなコンポーネントのクラス名をスキャンしたりせずに、何かを行う方法を簡単に発見できるソリューションを理解しようと頭を悩ませました/それが動作するように聞こえるものを見つけるためのプロジェクト。

私が思いつくことができた唯一のものは、より良い名前がないために、これらを持っていることです、「Table of Content Class」は実際のクラスを返すだけで何もしません（そして実際にそれらのほとんどはインターフェースですがそれらは他の開発者が希望する実際のタスクを実行するために使用できる違いまたは注意さえも知っています。まだ本当に大きなクラスになってしまいますが、それらにはほとんど振る舞いがありません。

SOLIDの実際の実装が行われる中間層の詳細な知識を必要としないより良い方法はありますか？

基本的に私が求めているのは、CRUDタイプの開発者が非常に複雑なシステムのCRUD開発者であり続けることを可能にする方法があるかどうかです。

あなたが説明したこと（つまり、従業員で実行できるすべての可能なコードを持つEmployeeクラス）は、私が個人的にかなり多く見た非常に一般的なパターンであるようです。私がよく知る前に自分で書いたコードの一部。

管理可能な一連のメソッドを使用して単一のエンティティを表すことになっているクラスから始まるものは、各機能と各リリースが同じクラスにますます追加するため、維持するのが悪夢のようなものに変化します。これは、クラスを一度記述して、何度も変更したいという衝動に抵抗する必要があるというSOLIDの原則に反します。

しばらく前に（他の人が宣伝したデザインパターンやSOLIDを発見する前に）、次のプロジェクトで物事を少し変えることを決めました。2つの非常に大きなプラットフォーム間のインターフェースとして機能するサーバーで作業していました。最初は構成の同期のみが必要でしたが、これが他の多くの機能にとって論理的な場所であることがわかりました。

したがって、メソッドを公開するクラスを作成する代わりに、メソッドを表すクラスを作成しました（GoFから「コマンド」パターンであることが判明しました）。クライアントのために作業を行う代わりに、私のすべてのメインアプリケーションクラスは永続的な状態ホルダーになり、長さがはるかに短くなりました。サービス自体に新しいインターフェイスメソッドを追加する必要があるたびに、すべてを開始するExecute（）メソッドを持つ新しいクラスを単に作成します。複数のコマンドに共通点がある場合、それらは共通の基本クラスから派生しました。最終的には、70以上の異なるコマンドクラスがあり、プロジェクト全体はまだ非常に管理しやすく、実際に取り組むことができました。

あなたの「TOCクラス」は私がやったことからそれほど遠くない。コマンドのインスタンス化を担当する抽象ファクトリー（GoF）がありました。ファクトリクラス内では、詳細のほとんどを基本クラスとATLスタイルマクロの背後に隠しました。そのため、プログラマーがリクエストを追加または検索する必要がある場合、そこに行って見たのは次のとおりです。

BEGIN_COMMAND_MAP()
    COMMAND_ENTRY( CChangeDeviceState )
    COMMAND_ENTRY( CSetConfiguration )
    ....
END_COMMAND_MAP()

別の方法として（またはそれに加えて）、実際のすべてのコマンドクラスを個別の名前空間に配置して、コーディングを行っているときに何かを実行する必要がある場合は、名前空間名を入力するだけで、Intellisenseは定義したすべてのコマンドを一覧表示します。次に、各コマンドには、どの入出力パラメーターを正確に決定するすべてのget get / setメソッドが含まれます。

また、Facade（GoF）パターンの使用についても調べることができます。1000以上のクラスをCRUDエンジニアに公開する代わりに。それらすべてを、必要なものだけを公開する単一のクラスの後ろに隠します。私は依然として各「アクション」を独自のクラスにすることに固執しますが、Facadeクラスには、各アクションをインスタンス化するメソッドを含めることができ、Intellisenseを使用すると、利用可能なものがすぐに表示されます。または、Facadeに実際のメソッドを持たせますが、内部でコマンドをインスタンス化し、キューに入れて、応答を待ちます。次に、通常のメソッド呼び出しが行われたかのように戻ります。

（*）多くの詳細を知りたくはありませんでしたが、実際には "Command"および "CommandHandler"クラスのセットがありました。これにより、in / outパラメータの管理/キューイング/シリアル化の責任が、これらのコマンドを実際に「処理」したクラスから分離されました。

問題になる可能性があります。特に物事をひどく名づける場合。しかし、複雑なクラスに頼らずに、いくつかの解決策があります。メソッドが多すぎるクラスは、Intellisenseでナビゲートするのも同様に困難です。

問題を単純化するために、名前空間（C＃）またはパッケージ（Java）、または言語が持つ類似の概念（すべてを名前空間と呼びます）を使用してみてください。

会社名から始めます。これにより、Intellisenseは自分で作成した名前空間のみに制限されます。次に、複数のアプリケーションがある場合は、名前空間の2番目の部分を使用してそれらを分割します。アプリケーション全体に存在するもののために、Core名前空間を含めます。次に、機能のタイプに分類します。等々。

これを正しく行うと、非常に発見可能なアイテムができあがります。

例として、ユーザー検証が必要な場合は、「MyCo」と入力します。アプリケーションの名前空間のリストが表示されます。ユーザーデータベースはすべてのアプリで使用されているので、「Core」と入力します。次に、機能のタイプのリストを取得します。それらの1つは「検証」であるため、それは明らかな選択のようです。そして、Validation内には、すべての機能を備えた「UserValidator」があります。

たまたま、私が頻繁に使用するものについては、名前、または少なくとも規則をすぐに思い出します。検証ルールに多くの変更を加えるため、すべての検証クラスがFooValidatorと呼ばれることがわかります。Fooはテーブルの名前です。したがって、実際には名前空間を走査する必要はありません。UserValidatorと入力して、残りの作業をIDEに実行させます。

しかし、思い出せないものについては、それを見つけるのはまだかなり簡単です。また、名前空間のプレフィックスを削除することもできます。

それらを基本的に「CRUD」開発者と呼ぶので、あなたは彼らが非常に良いとは思わないと仮定します。これが彼らがあなたのビジネスドメインを理解していないことを意味するかどうかはわかりません。彼らがドメインを理解していれば、クラスは彼らにとって理にかなっているはずです。いくつかのクラスが構築されていることを知っているので、最初に見て、2番目に尋ね、3番目のオプションとしてゼロから構築することを検討する必要があります。

クラスを見るだけでクラスの使用/再利用の方法を自動的に知る方法を知ることは、初めてではありません。文書化する必要があり、場合によってはトレーニングを通じて、またはコードレビュー中に追加の説明を提供する必要があります。

多くのAPIとオープンソースプロジェクトは、ドキュメント、コード例、その他の説明を提供しています。あなたはユーザーフレンドリーである必要はないかもしれませんが、それを回避する方法はありません。それらをよく教えなさい。