SlideShare a Scribd company logo
1 of 71
Download to read offline
GoFデザインパターン
振る舞いに関するパターン
・Template Method
・Strategy
・Visitor
Template Methodパターン
具体的な処理をサブクラスにまかせる
○Template Methodパターンとは
・ 端的に言うと、スーパークラスの方に処理の枠組み(テンプレート)
を定め、具体的な実装をサブクラスに任せるパターンのこと。
・ GoFパターンの中でも最も基本的なパターンの1つで、
他のパターンでも多く利用されてます。
Factory MethodパターンやStrategyパターンなど。
○Template Methodパターンの構造
○Template Methodパターンの適用タイミング
・ひとつは 共通化を行いたい処理が出てきた場合。
→スーパークラスで処理の共通化を行っている為。
・もうひとつは、サブクラスで必ず実行して欲しい処理がある場合。
→Template Methodパターンの実装の仕方によって、サブクラスで
オーバーライドしなければならないメソッドを制御できる為。
※つまり、共通部分と差分部分が明確に区別でき、処理に流れが
ある場合、サブクラスで実装して欲しい処理がある場合 に、
<Template Methodパターン>の適用を考えるとよい。
○Template Methodパターンのメリット
1.処理の流れをスーパークラスに集約することで、サブクラスでの
重複した実装を排除することができる。
2.実現したい処理をわかりやすく(簡素化)することができる。
3.サブクラスではオーバーライドすべきメソッドのみを実装し、
処理内容を定義するだけで実現内容を変更できる。
○Template Methodパターンのデメリット
1.クラスの数が膨大になりやすい
Template Methodパターンに凝り過ぎると、子クラスの数が膨大になってしまうことがある。
場合によっては、if文やswitch文で処理を分岐するだけに留め、クラスの数を減らした方が、
却って分かりやすくなることがある。
2.オーバーライドを忘れがち
子クラスでオーバーライドすべき抽象メソッドに対して、親クラスでデフォルト実装があると、
新しい子クラスを作る際に、それらを適切にオーバーライドすることを忘れてしまうことがある。
新しい子クラスを作る際に、既存の子クラスをコピー&ペーストして作ってしまうと、
本当はもっとオーバーライドしないといけないメソッドがあるのに、忘れてしまうことがある。
これを防ぐために、敢えて、親クラスではデフォルト実装を用意しない場合もある。
Strategyパターン
アルゴリズムをごっそり切り替える
○Strategy パターンとは
・Strategyとは「戦略」という意味があり、プログラミングでは
「アルゴリズム」 として考えられている。
どんなプログラムでも、問題を解くために特定のアルゴリズムが
実装されている。
そのアルゴリズムを実装した部分をごっそりと交換できるようにし、
アルゴリズムを切り替えることで、同じ問題を別の方法で解くのを
容易にするのがSterategyパターン。
○Strategy パターンの構造
インターフェイスか抽象クラスで
定義
○Strategy パターンの適用タイミング
・アルゴリズムを変更もしくは追加する可能性がある
・要件によって、アルゴリズムを動的に切り替える必要がある
・クライアントとアルゴリズムの結合度を低くしたい
(独立性を高くする)
※このような場合、Strategyパターンの採用を検討してみるとよい。
○Strategy パターンのメリット
1.処理毎にまとめることができる
それぞれの処理がクラスにまとめられて実装されており、コードは処理内容専念することが
でき、これにより保守性が高まる。
また、新しい処理が追加された場合も、既存のコードに手を入れることなく、新しいクラスを
作成するだけで済む。
2.異なる処理を選択する為の条件文がなくなる。
処理がクラス単位にまとめて実装されることで、結果、if文やswitch文を使うことがなくなり、
非常にすっきりしたコードになる。
3.異なる処理を動的に切り替えることができる。
クラス単位に処理がまとめて実装されているので、クライアントは使いたいクラスのインスタンスを
オブジェクトに渡すだけで、処理を動的に切り替えることができる。
○Strategy パターンのデメリット
・アルゴリズムを組み込むことになるので、
多少、複雑な処理になりがち。(その分コストも増える)
Visitorパターン
構造を渡り歩きながら仕事をする
○Visitor パターンとは
・「Visitor」という英単語は、「訪問者」を意味する。
このパターンは、「データ構造」と「それに対する処理」を
分離することを目的とするパターンです。
そのためこのパターンを適用すると、「データ構造」を
変更することなしに、「新しい処理」を追加することができる。
・具体的には、訪問者であるVisitor役のオブジェクトが、
訪問先であるデータ構造要素の個々のオブジェクトを訪問し、
その訪問先の公開されている資源を利用して処理を実行して回る
という形になる。
○Visitor パターンの構造
処理の部分
データ構造の部分
○Visitor パターンの適用タイミング
・データの構造が複合・複雑である場合。
・振る舞いが複合・複雑である場合。
・機能を拡張する可能性がある場合。
※このような場合に、Visitorパターンを利用すると良い。
○Visitor パターンのメリット
1.クラスの部品としての独立性を高める
データ構造と操作を分離することにより、独立して開発する
ことが可能になる。
2.データ構造のクラスを変更することなく、操作側の機能を
容易に拡張できる。
○Visitor パターンのデメリット
1.Visitor未使用時(普通のデータとそれに対する処理が纏まったクラス)と比べて
コードが複雑になる。
2.訪問者側に処理を追加するのは容易だが、データ構造側に処理を
追加する場合に、訪問者の受け入れを常に考慮する必要がでてくる。
3.訪問者に処理を行ってもらうには必要な情報を公開しなければならないが、
必要以上に情報を公開してしまうとデータの隠ぺいが崩れたり、
データ構造の改良が難しくなる。
GoFデザインパターン
生成を目的とするパターン
・Singleton
・Factory Method
・Abstract Factory
Singleton
いくつ作るかを制限する
Singletonパターンとは
 Singletonパターンは、オブジェクトの生成に関連
するパターンです。
 あるクラスに対してインスタンスが1つしか存在しな
いことを保証し、 それにアクセスするためのグロー
バルな方法を提供 します。
メリット1
 Singletonパターンを適用すると、インスタンスが1
つしか生成されないことが保証されます。このため、
開発者は「一度しかnewしてはならない」といった余
計な事を考えずに済むようになります。
メリット2
 オブジェクトを生成するnewは非常に負荷のかかる処理ですので、使
いまわしが効くオブジェクトを毎回newするのはパフォーマンス上問題
です。このようにオブジェクトの生成数を制限したいときは、シングルト
ンパターンの出番です。このパターンを使えば、オブジェクトを外部から
直接生成させることを防ぐことができ、クラス自体に同時に生成できる
オブジェクトの数を管理する機能を持たせることができます。
 Singletonパターンのポイントは、「コンストラクタを
