Code Compete 第2部 高品質なコードの作成 第5章コンストラクショ

Code Complete 第2版 上　完全なプログラミングを目指して

5.3.5|秘密の隠蔽(情報の隠蔽)
　2種類の秘密
　　情報隠蔽の「秘密」は、大きく2種類に分類される
　　-複雑さを隠ぺいして、特に必要がなければ考えずに済むようにする。
　　-変更の源を隠ぺいして、変更が発生した時に、その影響を1か所に留める。

　　-パフォーマンスの明らかな低下
　　　一般に問題となるのは、コーディングレベルの方である。データ項目への間接的なアクセスが、オブジェクトのインスタンス化やルーチン呼び出しなどを新たに発生させ、実行時のパフォーマンスを低下させるのではないかという懸念だ。それを心配するのは時期尚早である。システムのパフォーマンスを測定し、ボトルネックを突き止めるまでは、コードレベルのパフォーマンスを向上するために最良の方法は、モジュール性の高い設計を行うことである。そうすれば、ホットスポットを突き止めた時に、システムの残りの部分に影響を与えずに、個々のクラスやルーチンを最適化できる。

パフォーマンスが心配なら、それを考慮しながら実装するより、テストにて実パフォーマンスがどの程度のものか確認する工数が必要ということか。
実装時はあくまで疎結合となるよう考慮しながら実装することが第一優先、パフォーマンスが悪いようならそれ用にテストとボトルネック発見の工数を用意して、その中でやるべし、と。
#となると見積り段階でパフォーマンスに懸念がある部分は洗い出す必要があるが、果たしてそう都合良く洗い出せるのか？

5.3.6|変更の可能性が高い領域の特定
　+変更されそうな項目を特定する
　+変更されそうな項目を分離する

　-業務ルール
　-入出力
　-設計とコンストラクションの難度が高い領域
　-状態変数
　　-状態変数としてブール型の変数を使用しない。代わりに列挙型を使用する。
　　-状態変数を直接参照するのではなく、アクセスルーチンを使用する
　-データサイズの瀬谷区

状態変数を分離するという発想はなかった。今のシステムでは列挙型を活用する方式になっており、「状態変数に列挙型を使用」することはできている。
アクセスルーチンを利用した状態変数の参照はやっていない。ただ、そこまで難しい判定を行っているわけではない。
#機会があれば参考にしよう

　-セマンティクス結合

#保守フェーズなら仕方ない部分は少なからず出てくると思う。開発時点でこんなことやってはならない

5.3.8|一般的なデザインパターンの検索

#「デザインパターン」という単語が通じるのが会社に一人しかいない、自分もそんなに詳しくはないので、理解を深めねば。

5.3.9|その他のヒューリスティクス
　-ブルートフォースの検討

理論的には正しいがうまくいかない方法にこだわるべきではない。総当りを軽く見てはならない。
#自戒を込めて、どうしても面倒さが先に立って軽く見てしまう。

#3年以上ぶりに再開

Java言語で学ぶデザイパターン入門 8章 Bridge

Java言語で学ぶデザインパターン入門

Bridgeパターン
・実装と機能を分離する

インタフェース(Xxx)と実装クラス(XxxImpl)にわける

SQLチューニング *[SQL][Oracle][INSERT]

机上の空論だが、こんなんできるらしい。
マルチテーブルインサートとも表現される。

メリット
・プログラムから送るSQL文は1文で済む
・UNION ALLしてるだけなので、テーブル間に関連がなくてもいい
デメリット
・テーブル定義が一つでも変わったら全体が動かない
・一つでもいらないテーブルが出てきたとしても全体の再テストが必要
・再利用性が低い

INSERT ALL
 WHEN テーブル判別フラグ= 1 THEN
  INTO AAAAA VALUES( 項目1,…,項目100 )
 WHEN テーブル判別フラグ= 2 THEN
  INTO BBBBB VALUES( 項目101,…,項目200 )
SELECT 項目1
 ,項目2
 ,項目3
 :
 ,テーブル判別フラグ
 ,項目100
 ,項目102
 ,項目103
 :
FROM (SELECT 列名1 項目1
   ,列名2 項目2
   ,列名3 項目3
   ：
   ,列名100 項目100
   ,1 テーブル判別フラグ
  FROM テーブルA
  UNION ALL
  SELECT 列名A 項目101
   ,列名B 項目102
   ,列名C 項目103
   ：
   ,列名A100 項目200
   ,1 テーブル判別フラグ
  FROM テーブルA)

Java言語で学ぶデザイパターン入門 8章 Abstract Factory

Java言語で学ぶデザインパターン入門

