書いてみたけど文章だけじゃどうにもならんから、絵つけようこれ・・・わかりにくいわ(´ρ`)
誰が見ても分かりやすく理解しやすく誤解がないようにして結果として見やすいソースが
広がりますように(-m-)” パンパン
2012年8月29日水曜日
Abstract Factoryパターンについて。
Abstract Factoryパターンについて。
本を読むと大抵難しくこんな感じで書いてあると思います。
「互いに関連したり依存し合うオブジェクト群を、その具象クラスを明確にせずに生成する為のインターフェースを提供する。」
これ読んで一発でわかるなら、以降のAbstract Factoryパターンについては読まなくても大丈夫です。
何言ってんだ？？？
って場合は、前記載した通りできる限り簡単に噛み砕いて説明をします。
そもそもこのAbstract Factoryパターンで何がやりたいのよっていうと、
同じような操作を呼び出し元が行う場合に、各種呼び出し結果による振る舞いを
実態に任せて、呼び出し元は何を実体化させるかを意識しないでおきたいというような場合に利用します。
(´－｀) ンー これでも難しいですね説明が。
さて、もっと噛み砕きましょう。
何かしようかと思ったら、見えない妖精さん達が、最適な物を作ってくれるようにする為の仕組みです。
(こんな書き方したら、間違いなく偉い人は怒るよね？(´ρ`))
なんでこのような仕組みが必要かというと、例えば開発において使用するデータベースが環境単位で複数あるとします。
そんな時、当然使用するSqlCommandクラスなどは、対象となるDBに合わせたものが必要となります。
しかしながら、データを操作する側としては、インサート処理はインサート処理として記載をしたいわけです。
データベースがなんであれ。
そうした場合に、データ操作を行う為のクラスの実態と、データ操作を行うという命令自体を分けてしまい、
その間を取り持つための抽象クラスとして、各種操作を行う為の命令を提供しようという事です。
結果として、使用する側は実態が何かを考えないで、各種操作をするうえで必要となる命令部分を
抽象クラス側で提供してもらえればよい。
抽象クラス側も実装自体は、各種操作側の実態に任せてしまえばよいので楽ちんです。
そして操作側も、他に何があるかを考えずに、指定された抽象クラス内で定義されている
操作を実装するだけで問題が無いので楽ちん楽ちんです。
そして、最後に、このクラスの実態を生成する為仕組みとしてクラスの実態を作成する為の
実態作成クラスを作ってしまいます。
基本的には、どういった設定で実態クラスを生成するかは、Abstract Factoryの実態作成クラス側の内部に隠蔽するべきです。
これを外部から指定し始めてしまうと、隠蔽していた実際の命令が外部にまで飛び火する可能性が高いです。
実態がなんであれ、命令として同一の命令で臨む結果を設定に従って適宜実態であるクラスが行ってくれるのが
一番良い方法です。
もっとも、どうして特殊な操作が必要で、生成する実態を外部から制御したい場合があるとは思いますが、
そういった場合は、苦肉の策としてパラメータを指定して生成する実態を制御する方法もあります。
ただ、これを行うと先に書いた通り、抽象化していたクラスの実態が何であるかをわかったうえで操作する必要がある
特殊な物がある状態になるので、メンテナンス性は著しく低下します。
また、新規の操作を追加したり、新しい実態群が必要になった場合は、実装側のクラス全てに手が入る可能性がある為、
メンテナンスを行う手間が多くなる可能性もあります。
この辺を考えて作る必要があります。
今回のデータベースで考えると、作成しなければいけないのは、コマンドクラスとパラメータクラスとコネクションクラスとって色々ありますが、これらのクラスを抽象化し、実態をそれぞれ実装してもらい使う側は抽象クラス使って、実態生成の整合性については実態生成部分に責任をなすりつけようという形になります。
んでは今回はここまで。
暇があったらgithubにでもサンプルを随時追加予定？？？
本を読むと大抵難しくこんな感じで書いてあると思います。
「互いに関連したり依存し合うオブジェクト群を、その具象クラスを明確にせずに生成する為のインターフェースを提供する。」
これ読んで一発でわかるなら、以降のAbstract Factoryパターンについては読まなくても大丈夫です。
何言ってんだ？？？
って場合は、前記載した通りできる限り簡単に噛み砕いて説明をします。
そもそもこのAbstract Factoryパターンで何がやりたいのよっていうと、
同じような操作を呼び出し元が行う場合に、各種呼び出し結果による振る舞いを
実態に任せて、呼び出し元は何を実体化させるかを意識しないでおきたいというような場合に利用します。
(´－｀) ンー これでも難しいですね説明が。
さて、もっと噛み砕きましょう。
何かしようかと思ったら、見えない妖精さん達が、最適な物を作ってくれるようにする為の仕組みです。
(こんな書き方したら、間違いなく偉い人は怒るよね？(´ρ`))
なんでこのような仕組みが必要かというと、例えば開発において使用するデータベースが環境単位で複数あるとします。
そんな時、当然使用するSqlCommandクラスなどは、対象となるDBに合わせたものが必要となります。
しかしながら、データを操作する側としては、インサート処理はインサート処理として記載をしたいわけです。
データベースがなんであれ。
そうした場合に、データ操作を行う為のクラスの実態と、データ操作を行うという命令自体を分けてしまい、
その間を取り持つための抽象クラスとして、各種操作を行う為の命令を提供しようという事です。
結果として、使用する側は実態が何かを考えないで、各種操作をするうえで必要となる命令部分を
抽象クラス側で提供してもらえればよい。
抽象クラス側も実装自体は、各種操作側の実態に任せてしまえばよいので楽ちんです。
そして操作側も、他に何があるかを考えずに、指定された抽象クラス内で定義されている
操作を実装するだけで問題が無いので楽ちん楽ちんです。
そして、最後に、このクラスの実態を生成する為仕組みとしてクラスの実態を作成する為の
実態作成クラスを作ってしまいます。
基本的には、どういった設定で実態クラスを生成するかは、Abstract Factoryの実態作成クラス側の内部に隠蔽するべきです。
これを外部から指定し始めてしまうと、隠蔽していた実際の命令が外部にまで飛び火する可能性が高いです。
実態がなんであれ、命令として同一の命令で臨む結果を設定に従って適宜実態であるクラスが行ってくれるのが
一番良い方法です。
もっとも、どうして特殊な操作が必要で、生成する実態を外部から制御したい場合があるとは思いますが、
そういった場合は、苦肉の策としてパラメータを指定して生成する実態を制御する方法もあります。
ただ、これを行うと先に書いた通り、抽象化していたクラスの実態が何であるかをわかったうえで操作する必要がある
特殊な物がある状態になるので、メンテナンス性は著しく低下します。
また、新規の操作を追加したり、新しい実態群が必要になった場合は、実装側のクラス全てに手が入る可能性がある為、
メンテナンスを行う手間が多くなる可能性もあります。
この辺を考えて作る必要があります。
今回のデータベースで考えると、作成しなければいけないのは、コマンドクラスとパラメータクラスとコネクションクラスとって色々ありますが、これらのクラスを抽象化し、実態をそれぞれ実装してもらい使う側は抽象クラス使って、実態生成の整合性については実態生成部分に責任をなすりつけようという形になります。
んでは今回はここまで。
暇があったらgithubにでもサンプルを随時追加予定？？？
2012年7月25日水曜日
いまだにこんなところがorz
本日から新しい仕事を開始したが・・・正直しょっぱなから絶望した。
いまだにVB.NET使ってVB 6.0みたいなコード書く人間が多数居たなんて信じられない。
おまけにそれが、貸金業者で使用される大きなシステムだとは本当に信じられない。
久しぶりに見ましたよ。
メソッド一つが500行とか、if文の分岐が長すぎて追う気が失せたあげく激しくネストしてるのを。
VB.NET自体の言語仕様はそんなに悪くないのに、VB 6.0みたいに組む人間が多くて
えらく不遇な言語のような気がしてならない。
実際私も、そういったものが嫌でC#をメインとして動いているのに・・・今回の仕事ときたら(ノ_・、)シクシク
ついでにこの手のコード書く人たちって毎回人のせいにするよね。
立場の弱い新人のせいとかに。
新人とかが見てわからないだの、メンテナンスしに来る人間がわからないだの。
けど、新人の教育が出来ない、メンテナンスに呼ぶ人間の実力を見抜けないあなたのようなプログラマーがコーディング規約や作り方を決めたのがそもそもの間違いなんだよ。
ってのが正直な意見だ・・・
自分がわからないもの、理解できないものを遠ざけて、自分が過去培ったものだけを厳選して成長をやめたようにしか正直思えない。
少なくとも、.NETでVB 6.0チックに組むのは本当にやめてほしい。
ちなみにLINQまで使うな言われたんだが、そもそも.NET使うなと言いたい。
何のために.NETを使ってコーディングしてるのか本気でわけがわからん。
プログラムが出来るというのは、対象の言語を使用してコーディングが出来るというものではなく、
上記の事を含めて、さらにデザインパターン、ソフトウェアアーキテクチャパターンを理解したうえで組めるといってほしい。
言語知識のみが先行して、出来上がってくるものが目も当てられないものが多すぎる。
あと、Visual Studioつかいながら、Add-inのインストールすらさせないところや、ひどいところはヘルプすらインストールさせないところがある。
今回の現場はヘルプすらインストールできない。
いったいなんでVisual Studioを使用してプログラムを作成しているのか本気でわからない。
いったい何が作りたくて何がしたいんだろうか。本当に疑問だ・・・
あっ・・・ついでにいまだにVSS使ってるのをみたのも久しぶりだった・・・はぁ泣けるわ本気で。
最後に、金融系や医療系などで上記のようなプログラムを作成している方々がまれにいる？結構な頻度で見かける時もありますが。
是非とも他業種に行ってほしい。
どうにもならなくてリファクタリングをしながら一部の機能改善や速度改善をやるのにもう疲れたよ・・・
そうそう、書き忘れてましたが、Visual SourceSafe 2005 Standard Editionの通常サポート期間はすでに2012年07月10日で切れてます。
今現在は延長サポート期間に突入してます。
いい加減VSS使うの本当にやめてほしいわ。本気で発狂寸前になる。
あと、ドキュメントの管理を手作業でやらずに、ちゃんとバージョン管理ソフト使ってくださいよ(´ρ`)
http://support.microsoft.com/lifecycle/?LN=ja&c1=501
ついでに、手作業で変更履歴のファイル作るのやめましょうよ・・・
そんなのSVNとTracでも入れて管理しましょうよorz
開発が忙しいとか色々言ってますが、このへん自動化できて手が抜けるところを上手に手を抜かないから時間がなくなるんですよ。
全部手作業でやってたら、そら時間なんてどれだけあっても足りるはずがない。
おまけに、手作業で職人技でもの作れば高く売れるものもありますが、システム開発で自動化できるものを手作業しても、時間と間違いが増えるだけで開発費が高くなるだけですよ・・・
はぁ～
いまだにVB.NET使ってVB 6.0みたいなコード書く人間が多数居たなんて信じられない。
おまけにそれが、貸金業者で使用される大きなシステムだとは本当に信じられない。
久しぶりに見ましたよ。
メソッド一つが500行とか、if文の分岐が長すぎて追う気が失せたあげく激しくネストしてるのを。
VB.NET自体の言語仕様はそんなに悪くないのに、VB 6.0みたいに組む人間が多くて
えらく不遇な言語のような気がしてならない。
実際私も、そういったものが嫌でC#をメインとして動いているのに・・・今回の仕事ときたら(ノ_・、)シクシク
ついでにこの手のコード書く人たちって毎回人のせいにするよね。
立場の弱い新人のせいとかに。
新人とかが見てわからないだの、メンテナンスしに来る人間がわからないだの。
けど、新人の教育が出来ない、メンテナンスに呼ぶ人間の実力を見抜けないあなたのようなプログラマーがコーディング規約や作り方を決めたのがそもそもの間違いなんだよ。
ってのが正直な意見だ・・・
自分がわからないもの、理解できないものを遠ざけて、自分が過去培ったものだけを厳選して成長をやめたようにしか正直思えない。
少なくとも、.NETでVB 6.0チックに組むのは本当にやめてほしい。
ちなみにLINQまで使うな言われたんだが、そもそも.NET使うなと言いたい。
何のために.NETを使ってコーディングしてるのか本気でわけがわからん。
プログラムが出来るというのは、対象の言語を使用してコーディングが出来るというものではなく、
上記の事を含めて、さらにデザインパターン、ソフトウェアアーキテクチャパターンを理解したうえで組めるといってほしい。
言語知識のみが先行して、出来上がってくるものが目も当てられないものが多すぎる。
あと、Visual Studioつかいながら、Add-inのインストールすらさせないところや、ひどいところはヘルプすらインストールさせないところがある。
今回の現場はヘルプすらインストールできない。
いったいなんでVisual Studioを使用してプログラムを作成しているのか本気でわからない。
いったい何が作りたくて何がしたいんだろうか。本当に疑問だ・・・
あっ・・・ついでにいまだにVSS使ってるのをみたのも久しぶりだった・・・はぁ泣けるわ本気で。
最後に、金融系や医療系などで上記のようなプログラムを作成している方々がまれにいる？結構な頻度で見かける時もありますが。
是非とも他業種に行ってほしい。
どうにもならなくてリファクタリングをしながら一部の機能改善や速度改善をやるのにもう疲れたよ・・・
そうそう、書き忘れてましたが、Visual SourceSafe 2005 Standard Editionの通常サポート期間はすでに2012年07月10日で切れてます。
今現在は延長サポート期間に突入してます。
いい加減VSS使うの本当にやめてほしいわ。本気で発狂寸前になる。
あと、ドキュメントの管理を手作業でやらずに、ちゃんとバージョン管理ソフト使ってくださいよ(´ρ`)
http://support.microsoft.com/lifecycle/?LN=ja&c1=501
ついでに、手作業で変更履歴のファイル作るのやめましょうよ・・・
そんなのSVNとTracでも入れて管理しましょうよorz
開発が忙しいとか色々言ってますが、このへん自動化できて手が抜けるところを上手に手を抜かないから時間がなくなるんですよ。
全部手作業でやってたら、そら時間なんてどれだけあっても足りるはずがない。
おまけに、手作業で職人技でもの作れば高く売れるものもありますが、システム開発で自動化できるものを手作業しても、時間と間違いが増えるだけで開発費が高くなるだけですよ・・・
はぁ～
2012年6月21日木曜日
デザインパターン
どうにもUbuntuやWindows 8などを見ていて、最近プログラムに全く手を出せていない気がしないでもない。
ってことで久しぶりに頭の体操としてデザインパターンのお話を備忘録に残しておくことにする。
基本的にデザインパターンって何よって事だが、プログラムを実装するうえで起こりうるさまざまな問題点に対しての回答というのが簡単に理解できて短い説明だと思う。
たとえば拡張性がどうたらとかいった問題を解決する為の手法です。
色々本を読むと小難しく説明しているものもありますが、先人達が苦労したけど結果こうしたら上手くいったよってのをパターン化したものですんで、そんなに難しく考える事もないです(´ρ`)
紹介してあるデザインパターンの本についても目を通すとえらく小難しい事を書いてありますが、
意訳すると上のような感じです。
なんで気軽に考えて大丈夫です(´ρ`)
よくあるプログラムを作成するのに初心者の方々が、オブジェクト指向やデザインパターンや、MVVMなどの聞きなれないパターンを聞いて混乱する事がありますが、その辺の解決策になると良いなぁ～っと祈っております。
そもそも、オブジェクト指向などの説明も難しくしようとすれば難しく説明でき、非常にありがたく聞こえるが、内容を理解して意訳するとそんなにありがたいものでもない。
乱暴な言い方をすればオブジェクト指向はデータと関連するロジックをまとめて、蓋をして中身みえないようにして、なんかあったら外から叩いて中の様子が分かるようにしよう。
みたいなものである。
この辺ありがたがって、難しい言葉を並べると、初心者は難しいけど凄い事なんだと勘違いをして、手を出すのをためらってしまう。
なんで今回のデザインパターンについても、超意訳しまくりの、超簡単な説明としてしまおうと思っています。
これを読んで、なぁ～んだ、こんなもんかと思って頂き、楽しいプログラミングが出来る事を祈っております。
んでは次回よりデザインパターンの紹介と、それに伴う実装についてのお話を記載していきます。
そして、オブジェクト指向について、むちゃくちゃ意訳した為、偉い人が見たら発狂するかもしれませんので、多少細かい事だけ書いておきます。
もともと、むかぁ～しむかしは、構造化プログラミングというのが流行っていました。
これは、ロジックを構造化して、抜き出して再利用しやすいものにしましょうよっていう書き方です。
ところがどっこい、ロジックに渡すべきデータの内容が日増しに肥大し、データの管理が出来なくなってきた為、次は処理に使用するデータとロジックをまとめたモジュールというものに目がつけられました。
これで安心かと思いきや、モジュールに格納されるデータについての賞味期限が何時切れるのかがわからないという事態が発生するようになりました。
ってことで仕方がないので、今度はデータとロジックをまとめて賞味期限が何時切れるのかを明確にしたオブジェクト指向というのが出てきました。
これがオブジェクト指向です・・・・駄目だorz
これ偉い人が読んだら絶対発狂する(´ρ`)
私に小難しい説明は無理そうなんで、なんかわかる人がその辺まとめてくれてるから、そういう偉い人向けのはそっちに任せる。
ついでにMVVMはソフトウェアアーキテクチャパターンとなり、デザインパターンとは似て非なるものである。
この辺についても暇を見てつらつら書き綴っていきます。
ってことで久しぶりに頭の体操としてデザインパターンのお話を備忘録に残しておくことにする。
基本的にデザインパターンって何よって事だが、プログラムを実装するうえで起こりうるさまざまな問題点に対しての回答というのが簡単に理解できて短い説明だと思う。
たとえば拡張性がどうたらとかいった問題を解決する為の手法です。
色々本を読むと小難しく説明しているものもありますが、先人達が苦労したけど結果こうしたら上手くいったよってのをパターン化したものですんで、そんなに難しく考える事もないです(´ρ`)
紹介してあるデザインパターンの本についても目を通すとえらく小難しい事を書いてありますが、
意訳すると上のような感じです。
なんで気軽に考えて大丈夫です(´ρ`)
よくあるプログラムを作成するのに初心者の方々が、オブジェクト指向やデザインパターンや、MVVMなどの聞きなれないパターンを聞いて混乱する事がありますが、その辺の解決策になると良いなぁ～っと祈っております。
そもそも、オブジェクト指向などの説明も難しくしようとすれば難しく説明でき、非常にありがたく聞こえるが、内容を理解して意訳するとそんなにありがたいものでもない。
乱暴な言い方をすればオブジェクト指向はデータと関連するロジックをまとめて、蓋をして中身みえないようにして、なんかあったら外から叩いて中の様子が分かるようにしよう。
みたいなものである。
この辺ありがたがって、難しい言葉を並べると、初心者は難しいけど凄い事なんだと勘違いをして、手を出すのをためらってしまう。
なんで今回のデザインパターンについても、超意訳しまくりの、超簡単な説明としてしまおうと思っています。
これを読んで、なぁ～んだ、こんなもんかと思って頂き、楽しいプログラミングが出来る事を祈っております。
んでは次回よりデザインパターンの紹介と、それに伴う実装についてのお話を記載していきます。
そして、オブジェクト指向について、むちゃくちゃ意訳した為、偉い人が見たら発狂するかもしれませんので、多少細かい事だけ書いておきます。
もともと、むかぁ～しむかしは、構造化プログラミングというのが流行っていました。
これは、ロジックを構造化して、抜き出して再利用しやすいものにしましょうよっていう書き方です。
ところがどっこい、ロジックに渡すべきデータの内容が日増しに肥大し、データの管理が出来なくなってきた為、次は処理に使用するデータとロジックをまとめたモジュールというものに目がつけられました。
これで安心かと思いきや、モジュールに格納されるデータについての賞味期限が何時切れるのかがわからないという事態が発生するようになりました。
ってことで仕方がないので、今度はデータとロジックをまとめて賞味期限が何時切れるのかを明確にしたオブジェクト指向というのが出てきました。
これがオブジェクト指向です・・・・駄目だorz
これ偉い人が読んだら絶対発狂する(´ρ`)
私に小難しい説明は無理そうなんで、なんかわかる人がその辺まとめてくれてるから、そういう偉い人向けのはそっちに任せる。
ついでにMVVMはソフトウェアアーキテクチャパターンとなり、デザインパターンとは似て非なるものである。
この辺についても暇を見てつらつら書き綴っていきます。
登録:
投稿 (Atom)