privateにしてしまう」ことです。そして、唯一のイン
スタンスをprivateな static変数として保持して
おくのです。こうすることで、そのクラスがJava仮想
マシンへロードされたときに、一度だけインスタンス
が生成されま す。そして、これ以後、インスタンスの
生成は構造上不可能になります。インスタンスの取
得には、専用のstaticメソッドを用意します。
Singletonパターンのポイント1
Singletonパターンのポイント2
 サブクラスを作られると Singleton 型を持つ他のクラスができ、その
インスタンスを作るとシングルトン性が保証されないため、class 宣言
に final 指定をする
使用例
public final class MySingleton {
// このクラスに唯一のインスタンス
private static MySingleton instance = new MySingleton();
private MySingleton() {}
// インスタンス取得メソッド
public static MySingleton getInstance() {
return instance;
}
// 以後、通常のフィールドやメソッドの宣言
...中略...
}
public class Sample {
MySingleton mySingleton = Mysingleton.getInstance();
// 以後、通常のフィールドやメソッドの宣言
…略...
}
マルチスレッドにおける注意
 マルチスレッドプログラムにおいては、シングルトンを初期化するメソッ
ドは、複数のインスタンスが生成されないよう、なんらかの形でロックの
仕組みを使わなければならない。
対応策
 複数のスレッドによってシングルトンのインスタンスが複数生
成されてしまう問題に対処するために、getInstance()
を synchronized メソッドにする(但し、性能が劣化する)。
class MySingleton {
private static MySingleton Instance;
private MySingleton() {}
// 遅延初期化
public static synchronized MySingleton getInstance() {
if (Instance == null) {
Instance = new MySingleton();
}
return Instance;
}
}
Factory Method
インスタンスを生成する工場
FactoryMethodパターンとは
• オブジェクトを生成するときのインタフェース
だけを規定して、実際どのクラスを インスタン
ス化するかはサブクラスが決めるようにする。
Factory Methodパターンは、 インスタンス
化をサブクラスに任せる。
Factory Methodパターンは、オブジェクトの生成の方法
に注目したパターンです。Factory Methodパターンとは、
その名の通り「工場」のような振る舞いをします。何を作る工
場かというと、「クラスのインスタンス」という製品を製造する
工場です。
さて、この「Factory」で生成される「オブジェクト」はどのよ
うに実装されているのかはわかりませんが、どのように実装
されていても、同様の「機能」を提供します。この同様の「機
能」を実現するために「インターフェース」を定義し、Factory
で生成されるクラスが実装を行っています。言い換えると、
Factoryで生成されるインスタンスはどのクラスのものであ
れ、同様の「機能」を持っていると言えます。
Factory Methodパターンを利用することで、オブジェクト
の利用側はどのインスタンスが返ってくるのかを知る必要が
なくなります。繰り返しになりますが、利用側が知る必要があ
るのは製品の「機能」であり、具体的にどのクラスのインスタ
ンスであるかを知る必要はありません
• オブジェクトを生成する場合、下記のように記述する
のが普通です。
• しかし、このようなオブジェクト生成方法では、十分
に満足のいく結果が得られないことがあります。 そ
こで、FactoryMethodパターンでは、オブジェクト
の生成を担うメソッド(factory method)を通して間
接的にオブジェクトを生成します。
Product product = new Product();
public Product factoryMethod(){
return new Product();
}
Factory Methodのメリット
• オブジェクトの生成処理と使用処理を分離で
きる
• オブジェクトの利用側とオブジェクトのクラス
の結びつきを低くする
オブジェクトの生成処理と使用処理を分離できる と
は
• 複数のオブジェクトを扱う場合、if文やswitch文を使ってオブジェクトの生成コードを記述し、それら
を利用するコードも同じコード内に記述してしまいがちです。こういった場合、オブジェクト生成の
コードと利用側のコードを分けておくと、後々のメンテナンスが楽になります。
• Factory Methodパターンは、「オブジェクト生成側」と「オブジェクトの利用側」を分離するパターン
です。「オブジェクト生成側」はCreatorクラスと ConcreteCreatorクラス、「オブジェクト利用側」は
クライアント側のコードがそれぞれ担います。その間をやりとりするオブジェクトが、 Productクラス
とConcreteProductクラスになります。これにより、生成側はProductクラスを返すコード、一方
の利用側はProductクラスを利用するコードを記述するだけで良くなり、それぞれの処理内容に
専念することができます。
public class FileSaverFactory {
public static FileSaver createSaver(int saveType) {
FileSaver fileSaver = null;
if (saveType == FileTypeConstants.CSV_FILE_TYPE) {
fileSaver = new CSVFileSaver();
} else if (saveType == FileTypeConstants.HTML_FILE_TYPE) {
String encoding = System.getProperty("data.encoding");
fileSaver = new HTMLFileSaver(encoding);
}
return fileSaver;
}
}
// FileSaver を利用するクライアントクラス
public class ParticipationList implements Aggregate {
public void save(int saveType) throws Exception {
// .....略 .....
// シンプルなファクトリクラスのスタティックメソッドを呼び出す
FileSaver fileSaver = FileSaverFactory.createSaver(saveType);
fileSaver.save(this);
// .....略 .....
}
}
・Factoryクラス(生成側)
・利用者側
オブジェクトの利用側とオブジェクトのクラスの結び
つきを低くする とは
• Factory Methodパターンを使用することで、オブジェクトの利用側とオ
ブジェクトの結びつきを低くする事 ができます。これは、利用側でオブ
ジェクトを直接生成しない、つまり、利用側のコードに「new クラス名」と
直接書かなくてすむ、ということを意味します。この結果、利用側とオブ
ジェクトの結びつきがゆるくなります。たとえば、生成するクラスの種類
や生成手順が変更された場合でも、ファクトリ側を手直しするだけですみ
ます。
実例
public abstract class CutPrint{
protected abstract void draw( Cuttable hanzai );
protected abstract void cut( Cuttable hanzai );
protected abstract void print( Cuttable hanzai );
public void createCutPrint(){
Wood hanzai = new Wood();
draw( hanzai );
cut( hanzai );
print( hanzai );
}
}
下線を引いている部分では、どのクラスのインスタンスが生成されるかは決定したくありませ
ん。
なぜなら、生成するインスタンスの実際の型を決めてしまうと、サブクラスで自由に生成するイ
ンスタンスの型を決定することができないからです。
createCutPointをサブクラスでオーバーライドすれば、サブクラスで自由にインスタンスの型を
決定することができますが、これでは、Template Methodの利点が失われてしまいます。
さてどうすればいいでしょう?
public abstract class CutPrint{
protected abstract void draw( Cuttable hanzai );
protected abstract void cut( Cuttable hanzai );
protected abstract void print( Cuttable hanzai );
protected Cuttable createCuttable(){
return new Wood();
}
public void createCutPrint(){
Cuttable hanzai = createCuttable();
draw( hanzai );
cut( hanzai );
print( hanzai );
}
}
これを解決する方法として、FactoryMethod パターンが与えられます。
FactoryMethod パターンでは、インスタンス生成のためのメソッドを用意します。そし
て、そのインスタンスを生成するためのメソッドを通してインスタンスの生成を行いま
す。
次のページで、実際の実装例を示します
このように、インスタンスを生成するメソッドを通して、インスタンスを生成するようにし
ておくことで、 createCuttable メソッドをオーバーライドするメソッドを記述し、 インス
タンスの型を自由に選択することができるようになります。
public class ImagawasCutPrint extends CutPrint{
protected void draw(Cuttable hanzai){
System.out.println("マンガの絵を描く");
}
protected void cut(Cuttable hanzai){
System.out.println("彫刻刀を利用して器用に彫る");
}
protected void print(Cuttable hanzai){
System.out.println("インクとして、自分の血を使いプリントする");
}
protected Cuttable createCuttable(){
return new Potato();
}
}
Factory Methodパターンの構造
Abstract Factory
関連する部品をまとめて作る工場
はじめに
「abstract factory」を直訳すると「抽象的な工場」となります。抽象的な工場・・・これは一体何な
のでしょうか?
GoFパターンの一つにFactory Methodパターンがあります。Factory Methodパターンは
製品であるオブジェクトを作る「工場」を用意するパターンです。ここで見ていくAbstract Factory
パターンも同様にオブジェクトを生成するパターンの1つで、関連し合うオブジェクトの集まり、つまり
部品の集まりを生成します。
ここで、「抽象的な」というところがポイントです。この工場は「抽象的」な工場で、生成される部品も
「抽象的」なものになります。
オブジェクト指向プログラミングでは、「物を抽象化する」ということが重要なポイントとなります。つ
まり、具体的な物を直接扱うのではなく、「具体的な物を抽象化した物」を扱うということです。
Abstract Factoryパターンは、具体的なクラスを明確にすることなく、関連し合うオブジェクトの
集まりを生成するパターンです
Abstract Factoryパターン とは
Abstract Factoryパターンでは、部品の役割を持つクラスとその部品を作る工
場の役割を持つクラスが存在します。
ただし、その工場には関連し合う部品を生成するためのメソッドがそれぞれ用意
されます。また、関連し合う部品群の種類に応じて、その工場自身も「工場を生成
するための工場」によって生成されます。
これにより、状況に応じて生成される具体的な部品群を切り替えることができま
す。
まとめると、Abstract Factoryパターンでは工場から生成される部品は抽象化
されており、部品の具体的な内容や生成手順をクライアントが意識しなくて済むよ
うになります。
Abstract Factoryパターンの目的
 互いに関連したり依存し合うオブジェクト群を、その具象クラスを明確
