私は約 12 人の開発チームで働いており、厳密に社内のみで使用する適切な API セットを構築しています。通常、すべてのクラスとインターフェイスは public です。API のコンシューマ (内部ではあるが) がファクトリを使用する必要があるように、いくつかのコンストラクタを内部にすることの価値をよく考えてきました。
これはあなたとあなたのチームが実践していることですか?
これは単体テストにどのように影響しますか? ファクトリを介してクラスを単体テストしても問題ないと思いますか、または PrivateObject のようなものを介してコンストラクターにアクセスしますか?
答えはイエスです。私の現在のプロジェクトには、まさに 1 人の開発者 (私) が取り組んでいますが、必要に応じて、より複雑なデザイン パターンと共に、可視性やその他のアクセス修飾子を使用しています。理由は次のとおりです。
コンパイラは、それを許せば、優れた設計パターンを適用するための最高のツールの 1 つになる可能性があります。プログラム実行中の通常の状態がオブジェクト指向に相当するオブジェクトを維持しなければならない場合、すべてを公開すると、将来的に多くの頭痛の種になる可能性があります。彼の子供たちから、電気会社が彼の重要な臓器を突っついて、彼らがやりたいことをやらせるまで、彼を知っています。別の手を追加したり、1 つを削除したりすると、患者は心停止に陥る可能性があります。
コードは自己文書化する必要があります。内部としてマークされているクラスまたはクラス メンバーは、おそらくそうであるべきであることを意味します。すべてが公開されている場合、オブジェクトとやり取りするときに触れてはいけないものがあるかどうかわかりません。繰り返しになりますが、患者が手術台に座っていると、突然新しい人が入ってきて、肝臓をつかみ、「ねえ、これは何をするの？」と言います。物体は握手をし、何かをするように言われ、それをするために放す必要があり、肝臓の機能は彼ら以外には関係ありません.
コードは後世の人が保守できる必要があります。これは最初の 2 つのルールに関連していますが、基本的には、誰かがコードベースを開いて入り口を見つけ、基本的な実行フローをトレースしながら、途中で使用されるオブジェクトを調べて、それらの一般的な形式と機能を決定できる必要があります。 . 手術台にいる患者の話に戻ります。たとえば、5 年後に誰かがこのシーンに現れたとしましょう。50人の男が腹の中にいるテーブルで男が割って開いた。それは、彼がこれまでに見たような礼儀正しい社会的慣習のようには見えません。それはおそらく儀式的な人身御供のように見えるだろうし、そのような状況に遭遇したとき、ほとんどの人は最初の本能は逃げることだ.
ただし、コインの裏側は、それ自体のために実装されたデザインパターンは、一般的に非常に悪いことです。大学を卒業して最初の仕事に就いたら、誰もあなたが Strategy パターンを実装する方法を知っているかどうかなど気にしません。すべてのパターンには、それが適用される一連の状況があります。もしあなたが医者だったら、次に入ってきた患者に血管形成術を行いますか?