Java EEのファサードのポイントは何ですか?
-
24-10-2019 - |
質問
私はまさにファサードのポイントを理解していません。
public abstract class AbstractFacade<T> {
private Class<T> entityClass;
public AbstractFacade(Class<T> entityClass) {
this.entityClass = entityClass;
}
protected abstract EntityManager getEntityManager();
public void create(T entity) {
getEntityManager().persist(entity);
}
public void edit(T entity) {
getEntityManager().merge(entity);
}
public void remove(T entity) {
getEntityManager().remove(getEntityManager().merge(entity));
}
public T find(Object id) {
return getEntityManager().find(entityClass, id);
}
public List<T> findAll() {
CriteriaQuery cq = getEntityManager().getCriteriaBuilder().createQuery();
cq.select(cq.from(entityClass));
return getEntityManager().createQuery(cq).getResultList();
}
public List<T> findRange(int[] range) {
CriteriaQuery cq = getEntityManager().getCriteriaBuilder().createQuery();
cq.select(cq.from(entityClass));
Query q = getEntityManager().createQuery(cq);
q.setMaxResults(range[1] - range[0]);
q.setFirstResult(range[0]);
return q.getResultList();
}
public int count() {
CriteriaQuery cq = getEntityManager().getCriteriaBuilder().createQuery();
Root<T> rt = cq.from(entityClass);
cq.select(getEntityManager().getCriteriaBuilder().count(rt));
Query q = getEntityManager().createQuery(cq);
return ((Long) q.getSingleResult()).intValue();
}
}
このコードを持っていて、このようなEJBがあります。
@Stateless
public class WrapSpecFacade extends AbstractFacade<WrapSpec> {
@PersistenceContext
private EntityManager em;
@Override
protected EntityManager getEntityManager() {
return em;
}
public WrapSpecFacade() {
super(WrapSpec.class);
}
}
これのポイントは何ですか?なぜこれをファサードと呼ぶのですか?私にとって、それは同様の機能をグループ化する抽象クラスです。ありがとう。
解決
ファサードはデザインパターンです。パターンであるソフトウェアパターンは、コードを整理し、特定の構造を提供するための一連のルールです。パターンを使用して、いくつかの目標に到達できます。アプリケーションを設計するときに設計パターンが使用されます。
ファサードパターンにより、プログラマーはオブジェクトのシンプルなインターフェイスを作成して他のオブジェクトを使用できます。すべてが独自のインターフェイスを実装する非常に複雑なクラスのグループを使用して作業することを検討してください。さて、あなたはあなたが持っている多くのいくつかの機能のみを公開するためのインターフェイスを提供したいと思います。そうすることで、コードのシンプルさ、柔軟性、統合、ゆるいカップリングを実現します。
あなたの例では、多くの俳優間の結合を管理するために、ファサードが使用されています。それはデザインの問題です。多くのコンポーネントが互いに相互作用している場合、それらが結び付けられるほど、それらを維持するのが難しくなります(コードメンテナンスを意味します)。ファサードを使用すると、プログラマーが常に到達しようとする目標であるゆるいカップリングに到達できます。
以下を検討してください。
public class MyClass1 implements Interface1 {
public void call1() {}
public call call2() {}
}
public class MyClass2 implements Interface2 {
public void call3() {}
public void call4() {}
}
public class MyClass {
private MyClass1 a;
private MyClass2 b;
//calling methods call1 call2 call3 and call4 in other methods of this class
...
...
}
call1またはcall2が使用するクラスにあるビジネスロジックを変更する必要がある場合...インターフェイスを変更しないことで、これらすべてのクラスを変更する必要はありませんが、インターフェイスメソッドのいずれかで使用されるメソッド内のクラスのみを変更する必要はありません。最初の2つのクラス。
ファサードを使用すると、このメカニズムを改善できます。
申し訳ありませんが、それほど素晴らしく見えないことに気付きました。設計パターンはソフトウェア業界で頻繁に使用されており、大規模なプロジェクトに取り組むときに非常に役立ちます。あなたのプロジェクトはそれほど大きくなく、それが真実かもしれないことを指摘するかもしれませんが、Java EEはビジネスおよびエンタープライズレベルのアプリケーションプログラミングを支援することを目指しています。そのため、デフォルトでファサードパターンが使用される場合があります(一部のIDEも使用します)。
他のヒント
通常、このパターンは、インターフェイスを提示している基礎となるクラスの実装を非表示にするか、複雑なものの基礎となる実装を簡素化するために使用されます。
ファサードは外の世界に単純なインターフェイスを提示する場合がありますが、フードの下では、他のクラスのインスタンスの作成、トランザクションの管理、ファイル、またはTCP/IP接続の処理など、簡素化されたインターフェイスによって保護できるすべてのものが行われます。
あなたの特定の文脈では、これは実際にはファサードではありません。そのコードにあるものは、基本的にDAO(データアクセスオブジェクト)です。
DAOはDB操作のファサードと見なすことができますが、これはその主な目的ではありません。主にDB内部を隠すつもりです。例では、基礎となるストレージシステムをXMLファイルまたはHBaseのようなキー値ストアに切り替えている場合、その「ファサード」で定義されているメソッドを使用することができ、クライアントコードに変更は必要ありません。
(従来の)ファサードは、クライアントから隠す必要がある複雑なデザインを扱います。複雑なAPIと複雑なフローを公開する代わりに(このサービスからこれを取得し、このコンバーターに渡し、結果を取得してこれを検証してからこの他のサービスに送信します)。簡単な方法をクライアントに公開します。このように、APIの使いやすいという事実に加えて、クライアントコードを壊すことなく、基礎となる(複雑な)実装を自由に変更できます。