にせずに 生成するためのインターフェースを提供する。
Abstract Factoryパターンのメリット
 具体的なクラスをクライアントから隠蔽する
 クライアントは具体的な工場や部品に直接アクセスするのではなく、抽象化され
た工場や部品のAPIのみを使って部品オブジェクトを生成したりアクセスしたり
できます。このため、クライアントを変更することなく、具体的な工場や部品を変
更することが可能です。
 利用する部品群の整合性を保つ
 関連し合うオブジェクトを扱う場合、その整合性を保つことが重要になります。
Abstract Factoryパターンを適用することで、オブジェクト群の整合性を容易
に保つことができます。
Abstract Factoryパターンのメリット
 部品群の単位で切り替えができる
 ConcreteFactoryクラスは関連する部品の集まりを生成します。つまり、
ConcreteFactoryクラスを切り替えることで、関連する部品の集まりを容易に
切り替えることができます。
Abstract Factoryのクラス図
役割り
 1. AbstractProduct1・2・3(抽象的な製品)
 「AbstractFactory」(抽象的な工場)によって生成される抽象的なオブジェクト(部品・製品)のインタフェー
スを定義します。
 2. ConcreteProductA1・A2・A3、ConcreteProductB1・B2・B3(具体的な製品)
 「AbstractProduct1・2・3」のインタフェースを実装します。
 3. AbstractFactory(抽象的な工場)
 「AbstractProduct1・2・3」を生成するためのインタフェースを定義します。
※Factoryオブジェクト「ConcreteFactoryA」「ConcreteFactoryB」(具体的な工場)を生成するための
クラスメソッドを定義します。
 4. ConcreteFactoryA・ConcreteFactoryB(具体的な工場)
 「AbstractFactory」のインタフェースを実装します。
 5. Client(利用者)
 「AbstractProduct1・2・3」「AbstractFactory」が提供するインタフェースのみを使用して処理を行いま