AbstractFactoryパターン
・インタフェースが決まっている抽象的な部品を組み合わせて複雑な構造のインスタンスを作る
AbstractProduct
・AbstractFactoryによって作り出される抽象的な部品や製品のインタフェース
AbstractFactory
・AbstractProductのインスタンスを生成するためのインタフェース
Client
・AbstractFactory、AbstractProductのみを使って仕事を行う

Clientは具体的な実装を意識しない。

ConcreteProduct
・AbstractProductを実装するクラス

部品の追加は困難→すでに存在するConcreteFactory全てに修正が入る
AbstractFactoryパターンは部品の組み合わせでインスタンスを生成、Builderパターンは段階的にインスタンスを生成を大きくしていく。
→Builderパターンで、Directorから順に呼ばれる各メソッドがAbstractFactoryパターンでいうところのConcreteProduct？

Java言語で学ぶデザイパターン入門 7章 Builder

Java言語で学ぶデザインパターン入門

・Builder役
インスタンスを生成するためのインタフェースを定める
・ConcreteBuilder役
Builderのインタフェースを実装したクラス
成果物を得る為のメソッドはこちらに定義
・Director役
Builderのインタフェースを使ってインスタンスを生成
・Client役
Builderを利用する役

Builder役でインスタンスを生成するための機能を提供するが、呼び出しの順番は制御せず、Directorが順番を制御する
→Builderは各メソッドがどの順番で呼ばれてもOKな作りにしたほうがよい？
Builderのもつ複雑なインスタンス生成過程を、Directorを使うことによって外部からは簡単につくれるようになる。
Facadeパターンのインスタンス生成版みたいな感じ。

成果物を得るメソッドはConcreteBuilderが持つのはなぜだろう？
・Directorに持たせようとしたらBuilderのメソッドでなければならない
・Builderに持たせたとしてもClientはBuilderを意識しないので意味が無い
・Directorのコンストラクタなり何なりにConcreteBuilderは渡すので、ClientはConcreteBuilderを意識せざるを得ない
から、やはりConcreteBuilderに持たせるしかないのか。。。なんか微妙な感じがするけどこんなところか。

Java言語で学ぶデザイパターン入門 6章 Prototype

Java言語で学ぶデザインパターン入門

Prototype：インスタンスから別のインスタンスを生成する
（1）種類が多すぎてクラスにまとめられない場合
（2）クラスからのインスタンス作成が難しい場合
（3）フレームワークと生成するインスタンスを分けたい場合
cloneメソッド、Cloneableインターフェースが関係する

どういうことかというと以下の様なことらしい
(1)扱うオブジェクトの種類が多くてクラスを作ってられない時
(2)ユーザの入力によって生成されるインスタンスの複製を行いたい時
(3)インスタンス生成を特定のクラスに依存させないようにしたい時
→インターフェースによる処理、パラメータの型をインターフェースにすることみたい

インターフェースと実装クラスの関係？
この本ではPrototypeの役割を担うのはインターフェースとなっている。
実装が何であれ、AクラスのA'メソッドの引数の型がBインターフェースであれば、それを実装したCクラスでA'メソッドは実行可能となる
→A、B、Cにてプロトタイプパターンを実現？
であれば、AとBは機能を提供する側が用意して、Cを利用する側が用意するということか？

Prototype(原型)の役
サンプルプログラムではProductインターフェースがこの役を務めた
ConcretePrototype(具体的な原型)の役
サンプルプログラムではProductインターフェースの具象クラスがこの役を務めた
Client(利用者)の役
サンプルプログラムではManagerクラスがこの役を務めた

上記引用で考えるとPrototype、Clientを提供されて、利用する側はConcretePrototypeを作る？
Clientのメソッド内でPrototypeを使うということみたいなので、そう考えるのが自然かなー。

Prototype：インスタンスから別のインスタンスを生成する

これは結局わからなかった、Cloneableインターフェースの説明があったけど、それのことなんだろうか。
cloneメソッドでシャローコピーでもいいからインスタンスのクローンを作ることが出来れば、それはPrototypeパターンを使っているといえるということなのだろうか。

Java言語で学ぶデザイパターン入門 5章 Singleton

Java言語で学ぶデザインパターン入門

Singleton
・指定したクラスのインスタンスが絶対に１個しか存在しないことを保証したい
・インスタンスが１個しか存在しないことをプログラム上で表現したい

今はbeanutilのconverter作る時に使っている
ｂｉｒｔのエンジン作るクラスとかもSingletonにしてもいいかも
Java5からはenumを使ってSingletonパターンを実現するほうがより安全となっているらしい