みなさん こんばんは。
今回はAbstract Factoryパターンについて書いていきます。
Abstract Factoryパターンは1つのFactoryクラスに複数のFactoryメソッドを持たせ、
主に実装環境に依存するような場合などに利用されます。
Abstract Factoryパターンの古典的な例として、WindowsやMacintoshなど、
複数のルック&フィールドのユーザインターフェースをまとめて切り替えるような例で使われたりします。
グループ化されたオブジェクト単位で切り替える場合に利用されるパターンがAbstract Factoryパターンと言えるでしょうか。
では簡単な例を見てみましょう。
// Abstract Factory基底インターフェース
public interface AbstractFactory {
public Product1 createProduct1();
public Product2 createProduct2();
}
// 製品基底インターフェース1
public interface Product1 {
public void sayHello();
}
// 製品基底インターフェース2
public interface Product2 {
public void goodNight();
}
// 製品実装クラス1
public class ConcreateProduct1 implements Product1 {
public void sayHell(){
System.out.println("こんにちは。こちらが製品1になります。");
}
}
// 製品実装クラス2
public class ConcreateProduct2 implements Product2 {
public void goodNight(){
System.out.println("こんばんは。こちらが製品2になります。");
}
}
// AbstractFactory実装クラス
public class ConcreateFactory implements AbstractFactory {
public Product1 createProduct1() {
return new ConcreateProduct1();
}
public Product2 createProduct2() {
return new ConcreateProduct2();
}
}
// クライアントクラス
public class Client {
public static void main(String args[]) {
AbstractFactory factory = new ConcreateFactory();
Product1 p1 = factory.createProduct1();
Product2 p2 = factory.createProduct2();
p1.sayHello();
p2.goodNight();
}
}
クラス図の通り実装してみました。
Abstract Factoryクラスの利点は、新たな(ファクトリ用の)サブクラスを容易に追加できる点に
あると思います。
人気ブログランキングへ
2016年9月6日火曜日
2016年9月5日月曜日
Factory Methodパターン
みなさん、こんばんは。
前回はもっとも簡単なSimple Factoryパターンを案内しましたが、
今回のFactory MethodパターンはSimple Factoryパターンを拡張した内容と言えるでしょうか。
Factory Methodパターンはそのオブジェクトを生成するかを各サブクラスに決定させる抽象クラスを定義します。
言葉での前置きよりさっそく実例を見ていきましょうか。
以下はクラス図になります。
では、どういう場合にFactory Methodを使うべきでしょうか?
考えられる状況として
・これはSimple Factoryパターンにも言えますが、
生成すべきオブジェクトのクラスが予測できない場合。
・生成すべきオブジェクトをサブクラスによって特定する場合。
・どのクラスのオブジェクトを生成すべきかに関する知識を局所化したい場合。
デメリットとしては、生成するオブジェクトが増えるごとにファクトリーメソッドを持ったクラスが増えてしまうことではないでしょうか。
その問題もDIコンテナを導入することで解決出来ますが、DIコンテナが考えられた背景を学ぶのは損ではないと思います。
人気ブログランキングへ
前回はもっとも簡単なSimple Factoryパターンを案内しましたが、
今回のFactory MethodパターンはSimple Factoryパターンを拡張した内容と言えるでしょうか。
Factory Methodパターンはそのオブジェクトを生成するかを各サブクラスに決定させる抽象クラスを定義します。
言葉での前置きよりさっそく実例を見ていきましょうか。
以下はクラス図になります。
ソースコードで実装するとこんな感じでしょうか。
// Factory Method抽象クラス
public abstract class Creator {
public abstract Product factoryMethod();
}
// Factory Method具象クラス
public class ConcreteCreator extends Creator {
public Product factoryMethod(){
return new ConcreteProduct();
}
}
// 製品抽象クラス
public abstract class Product {
public abstract void hell();
}
// 製品具象クラス
public class ConcreateProduct extends Product {
public void hello() {
System.out.println("Hello World");
}}
// メインクラス
public class FactoryMethodMain {
public static void main(String args[]) {
// 引数args[0]には「ConcreateCreator」が設定されていること
Creator creator = Class.forName(args[0]).newInstance();
Product product = creator.factoryMethod();
product.hello();
}
}
では、どういう場合にFactory Methodを使うべきでしょうか?
考えられる状況として
・これはSimple Factoryパターンにも言えますが、
生成すべきオブジェクトのクラスが予測できない場合。
・生成すべきオブジェクトをサブクラスによって特定する場合。
・どのクラスのオブジェクトを生成すべきかに関する知識を局所化したい場合。
デメリットとしては、生成するオブジェクトが増えるごとにファクトリーメソッドを持ったクラスが増えてしまうことではないでしょうか。
その問題もDIコンテナを導入することで解決出来ますが、DIコンテナが考えられた背景を学ぶのは損ではないと思います。
人気ブログランキングへ
2016年9月4日日曜日
Simple Factoryパターン
システム開発を行う上での問題はいかに結合度を低くするかにあるでしょう。
デザインパターンでは様々な生成に関するパターンが作られてきました。
そこで今回はSimple Factoryパターンを見ていきましょう。
このパターンは、与えられたデータに基づいて、
複数の可能なクラスの中の1つのクラスのインスタンスを返します。
Simple Factoryを理解するために、まずはソースを見て下さい。
クラスXFactoryは、引数で渡される値に基づいて、
これらのサブクラスのどちらのインスタンスを返すべきか判断します。
ここでは、メソッドgetClass()がそうです。このメソッドは何らかの値を引数で受け取り、
その値に基づいてクラスXの何らかの(XYもしくはXZの)インスタンスを返すのです。
クラスXYならびにXZは同じ(実装内容が異なりますが)メソッドdo_X()を持っているため、
どちらのクラスのインスタンスを返すべきかは、完全にFactoryクラス(ここではXFactory)
に任されるのです。
以上がSimple Factoryパターンの基本原理です。
どのクラスのインスタンスを返すべきかを判断して返す「抽象」を作るわけです。
返されたインスタンスに対しては、それが実際にどのサブクラスに属するかを意識することなく
メソッドを呼び出せます。個々のクラスの具体的はメソッドに依存することがなくなります。
DIコンテナ全盛の中で生成に関するパターンを学ぶ必要があるのかと言われたりもしますが、
プログラムの結合度を減らすために何故その技術が出来たのかの経緯を知るためには
必要であると感じました。
人気ブログランキングへ
デザインパターンでは様々な生成に関するパターンが作られてきました。
そこで今回はSimple Factoryパターンを見ていきましょう。
このパターンは、与えられたデータに基づいて、
複数の可能なクラスの中の1つのクラスのインスタンスを返します。
Simple Factoryを理解するために、まずはソースを見て下さい。
// 基底クラス
abstract class X { abstract public void do_X();}
// サブクラス
public class XY extends X {
public void do_X() {
int i = 5;
}
}
// サブクラス
public class XZ extends X {
public void do_X {
int i = 6;
}
}
// 引数で渡される値に基づいて、どちらかのサブクラスのインスタンスを返します。
public class XFactory {
public X getClass(int index) {
if ( index == 1) {
return new XY();
} else {
return new XZ();
}
}
}
// テストクラスこのソースは、Xは基底クラスで、XYとXZはXのサブクラスになっています。
public class TEST {
public static void main(String args[]) {
int index = 1;
XFactory factory = new XFactory();
X x = factory.getClass(index);
x.do_X();
}
}
クラスXFactoryは、引数で渡される値に基づいて、
これらのサブクラスのどちらのインスタンスを返すべきか判断します。
ここでは、メソッドgetClass()がそうです。このメソッドは何らかの値を引数で受け取り、
その値に基づいてクラスXの何らかの(XYもしくはXZの)インスタンスを返すのです。
クラスXYならびにXZは同じ(実装内容が異なりますが)メソッドdo_X()を持っているため、
どちらのクラスのインスタンスを返すべきかは、完全にFactoryクラス(ここではXFactory)
に任されるのです。
以上がSimple Factoryパターンの基本原理です。
どのクラスのインスタンスを返すべきかを判断して返す「抽象」を作るわけです。
返されたインスタンスに対しては、それが実際にどのサブクラスに属するかを意識することなく
メソッドを呼び出せます。個々のクラスの具体的はメソッドに依存することがなくなります。
DIコンテナ全盛の中で生成に関するパターンを学ぶ必要があるのかと言われたりもしますが、
プログラムの結合度を減らすために何故その技術が出来たのかの経緯を知るためには
必要であると感じました。
人気ブログランキングへ
デザインパターンについて
突然ですが、皆さんはデザインパターンを利用してプログラミングしてますでしょうか?
自分が今まで多数のプロジェクトで他の人が書いたソースコードを見てきましたが、
これはデザインパターンを使っているなと思われるソースコードに殆ど出会ったことがありません。
そこでデザインパターンを実際にどう使えば良いのかを考えていきたいと思います。
まずどんなデザインパターンがあるか見てみましょう。
生成に関するパターン
Simple Factoryパターン
Factory Methodパターン
Abstract Factoryパターン
Singletonパターン
Builderパターン
Prototypeパターン
構造に関するパターン
Adapterパターン
Bridgeパターン
Compositeパターン
Facadeパターン
Flyweightパターン
Proxyパターン
振舞に関するパターン
Chain of Responsibilityパターン
Commandパターン
Interpreterパターン
Mediatorパターン
Mementoパターン
Observerバターン
Stateパターン
Template Methodパターン
Visitorパターン
プレゼンテーションパターン
Model-View-Controllerパターン
Front Controllerパターン
View Helperパターン
Decoratorパターン
Service to workerパターン
Composite Viewパターン
Asynchronous Pageパターン
Caching Filterパターン
Resource Poolパターン
ビジネスロジック層のパターン
Composite Entityパターン
Entity Facadeパターン
層と層の間の通信のパターン
Data Transferパターン
Data Transfer Hashパターン
データベースパターン
Data Access Objectパターン
Tuple Tableパターン
PK Block Generatorパターン
等々。。
昔の人は凄いですね。
これだけあげましたけどまだ沢山のデザインパターンがあります。
次回からはこの中からデザインパターンを見ていくことにしましょう。
人気ブログランキングへ
自分が今まで多数のプロジェクトで他の人が書いたソースコードを見てきましたが、
これはデザインパターンを使っているなと思われるソースコードに殆ど出会ったことがありません。
そこでデザインパターンを実際にどう使えば良いのかを考えていきたいと思います。
まずどんなデザインパターンがあるか見てみましょう。
生成に関するパターン
Simple Factoryパターン
Factory Methodパターン
Abstract Factoryパターン
Singletonパターン
Builderパターン
Prototypeパターン
構造に関するパターン
Adapterパターン
Bridgeパターン
Compositeパターン
Facadeパターン
Flyweightパターン
Proxyパターン
振舞に関するパターン
Chain of Responsibilityパターン
Commandパターン
Interpreterパターン
Mediatorパターン
Mementoパターン
Observerバターン
Stateパターン
Template Methodパターン
Visitorパターン
プレゼンテーションパターン
Model-View-Controllerパターン
Front Controllerパターン
View Helperパターン
Decoratorパターン
Service to workerパターン
Composite Viewパターン
Asynchronous Pageパターン
Caching Filterパターン
Resource Poolパターン
ビジネスロジック層のパターン
Composite Entityパターン
Entity Facadeパターン
層と層の間の通信のパターン
Data Transferパターン
Data Transfer Hashパターン
データベースパターン
Data Access Objectパターン
Tuple Tableパターン
PK Block Generatorパターン
等々。。
昔の人は凄いですね。
これだけあげましたけどまだ沢山のデザインパターンがあります。
次回からはこの中からデザインパターンを見ていくことにしましょう。
人気ブログランキングへ
2016年8月31日水曜日
よくjavaの開発は出来ますか?と聞かれますが
何を基準に出来ると判定されるのでしょうか?
基本文法は理解していても実際のアプリケーション開発を出来るとは言いきれないところがあります。
例えばjavaでブラウザを作れるかとかサーバーを作れる人は殆どいないと思います。
かくいう自分も本格的なブラウザやサーバーを作れるかと言われるとそこまで自信があるわけではありません。。
javaと言っても色んなジャンルがあり、とても一人では学びきれない程の量があります。
自分でざっと調べただけでもこれだけのジャンルがありました。
JavaSE
基本文法
文字列操作
クラスとインスタンス
日付操作
ファイル操作
入出力
配列
リスト
マップ
数学処理
ネットワーク
マルチスレッド
XML操作
システム
アノテーション
ジェネリクス
リフレクション
ラムダ式
JavaDoc
正規表現
JDBC
Swing
AWT
JavaFX
Webアプリケーション
Servlet
リクエスト情報
レスポンス情報
セッション
コンテキスト
デプロイディスクリプタ(web.xml)
etc
JSP
Tomcat
フレームワーク
Struts
Spring
Seasar2
JavaEE
JSF
Play
プログラミング技法
オブジェクト指向
デザインパターン
リファクタリング
テスト
JUnit
もうこの辺で止めときましょう。。
その他にもいっぱいありますし、周辺技術にデータベースなどのインフラ回り、
JavaScriptなどのフロントエンド開発などあげたらきりがありません。
逆に言えばブログに使う題材には事欠かないですね!
自分はこのブログを通じて上記の難易度の高い技術も執筆していきたいと思います。
このブログを通じて一人でも多くの開発者に質の高い情報を提供していけたらと思っ
てます。
人気ブログランキングへ
基本文法は理解していても実際のアプリケーション開発を出来るとは言いきれないところがあります。
例えばjavaでブラウザを作れるかとかサーバーを作れる人は殆どいないと思います。
かくいう自分も本格的なブラウザやサーバーを作れるかと言われるとそこまで自信があるわけではありません。。
javaと言っても色んなジャンルがあり、とても一人では学びきれない程の量があります。
自分でざっと調べただけでもこれだけのジャンルがありました。
JavaSE
基本文法
文字列操作
クラスとインスタンス
日付操作
ファイル操作
入出力
配列
リスト
マップ
数学処理
ネットワーク
マルチスレッド
XML操作
システム
アノテーション
ジェネリクス
リフレクション
ラムダ式
JavaDoc
正規表現
JDBC
Swing
AWT
JavaFX
Webアプリケーション
Servlet
リクエスト情報
レスポンス情報
セッション
コンテキスト
デプロイディスクリプタ(web.xml)
etc
JSP
Tomcat
フレームワーク
Struts
Spring
Seasar2
JavaEE
JSF
Play
プログラミング技法
オブジェクト指向
デザインパターン
リファクタリング
テスト
JUnit
もうこの辺で止めときましょう。。
その他にもいっぱいありますし、周辺技術にデータベースなどのインフラ回り、
JavaScriptなどのフロントエンド開発などあげたらきりがありません。
逆に言えばブログに使う題材には事欠かないですね!
自分はこのブログを通じて上記の難易度の高い技術も執筆していきたいと思います。
このブログを通じて一人でも多くの開発者に質の高い情報を提供していけたらと思っ
てます。
人気ブログランキングへ
2016年8月30日火曜日
はじめましてjava狂いです。
皆さん
はじめまして。
java開発好きなシステムエンジニアです。
普段は関東近辺で仕事をしています。
好きなことを仕事に出来る幸せを感じつつ日々精進しています。
このブログを開設するきっかけになったのはジョン・ソンメズ(John Z. Sonmez)氏
の書籍「SOFT SKILLS」を読み自分のいままで学んできたスキルを無料で開放することにしまし
た。今までの自分は書籍を読み、自分の中だけで消化していましたが、これからはどんどんと情報
を発信していきたいと思います。
正直、オタクな面もあり読みづらいかもしれませんが、長くお付き合いしていきたいです。
次からは技術的な内容を投稿していきます。
それではよろしくお願いします。
人気ブログランキングへ
はじめまして。
java開発好きなシステムエンジニアです。
普段は関東近辺で仕事をしています。
好きなことを仕事に出来る幸せを感じつつ日々精進しています。
このブログを開設するきっかけになったのはジョン・ソンメズ(John Z. Sonmez)氏
の書籍「SOFT SKILLS」を読み自分のいままで学んできたスキルを無料で開放することにしまし
た。今までの自分は書籍を読み、自分の中だけで消化していましたが、これからはどんどんと情報
を発信していきたいと思います。
正直、オタクな面もあり読みづらいかもしれませんが、長くお付き合いしていきたいです。
次からは技術的な内容を投稿していきます。
それではよろしくお願いします。
人気ブログランキングへ
登録:
投稿 (Atom)