す。
AbstractProduct1.java
public abstract class AbstractProduct1 {
protected String name;
public AbstractProduct1(String name) {
this.name = name;
}
public abstract void execute();
}
AbstractProduct2.java
public abstract class AbstractProduct2 {
protected String name;
public AbstractProduct2(String name) {
this.name = name;
}
public abstract void run();
}
AbstractProduct3.java
public abstract class AbstractProduct3 {
protected String name;
public AbstractProduct3(String name) {
this.name = name;
}
public abstract void action();
}
ConcreteProductA1.java
public class ConcreteProductA1 extends AbstractProduct1 {
public ConcreteProductA1(String name) {
super(name);
}
public void execute() {
System.out.println(name + " 完成(A1-execute)!");
}
}
ConcreteProductA2.java
public class ConcreteProductA2 extends AbstractProduct2 {
public ConcreteProductA2(String name) {
super(name);
}
public void run() {
System.out.println(name + " 完成(A2-run)!");
}
}
ConcreteProductA3.java
public class ConcreteProductA3 extends AbstractProduct3 {
public ConcreteProductA3(String name) {
super(name);
}
public void action() {
System.out.println(name + " 完成(A3-action)!");
}
}
ConcreteProductB1.java
public class ConcreteProductB1 extends AbstractProduct1 {
public ConcreteProductB1(String name) {
super(name);
}
public void execute() {
System.out.println(name + " 完成(B1-execute)!");
}
}
ConcreteProductB2.java
public class ConcreteProductB2 extends AbstractProduct2 {
public ConcreteProductB2(String name) {
super(name);
}
public void run() {
System.out.println(name + " 完成(B2-run)!");
}
}
ConcreteProductB3.java
public class ConcreteProductB3 extends AbstractProduct3 {
public ConcreteProductB3(String name) {
super(name);
}
public void action() {
System.out.println(name + " 完成(B3-action)!");
}
}
AbstractFactory.java
public abstract class AbstractFactory {
public static AbstractFactory createFactory(int factoryId){
switch(factoryId){
case ConcreteFactoryA.id:
return new ConcreteFactoryA();
case ConcreteFactoryB.id:
return new ConcreteFactoryB();
default:
return null;
}
}
public abstract AbstractProduct1 createProduct1();
public abstract AbstractProduct2 createProduct2();
public abstract AbstractProduct3 createProduct3();
}
ConcreteFactoryA.java
public class ConcreteFactoryA extends AbstractFactory {
public static final int id = 1;
public AbstractProduct1 createProduct1() {
return new ConcreteProductA1("工場A - 製品1");
}
public AbstractProduct2 createProduct2() {
return new ConcreteProductA2("工場A - 製品2");
}
public AbstractProduct3 createProduct3() {
return new ConcreteProductA3("工場A - 製品3");
}
}
ConcreteFactoryB.java
public class ConcreteFactoryB extends AbstractFactory {
public static final int id = 2;
public AbstractProduct1 createProduct1() {
return new ConcreteProductB1("工場B - 製品1");
}
public AbstractProduct2 createProduct2() {
return new ConcreteProductB2("工場B - 製品2");
}
public AbstractProduct3 createProduct3() {
return new ConcreteProductB3("工場B - 製品3");
}
}
Client.java
public class Client {
public static void main(String[] args) {
List<AbstractFactory> factorys = new ArrayList<AbstractFactory>();
factorys.add(AbstractFactory.createFactory(ConcreteFactoryA.id));
factorys.add(AbstractFactory.createFactory(ConcreteFactoryB.id));
Iterator<AbstractFactory> it = factorys.iterator();
while (it.hasNext()){
AbstractFactory factory = it.next();
AbstractProduct1 product1 = factory.createProduct1();
AbstractProduct2 product2 = factory.createProduct2();
AbstractProduct3 product3 = factory.createProduct3();
product1.execute();
product2.run();
product3.action();
}
}
}
実行結果
C:¥sample¥desin_pattern¥abstract_factory>javac Client.java [Enter]
C:¥sample¥desin_pattern¥abstract_factory>java Client [Enter]
工場A - 製品1 完成(A1-execute)!
工場A - 製品2 完成(A2-run)!
工場A - 製品3 完成(A3-action)!
工場B - 製品1 完成(B1-execute)!
工場B - 製品2 完成(B2-run)!
工場B - 製品3 完成(B3-action)!
Factory Method との違い
 「Factory Method」パターンは、『オブジェクト生成』の抽象化にポイ
ントを置いたパターンであるのに対し、「Abstract Factory」パターン
は、『関連するオブジェクト郡をまとめて生成するための手順』の抽象
化にある。
GoFデザインパターン
構造に関するパターン3種
Adapter パターン
• 継承・委譲をすることで、使えなかった処理を
使えるようにするパターン
• 既存のクラスに手を加えずに互換性の無いク
ラスを組み合わせることが出来る
• 後から処理を足すのに便利
特徴
Composite パターン
特徴
• 共通した処理を決めておくことで、単一オブ
ジェクトとオブジェクトの集合を区別せずに良
くなる
• 共通するインターフェースを持つので、後から
処理を変更し辛い
Flyweight パターン
特徴
• インスタンスを使いまわすことでメモリを節約する(使用するメ
モリ領域を共有する)
• 処理負荷を減らす(newで生成するのに掛かる時間を短縮す
る)

More Related Content

What's hot

【DL輪読会】DINOv2: Learning Robust Visual Features without Supervision
【DL輪読会】DINOv2: Learning Robust Visual Features without Supervision【DL輪読会】DINOv2: Learning Robust Visual Features without Supervision
【DL輪読会】DINOv2: Learning Robust Visual Features without SupervisionDeep Learning JP
 
パスワード氾濫時代のID管理とは? ~最新のOpenIDが目指すユーザー認証の効率的な強化~
パスワード氾濫時代のID管理とは? ~最新のOpenIDが目指すユーザー認証の効率的な強化~パスワード氾濫時代のID管理とは? ~最新のOpenIDが目指すユーザー認証の効率的な強化~
パスワード氾濫時代のID管理とは? ~最新のOpenIDが目指すユーザー認証の効率的な強化~Tatsuo Kudo
 
ソースコードの品質向上のための効果的で効率的なコードレビュー
ソースコードの品質向上のための効果的で効率的なコードレビューソースコードの品質向上のための効果的で効率的なコードレビュー
ソースコードの品質向上のための効果的で効率的なコードレビューMoriharu Ohzu
 
SQLアンチパターン - 開発者を待ち受ける25の落とし穴 (拡大版)
SQLアンチパターン - 開発者を待ち受ける25の落とし穴 (拡大版)SQLアンチパターン - 開発者を待ち受ける25の落とし穴 (拡大版)
SQLアンチパターン - 開発者を待ち受ける25の落とし穴 (拡大版)Takuto Wada
 
機械学習で泣かないためのコード設計
機械学習で泣かないためのコード設計機械学習で泣かないためのコード設計
機械学習で泣かないためのコード設計Takahiro Kubo
 
Elasticsearch の検索精度のチューニング 〜テストを作って高速かつ安全に〜
Elasticsearch の検索精度のチューニング 〜テストを作って高速かつ安全に〜Elasticsearch の検索精度のチューニング 〜テストを作って高速かつ安全に〜
Elasticsearch の検索精度のチューニング 〜テストを作って高速かつ安全に〜Takahiko Ito
 
全力解説!Transformer
全力解説!Transformer全力解説!Transformer
全力解説!TransformerArithmer Inc.
 
DBスキーマもバージョン管理したい!
DBスキーマもバージョン管理したい!DBスキーマもバージョン管理したい!
DBスキーマもバージョン管理したい!kwatch
 
グラフ構造のデータモデルをPower BIで可視化してみた
グラフ構造のデータモデルをPower BIで可視化してみたグラフ構造のデータモデルをPower BIで可視化してみた
グラフ構造のデータモデルをPower BIで可視化してみたCData Software Japan
 
Python におけるドメイン駆動設計(戦術面)の勘どころ
Python におけるドメイン駆動設計(戦術面)の勘どころPython におけるドメイン駆動設計(戦術面)の勘どころ
Python におけるドメイン駆動設計(戦術面)の勘どころJunya Hayashi
 
