Differences between revisions 1 and 2

Guiceが生成するクラスについてのコンストラクタをできる限り隠せ

以下のシンプルなインターフェースを考えてみよう。

public interface DataReader {
 
  Data readData(DataSource dataSource);
}

このインターフェースを以下のようなpublicクラスで実装するのが普通である。

public class DatabaseDataReader implements DataReader {
  
   private final ConnectionManager connectionManager;

   @Inject
   public DatabaseDataReader(
      ConnectionManager connectionManager) {
     this.connectionManager = connectionManager;
   }

   @Override
   public Data readData(DataSource dataSource) {
      // ... read data from the database
      return Data.of(readInData, someMetaData);
   }
}

特に問題はないように見える。 Unfortunately, such an inspection excludes the dimension of time and the inevitability of an unguarded code base to become more tightly coupled within itself over time.

深夜をまたぐと何も良いことは起こらない（訳注：？）という古い格言と同様、コンストラクタをpublicにすることは良いことではない。 publicコンストラクタはコードベース内での不法な使用につながる。これらは必然的に以下をもたらす。

リファクタリングを難しくする。
インターフェース/実装間のバリアを破壊する。
コードベースとのタイトな結合をもたらす。

最も悪いことは、コンストラクタの直接的な使用はGuiceのオブジェクトインスタンス化を回避してしまうことだ。

これを正すには、単純に実装クラスとコンストラクタのビジビリティを変更することである。通常は、双方をパッケージprivateとすることである。これにより、

モジュールと同じパッケージのクラスをバインドするようにする。
unit testing the class through means of direct instantiation

簡単で思い出しやすい例として、publicと@Injectはエルフとドワーフに例えることができる。彼らは一緒に働くが、しかし理想的な世界では、独立して存在すべきなのである（訳注？）。

-Deletions are marked like this.
+Additions are marked like this.
 Line 32:
-Similar to the old axiom, Nothing good happens after midnight, we also know that Nothing good happens after making a constructor public: A public constructor will have illicit uses introduced within a code base. These uses necessarily will:
+深夜をまたぐと何も良いことは起こらない（訳注：？）という古い格言と同様、コンストラクタをpublicにすることは良いことではない。

publicコンストラクタはコードベース内での不法な使用につながる。

これらは必然的に以下をもたらす。
-Line 34:
+Line 36:
-    * make refactoring more difficult.

    * break the interface-implementation abstraction barrier.

    * introduce tighter coupling within a codebase.
+ * リファクタリングを難しくする。

 * インターフェース/実装間のバリアを破壊する。

 * コードベースとのタイトな結合をもたらす。
-Line 38:
+Line 40:
-Perhaps worst of all, any direct use of a constructor circumvents Guice's object instantiation.
+最も悪いことは、コンストラクタの直接的な使用はGuiceのオブジェクトインスタンス化を回避してしまうことだ。
-Line 40:
+Line 42:
-As a correction, simply limit the visibility of both your implementation classes, and their constructors. Typically package private is preferred for both, as this facilitates:
+これを正すには、単純に実装クラスとコンストラクタのビジビリティを変更することである。

通常は、双方をパッケージprivateとすることである。これにより、
-Line 42:
+Line 45:
-    * binding the class within a Module in the same package
+    * モジュールと同じパッケージのクラスをバインドするようにする。
-Line 45:
+Line 48:
-As a simple, mnemonic remember that public and @Inject are like Elves and Dwarfs: they can work together, but in an ideal world, they would coexist independently.
+簡単で思い出しやすい例として、publicと@Injectはエルフとドワーフに例えることができる。

彼らは一緒に働くが、しかし理想的な世界では、独立して存在すべきなのである（訳注？）。

Diff for "guice/Manual/BestPractices/KeepConstructorsHidden"

Guiceが生成するクラスについてのコンストラクタをできる限り隠せ