実運用して分かったRabbit MQの良いところ・気をつけること #jjug
実運用して分かったRabbit MQの良いところ・気をつけること #jjug実運用して分かったRabbit MQの良いところ・気をつけること #jjug
実運用して分かったRabbit MQの良いところ・気をつけること #jjugYahoo!デベロッパーネットワーク
 
AIによるアニメ生成の挑戦
AIによるアニメ生成の挑戦AIによるアニメ生成の挑戦
AIによるアニメ生成の挑戦Koichi Hamada
 
プロジェクトマネージャのための機械学習工学入門
プロジェクトマネージャのための機械学習工学入門プロジェクトマネージャのための機械学習工学入門
プロジェクトマネージャのための機械学習工学入門Nobukazu Yoshioka
 
入門 Kubeflow ~Kubernetesで機械学習をはじめるために~ (NTT Tech Conference #4 講演資料)
入門 Kubeflow ~Kubernetesで機械学習をはじめるために~ (NTT Tech Conference #4 講演資料)入門 Kubeflow ~Kubernetesで機械学習をはじめるために~ (NTT Tech Conference #4 講演資料)
入門 Kubeflow ~Kubernetesで機械学習をはじめるために~ (NTT Tech Conference #4 講演資料)NTT DATA Technology & Innovation
 
時系列予測にTransformerを使うのは有効か?
時系列予測にTransformerを使うのは有効か?時系列予測にTransformerを使うのは有効か?
時系列予測にTransformerを使うのは有効か?Fumihiko Takahashi
 
SegFormer: Simple and Efficient Design for Semantic Segmentation with Transfo...
SegFormer: Simple and Efficient Design for Semantic Segmentation with Transfo...SegFormer: Simple and Efficient Design for Semantic Segmentation with Transfo...
SegFormer: Simple and Efficient Design for Semantic Segmentation with Transfo...harmonylab
 
ドメイン駆動設計のためのオブジェクト指向入門
ドメイン駆動設計のためのオブジェクト指向入門ドメイン駆動設計のためのオブジェクト指向入門
ドメイン駆動設計のためのオブジェクト指向入門増田 亨
 
20230216_Python機械学習プログラミング.pdf
20230216_Python機械学習プログラミング.pdf20230216_Python機械学習プログラミング.pdf
20230216_Python機械学習プログラミング.pdfShintaro Fukushima
 
【DL輪読会】Scale Efficiently: Insights from Pre-training and Fine-tuning Transfor...
【DL輪読会】Scale Efficiently: Insights from Pre-training and Fine-tuning Transfor...【DL輪読会】Scale Efficiently: Insights from Pre-training and Fine-tuning Transfor...
【DL輪読会】Scale Efficiently: Insights from Pre-training and Fine-tuning Transfor...Deep Learning JP
 

What's hot (20)

【DL輪読会】DINOv2: Learning Robust Visual Features without Supervision
【DL輪読会】DINOv2: Learning Robust Visual Features without Supervision【DL輪読会】DINOv2: Learning Robust Visual Features without Supervision
【DL輪読会】DINOv2: Learning Robust Visual Features without Supervision
 
パスワード氾濫時代のID管理とは? ~最新のOpenIDが目指すユーザー認証の効率的な強化~
パスワード氾濫時代のID管理とは? ~最新のOpenIDが目指すユーザー認証の効率的な強化~パスワード氾濫時代のID管理とは? ~最新のOpenIDが目指すユーザー認証の効率的な強化~
パスワード氾濫時代のID管理とは? ~最新のOpenIDが目指すユーザー認証の効率的な強化~
 
ソースコードの品質向上のための効果的で効率的なコードレビュー
ソースコードの品質向上のための効果的で効率的なコードレビューソースコードの品質向上のための効果的で効率的なコードレビュー
ソースコードの品質向上のための効果的で効率的なコードレビュー
 
SQLアンチパターン - 開発者を待ち受ける25の落とし穴 (拡大版)
SQLアンチパターン - 開発者を待ち受ける25の落とし穴 (拡大版)SQLアンチパターン - 開発者を待ち受ける25の落とし穴 (拡大版)
SQLアンチパターン - 開発者を待ち受ける25の落とし穴 (拡大版)
 
機械学習で泣かないためのコード設計
機械学習で泣かないためのコード設計機械学習で泣かないためのコード設計
機械学習で泣かないためのコード設計
 
Elasticsearch の検索精度のチューニング 〜テストを作って高速かつ安全に〜
Elasticsearch の検索精度のチューニング 〜テストを作って高速かつ安全に〜Elasticsearch の検索精度のチューニング 〜テストを作って高速かつ安全に〜
Elasticsearch の検索精度のチューニング 〜テストを作って高速かつ安全に〜
 
全力解説!Transformer
全力解説!Transformer全力解説!Transformer
全力解説!Transformer
 
DBスキーマもバージョン管理したい!
DBスキーマもバージョン管理したい!DBスキーマもバージョン管理したい!
DBスキーマもバージョン管理したい!
 
グラフ構造のデータモデルをPower BIで可視化してみた
グラフ構造のデータモデルをPower BIで可視化してみたグラフ構造のデータモデルをPower BIで可視化してみた
グラフ構造のデータモデルをPower BIで可視化してみた
 
Python におけるドメイン駆動設計(戦術面)の勘どころ
Python におけるドメイン駆動設計(戦術面)の勘どころPython におけるドメイン駆動設計(戦術面)の勘どころ
Python におけるドメイン駆動設計(戦術面)の勘どころ
 
実運用して分かったRabbit MQの良いところ・気をつけること #jjug
実運用して分かったRabbit MQの良いところ・気をつけること #jjug実運用して分かったRabbit MQの良いところ・気をつけること #jjug
実運用して分かったRabbit MQの良いところ・気をつけること #jjug
 
AIによるアニメ生成の挑戦
AIによるアニメ生成の挑戦AIによるアニメ生成の挑戦
AIによるアニメ生成の挑戦
 
プロジェクトマネージャのための機械学習工学入門
プロジェクトマネージャのための機械学習工学入門プロジェクトマネージャのための機械学習工学入門
プロジェクトマネージャのための機械学習工学入門
 
入門 Kubeflow ~Kubernetesで機械学習をはじめるために~ (NTT Tech Conference #4 講演資料)
入門 Kubeflow ~Kubernetesで機械学習をはじめるために~ (NTT Tech Conference #4 講演資料)入門 Kubeflow ~Kubernetesで機械学習をはじめるために~ (NTT Tech Conference #4 講演資料)
入門 Kubeflow ~Kubernetesで機械学習をはじめるために~ (NTT Tech Conference #4 講演資料)
 
時系列予測にTransformerを使うのは有効か?
時系列予測にTransformerを使うのは有効か?時系列予測にTransformerを使うのは有効か?
時系列予測にTransformerを使うのは有効か?
 
SegFormer: Simple and Efficient Design for Semantic Segmentation with Transfo...
SegFormer: Simple and Efficient Design for Semantic Segmentation with Transfo...SegFormer: Simple and Efficient Design for Semantic Segmentation with Transfo...
SegFormer: Simple and Efficient Design for Semantic Segmentation with Transfo...
 
UE4ディープラーニングってやつでなんとかして!環境構築編(Python3+TensorFlow)
UE4ディープラーニングってやつでなんとかして!環境構築編(Python3+TensorFlow) UE4ディープラーニングってやつでなんとかして!環境構築編(Python3+TensorFlow)
UE4ディープラーニングってやつでなんとかして!環境構築編(Python3+TensorFlow)
 
ドメイン駆動設計のためのオブジェクト指向入門
ドメイン駆動設計のためのオブジェクト指向入門ドメイン駆動設計のためのオブジェクト指向入門
ドメイン駆動設計のためのオブジェクト指向入門
 
20230216_Python機械学習プログラミング.pdf
20230216_Python機械学習プログラミング.pdf20230216_Python機械学習プログラミング.pdf
20230216_Python機械学習プログラミング.pdf
 
【DL輪読会】Scale Efficiently: Insights from Pre-training and Fine-tuning Transfor...
【DL輪読会】Scale Efficiently: Insights from Pre-training and Fine-tuning Transfor...【DL輪読会】Scale Efficiently: Insights from Pre-training and Fine-tuning Transfor...
【DL輪読会】Scale Efficiently: Insights from Pre-training and Fine-tuning Transfor...
 

Viewers also liked

GoF のデザインパターンじゃないけど、よくあるパターン
GoF のデザインパターンじゃないけど、よくあるパターンGoF のデザインパターンじゃないけど、よくあるパターン
GoF のデザインパターンじゃないけど、よくあるパターンGaprot
 
Crystalを触り始めてから起こったこと
Crystalを触り始めてから起こったことCrystalを触り始めてから起こったこと
Crystalを触り始めてから起こったことat grandpa
 
XP寺子屋 デザインパターン入門
XP寺子屋 デザインパターン入門XP寺子屋 デザインパターン入門
XP寺子屋 デザインパターン入門takepu
 
覚えて帰ろうJavaデザインパターン
覚えて帰ろうJavaデザインパターン覚えて帰ろうJavaデザインパターン
覚えて帰ろうJavaデザインパターンKazuya Hirota
 
Fly weight pattern #dezapatan
Fly weight pattern #dezapatanFly weight pattern #dezapatan
Fly weight pattern #dezapatankuidaoring
 
凡人の凡人による凡人のためのデザインパターン第一幕 Public
凡人の凡人による凡人のためのデザインパターン第一幕 Public凡人の凡人による凡人のためのデザインパターン第一幕 Public
凡人の凡人による凡人のためのデザインパターン第一幕 Publicbonjin6770 Kurosawa
 
Strategy パターンと開放/閉鎖原則に見るデザインパターンの有用性
Strategy パターンと開放/閉鎖原則に見るデザインパターンの有用性Strategy パターンと開放/閉鎖原則に見るデザインパターンの有用性
Strategy パターンと開放/閉鎖原則に見るデザインパターンの有用性tomo_masakura
 
Reactor Design Pattern
Reactor Design PatternReactor Design Pattern
Reactor Design Patternliminescence
 
DevLOVE関西2012 B-2「メンバーの行動が激変!「ペアふりかえり」ワークショップ
DevLOVE関西2012 B-2「メンバーの行動が激変!「ペアふりかえり」ワークショップ DevLOVE関西2012 B-2「メンバーの行動が激変!「ペアふりかえり」ワークショップ
DevLOVE関西2012 B-2「メンバーの行動が激変!「ペアふりかえり」ワークショップ takepu
 
上級救命技能認定
上級救命技能認定上級救命技能認定
上級救命技能認定Tetsuya Yoshida
 
デザインパターン勉強会
デザインパターン勉強会デザインパターン勉強会
デザインパターン勉強会Tetsuya Yoshida
 
お客様へ価値を届け続けるために~継続的デリバリーの活用~
お客様へ価値を届け続けるために~継続的デリバリーの活用~お客様へ価値を届け続けるために~継続的デリバリーの活用~
お客様へ価値を届け続けるために~継続的デリバリーの活用~takepu
 
オブジェクト指向モデリング
オブジェクト指向モデリングオブジェクト指向モデリング
オブジェクト指向モデリングtakepu
 
デザインパターン(state,strategy,template)
デザインパターン(state,strategy,template)デザインパターン(state,strategy,template)
デザインパターン(state,strategy,template)tniky1
 
XP寺子屋第9回「シンプル・プログラミング」
XP寺子屋第9回「シンプル・プログラミング」XP寺子屋第9回「シンプル・プログラミング」
XP寺子屋第9回「シンプル・プログラミング」takepu
 
「コトナス」:出会わなくても良いアプリ『Match★Contact』
「コトナス」:出会わなくても良いアプリ『Match★Contact』「コトナス」:出会わなくても良いアプリ『Match★Contact』
「コトナス」:出会わなくても良いアプリ『Match★Contact』cotonas_en
 
Xp入門 ~これで分かる!究極のxp入門~
Xp入門 ~これで分かる!究極のxp入門~Xp入門 ~これで分かる!究極のxp入門~
Xp入門 ~これで分かる!究極のxp入門~takepu
 
Java数値(浮動小数点)課題勉強会
Java数値(浮動小数点)課題勉強会Java数値(浮動小数点)課題勉強会
Java数値(浮動小数点)課題勉強会Tetsuya Yoshida
 

Viewers also liked (20)

GoF のデザインパターンじゃないけど、よくあるパターン
GoF のデザインパターンじゃないけど、よくあるパターンGoF のデザインパターンじゃないけど、よくあるパターン
GoF のデザインパターンじゃないけど、よくあるパターン
 
Crystalを触り始めてから起こったこと
Crystalを触り始めてから起こったことCrystalを触り始めてから起こったこと
Crystalを触り始めてから起こったこと
 
XP寺子屋 デザインパターン入門
XP寺子屋 デザインパターン入門XP寺子屋 デザインパターン入門
XP寺子屋 デザインパターン入門
 
覚えて帰ろうJavaデザインパターン
覚えて帰ろうJavaデザインパターン覚えて帰ろうJavaデザインパターン
覚えて帰ろうJavaデザインパターン
 
Fly weight pattern #dezapatan
Fly weight pattern #dezapatanFly weight pattern #dezapatan
Fly weight pattern #dezapatan
 
dezainn
dezainndezainn
dezainn
 
凡人の凡人による凡人のためのデザインパターン第一幕 Public
凡人の凡人による凡人のためのデザインパターン第一幕 Public凡人の凡人による凡人のためのデザインパターン第一幕 Public
凡人の凡人による凡人のためのデザインパターン第一幕 Public
 
Strategy パターンと開放/閉鎖原則に見るデザインパターンの有用性
Strategy パターンと開放/閉鎖原則に見るデザインパターンの有用性Strategy パターンと開放/閉鎖原則に見るデザインパターンの有用性
Strategy パターンと開放/閉鎖原則に見るデザインパターンの有用性
 
Reactor Design Pattern
Reactor Design PatternReactor Design Pattern
Reactor Design Pattern
 
DevLOVE関西2012 B-2「メンバーの行動が激変!「ペアふりかえり」ワークショップ
DevLOVE関西2012 B-2「メンバーの行動が激変!「ペアふりかえり」ワークショップ DevLOVE関西2012 B-2「メンバーの行動が激変!「ペアふりかえり」ワークショップ
DevLOVE関西2012 B-2「メンバーの行動が激変!「ペアふりかえり」ワークショップ
 
上級救命技能認定
上級救命技能認定上級救命技能認定
上級救命技能認定
 
デザインパターン勉強会
デザインパターン勉強会デザインパターン勉強会
デザインパターン勉強会
 
お客様へ価値を届け続けるために~継続的デリバリーの活用~
お客様へ価値を届け続けるために~継続的デリバリーの活用~お客様へ価値を届け続けるために~継続的デリバリーの活用~
お客様へ価値を届け続けるために~継続的デリバリーの活用~
 
オブジェクト指向モデリング
オブジェクト指向モデリングオブジェクト指向モデリング
オブジェクト指向モデリング
 
Template Method Design Pattern
Template Method Design PatternTemplate Method Design Pattern
Template Method Design Pattern
 
デザインパターン(state,strategy,template)
デザインパターン(state,strategy,template)デザインパターン(state,strategy,template)
デザインパターン(state,strategy,template)
 
XP寺子屋第9回「シンプル・プログラミング」
XP寺子屋第9回「シンプル・プログラミング」XP寺子屋第9回「シンプル・プログラミング」
XP寺子屋第9回「シンプル・プログラミング」
 
「コトナス」:出会わなくても良いアプリ『Match★Contact』
「コトナス」:出会わなくても良いアプリ『Match★Contact』「コトナス」:出会わなくても良いアプリ『Match★Contact』
「コトナス」:出会わなくても良いアプリ『Match★Contact』
 
Xp入門 ~これで分かる!究極のxp入門~
Xp入門 ~これで分かる!究極のxp入門~Xp入門 ~これで分かる!究極のxp入門~
Xp入門 ~これで分かる!究極のxp入門~
 
Java数値(浮動小数点)課題勉強会
Java数値(浮動小数点)課題勉強会Java数値(浮動小数点)課題勉強会
Java数値(浮動小数点)課題勉強会
 

Similar to デザインパターン

PHP 2大 web フレームワークの徹底比較!
PHP 2大 web フレームワークの徹底比較!PHP 2大 web フレームワークの徹底比較!
PHP 2大 web フレームワークの徹底比較!Shohei Okada
 
【アシアル塾】PHPオブジェクト指向再入門・第四回デザインパターンに学ぶクラス設計
【アシアル塾】PHPオブジェクト指向再入門・第四回デザインパターンに学ぶクラス設計【アシアル塾】PHPオブジェクト指向再入門・第四回デザインパターンに学ぶクラス設計
【アシアル塾】PHPオブジェクト指向再入門・第四回デザインパターンに学ぶクラス設計アシアル株式会社
 
symfonyで汎用設定値を読み書きするモデル等をプラグインにした話
symfonyで汎用設定値を読み書きするモデル等をプラグインにした話symfonyで汎用設定値を読み書きするモデル等をプラグインにした話
symfonyで汎用設定値を読み書きするモデル等をプラグインにした話Hidenori Goto
 
デザインパターン(初歩的な7パターン)
デザインパターン(初歩的な7パターン)デザインパターン(初歩的な7パターン)
デザインパターン(初歩的な7パターン)和明 斎藤
 
10分でわかるFuelPHP @ 2013/04 FuelPHP入門ハンズオン vol.1
 10分でわかるFuelPHP @ 2013/04 FuelPHP入門ハンズオン vol.1 10分でわかるFuelPHP @ 2013/04 FuelPHP入門ハンズオン vol.1
10分でわかるFuelPHP @ 2013/04 FuelPHP入門ハンズオン vol.1kenjis
 
10分でわかるFuelPHP @ 2011/12
10分でわかるFuelPHP @ 2011/1210分でわかるFuelPHP @ 2011/12
10分でわかるFuelPHP @ 2011/12kenjis
 
Django 1.5 における効果的な MTV 設計 & ネイティブApp
Django 1.5 における効果的な MTV 設計 & ネイティブAppDjango 1.5 における効果的な MTV 設計 & ネイティブApp
Django 1.5 における効果的な MTV 設計 & ネイティブAppYikei Lu
 
カラーミーショップ「カスタマイズスクール第1期vol.1」
カラーミーショップ「カスタマイズスクール第1期vol.1」カラーミーショップ「カスタマイズスクール第1期vol.1」
カラーミーショップ「カスタマイズスクール第1期vol.1」ec-campus
 
10分でわかるFuelPHP @ 2012/05 OSC2012 Nagoya
 10分でわかるFuelPHP @ 2012/05 OSC2012 Nagoya 10分でわかるFuelPHP @ 2012/05 OSC2012 Nagoya
10分でわかるFuelPHP @ 2012/05 OSC2012 Nagoyakenjis
 
2005 07 30_xwj_customizinig
2005 07 30_xwj_customizinig2005 07 30_xwj_customizinig
2005 07 30_xwj_customizinigTom Hayakawa
 
エンタープライズ分野での実践AngularJS
エンタープライズ分野での実践AngularJSエンタープライズ分野での実践AngularJS
エンタープライズ分野での実践AngularJSAyumi Goto
 
第4回Symfony2勉強会 基礎編ワークショップ.1
第4回Symfony2勉強会 基礎編ワークショップ.1第4回Symfony2勉強会 基礎編ワークショップ.1
第4回Symfony2勉強会 基礎編ワークショップ.1Yusuke Ueno
 
Windows ストア lob アプリ開発のためのガイダンスとフレームワークのご紹介 rev
Windows ストア lob アプリ開発のためのガイダンスとフレームワークのご紹介 revWindows ストア lob アプリ開発のためのガイダンスとフレームワークのご紹介 rev
Windows ストア lob アプリ開発のためのガイダンスとフレームワークのご紹介 revShotaro Suzuki
 
eZ Publish 2012年8月勉強会 - テンプレートオーバーライド
eZ Publish 2012年8月勉強会 - テンプレートオーバーライドeZ Publish 2012年8月勉強会 - テンプレートオーバーライド
eZ Publish 2012年8月勉強会 - テンプレートオーバーライドericsagnes
 
pi-3. 式の抽象化とメソッド
pi-3. 式の抽象化とメソッドpi-3. 式の抽象化とメソッド
pi-3. 式の抽象化とメソッドkunihikokaneko1
 
FlutterでのWidgetツリーへの状態伝播とアクセス制限の基本戦略
FlutterでのWidgetツリーへの状態伝播とアクセス制限の基本戦略FlutterでのWidgetツリーへの状態伝播とアクセス制限の基本戦略
FlutterでのWidgetツリーへの状態伝播とアクセス制限の基本戦略cch-robo
 
Firefox 学生向けアドオンパック
Firefox 学生向けアドオンパックFirefox 学生向けアドオンパック
Firefox 学生向けアドオンパックKosei Moriyama
 
第2回デザインパターン資料
第2回デザインパターン資料第2回デザインパターン資料
第2回デザインパターン資料gaaupp
 
GAE/GoでWebアプリ開発入門
GAE/GoでWebアプリ開発入門GAE/GoでWebアプリ開発入門
GAE/GoでWebアプリ開発入門Takuya Ueda
 

Similar to デザインパターン (20)

PHP 2大 web フレームワークの徹底比較!
PHP 2大 web フレームワークの徹底比較!PHP 2大 web フレームワークの徹底比較!
PHP 2大 web フレームワークの徹底比較!
 
【アシアル塾】PHPオブジェクト指向再入門・第四回デザインパターンに学ぶクラス設計
【アシアル塾】PHPオブジェクト指向再入門・第四回デザインパターンに学ぶクラス設計【アシアル塾】PHPオブジェクト指向再入門・第四回デザインパターンに学ぶクラス設計
【アシアル塾】PHPオブジェクト指向再入門・第四回デザインパターンに学ぶクラス設計
 
Dakota+openFoam1
Dakota+openFoam1Dakota+openFoam1
Dakota+openFoam1
 
symfonyで汎用設定値を読み書きするモデル等をプラグインにした話
symfonyで汎用設定値を読み書きするモデル等をプラグインにした話symfonyで汎用設定値を読み書きするモデル等をプラグインにした話
symfonyで汎用設定値を読み書きするモデル等をプラグインにした話
 
デザインパターン(初歩的な7パターン)
デザインパターン(初歩的な7パターン)デザインパターン(初歩的な7パターン)
デザインパターン(初歩的な7パターン)
 
10分でわかるFuelPHP @ 2013/04 FuelPHP入門ハンズオン vol.1
 10分でわかるFuelPHP @ 2013/04 FuelPHP入門ハンズオン vol.1 10分でわかるFuelPHP @ 2013/04 FuelPHP入門ハンズオン vol.1
10分でわかるFuelPHP @ 2013/04 FuelPHP入門ハンズオン vol.1
 
10分でわかるFuelPHP @ 2011/12
10分でわかるFuelPHP @ 2011/1210分でわかるFuelPHP @ 2011/12
10分でわかるFuelPHP @ 2011/12
 
Django 1.5 における効果的な MTV 設計 & ネイティブApp
Django 1.5 における効果的な MTV 設計 & ネイティブAppDjango 1.5 における効果的な MTV 設計 & ネイティブApp
Django 1.5 における効果的な MTV 設計 & ネイティブApp
 
カラーミーショップ「カスタマイズスクール第1期vol.1」
カラーミーショップ「カスタマイズスクール第1期vol.1」カラーミーショップ「カスタマイズスクール第1期vol.1」
カラーミーショップ「カスタマイズスクール第1期vol.1」
 
10分でわかるFuelPHP @ 2012/05 OSC2012 Nagoya
 10分でわかるFuelPHP @ 2012/05 OSC2012 Nagoya 10分でわかるFuelPHP @ 2012/05 OSC2012 Nagoya
10分でわかるFuelPHP @ 2012/05 OSC2012 Nagoya
 
2005 07 30_xwj_customizinig
2005 07 30_xwj_customizinig2005 07 30_xwj_customizinig
2005 07 30_xwj_customizinig
 
エンタープライズ分野での実践AngularJS
エンタープライズ分野での実践AngularJSエンタープライズ分野での実践AngularJS
エンタープライズ分野での実践AngularJS
 
第4回Symfony2勉強会 基礎編ワークショップ.1
第4回Symfony2勉強会 基礎編ワークショップ.1第4回Symfony2勉強会 基礎編ワークショップ.1
第4回Symfony2勉強会 基礎編ワークショップ.1
 
Windows ストア lob アプリ開発のためのガイダンスとフレームワークのご紹介 rev
Windows ストア lob アプリ開発のためのガイダンスとフレームワークのご紹介 revWindows ストア lob アプリ開発のためのガイダンスとフレームワークのご紹介 rev
Windows ストア lob アプリ開発のためのガイダンスとフレームワークのご紹介 rev
 
eZ Publish 2012年8月勉強会 - テンプレートオーバーライド
eZ Publish 2012年8月勉強会 - テンプレートオーバーライドeZ Publish 2012年8月勉強会 - テンプレートオーバーライド
eZ Publish 2012年8月勉強会 - テンプレートオーバーライド
 
pi-3. 式の抽象化とメソッド
pi-3. 式の抽象化とメソッドpi-3. 式の抽象化とメソッド
pi-3. 式の抽象化とメソッド
 
FlutterでのWidgetツリーへの状態伝播とアクセス制限の基本戦略
FlutterでのWidgetツリーへの状態伝播とアクセス制限の基本戦略FlutterでのWidgetツリーへの状態伝播とアクセス制限の基本戦略
FlutterでのWidgetツリーへの状態伝播とアクセス制限の基本戦略
 
Firefox 学生向けアドオンパック
Firefox 学生向けアドオンパックFirefox 学生向けアドオンパック
Firefox 学生向けアドオンパック
 
第2回デザインパターン資料
第2回デザインパターン資料第2回デザインパターン資料
第2回デザインパターン資料
 
GAE/GoでWebアプリ開発入門
GAE/GoでWebアプリ開発入門GAE/GoでWebアプリ開発入門
GAE/GoでWebアプリ開発入門
 

デザインパターン