Date:  Wed, 18 Jul 2007 16:56:05 +0900
Subject:  【オブジェクト倶楽部: 2007-25号】
X-Mail-Count: 00200

       ┏━━━━━━━━━━━━━━━━━━━━━━━━━━■
       ┃                         ■┃
      ●┃● ● オ ブ ジ ェ ク ト 倶 楽 部   ■ ┃
       ┃                       ■  ┃
       ┗━━━━━━━━━━━━━━━━━━━━━━■━━━┛
                          No.194 2007/07/18

■ I N D E X
┃
┣【Topics】オブラブサイト書籍紹介更新!
┣【プログラミング】ゆるーいHaskell[12]
┣【設計】ソフトウェアのお言葉[20] - オブジェクト指向設計はモジュール設計
┗【アンケート】気になるシステム業界 ホントのところ

〇━━━━━━━━━━━━━━━━━━━━━━━━━━━T o p i c s━
 〇 オブラブサイト書籍紹介更新!
  〇 〇━━━━━━━━━━━━━ ━━・ 

本メールマガジンでは、オブジェクト倶楽部のスタッフによる書籍の発売情報
を紹介しています。ブジェクト倶楽部のサイト内にも情報を更新しましたので、
ぜひ、ご覧になってください。

●書籍紹介
 http://www.ObjectClub.jp/technicaldoc/bookguide/

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━1 s t ■━
■
┗【プログラミング】ゆるーいHaskell[12]

西川です。前回[*1]お話した通り今回はHaskellのモナドについてお話します。
モナドは難しいとかよく分からないとかいった話をよく聞きます。実際つきつ
めてやりだすとたしかに難しいものなのかもしれませんが、まずは割りきって
Haskellのモナドを使えたり作ったりできるようになって、それから徐々に理解
を深めるというのはどうでしょう?
それでは早速ghciを起動しましょう。

$ ghci
Prelude> :i Monad
class Monad m where
  (>>=) :: m a -> (a -> m b) -> m b
  (>>) :: m a -> m b -> m b
  return :: a -> m a
  fail :: String -> m a
        -- Defined in GHC.Base
instance Monad Maybe -- Defined in Data.Maybe instance Monad IO -- Defined in GHC.IOBase instance Mnad [] -- Defined in GHC.Base

型クラスMonadには4つの関数があります。それぞれの関数の型に注目してくだ
さい。return関数はある値(=関数)をモナドに投入する関数です。
(>>=)関数はモナド(m a)とモナドの中の値をモナドに投入する関数(a -> mb)
とを引数にとり、モナド(m b)を返す関数です。
(>>)関数は1番目の引数(m a)を無視して2番目の引数(m b)を返す関数です。
fail関数は今回は出番がないので説明を割愛します。
(>>)関数とfail関数にはデフォルトの実装が定義されています。

m >> k = m >>= (\_ -> k)
fail s = error s

ですのでモナドを作る際には(>>=)関数、return関数の2つの関数を定義しさえ
すればよいのです。もちろん必要に応じて(>>)関数もfail関数を定義すること
もできます。さて、いきなりですが、まずは適当にモナドを作ってみましょう。


-- SampleMonad.hs --
data SampleMonad a = SampleMonad a deriving Show

instance Monad SampleMonad where
  return x = SampleMonad x
  (SampleMonad x) >>= f = f x

sample :: a -> SampleMonad a
sample x = return x
-- SampleMonad.hs ここまで --

型クラスMonadのclass宣言にあるmの部分がそのままSampleMonadに置き換わって
いることがお分かりになるのではないでしょうか。
せっかくなので、SampleMonadでちょっと遊んでみましょう。

Prelude> :l SampleMonad.hs
[1 of 1] Compiling Main             ( SampleMonad.hs, interpreted )
Ok, modules loaded: Main.
*Main>
*Main> sample "hoge" >>= return . length SampleMonad 4 *Main> sample "hoge" >>= return . length >>=return . (1+) SampleMonad 5 *Main> sample "hoge" >>= return . length >>= return . (1+) >> return 10SampleMonad 10

SampleMonadは何の役にも立たないし、実装もものすごく簡単ですが、これも立
派なモナドです。ではそもそもモナドのうれしさとは何なんでしょう。
「モナドのすべて」[*2]にこうあります。

1.モジュラリティ
2.柔軟性
3.分離性

このようなモナドのうれしさが本当なのかどうか、実際にちょっと前に流行った
FizzBuzz問題[*3]をモナドを使って解くことで確認してみましょう。

-- FizzBuzz.hs --
data FB a = FB (a, String)

instance Monad FB where
  return x = FB (x, "")
  (FB (x,y)) >>= g = let FB (x',y') = g x in FB (x',y ++ y')

fizzbuzz x = let FB (p,q) = (return x >>= fizz >>= buzz)
             in if q == "" then show p else q

fizz x | x `mod` 3 == 0 = FB (x, "Fizz")
       | otherwise      = return x

buzz x | x `mod` 5 == 0 = FB (x, "Buzz")
       | otherwise      = return x
-- FizzBuzz.hs ここまで --

$ ghci FizzBuzz.hs
*Main> map fizzbuzz [1..100]
(FizzBuzzの結果が表示されます)

3と5で割りきれるなら"FizzBuzz",3で割りきれるなら"Fizz",5で割りきれるな
ら"Buzz"と条件分岐が煩雑なFizzBuzz問題ですが、モナドによって(とくに
(>>=)関数に注目してください)計算の過程を抽象化することにより、実に簡潔
にFizzBuzzを記述することができました。
実際にはこれぐらいの問題ならばわざわざモナドを作る必要はないのかもしれ
ません。ただモナドという仕組みを使って透過的に計算を抽象化して扱うこと
ができる、ということが重要だと思います。ちょっと難しかったでしょうか。
それでは次回はもっとモナドを紹介します。(西川)

[1] : http://www.objectclub.jp/ml-arch/magazine/194.html
[2] : http://www.sampou.org/haskell/a-a-monads/html/introduction.html#why
[3] : http://www.aoky.net/articles/jeff_atwood/why_cant_programmers_program.htm

_______________________________________________________________________
この記事への評価にご協力をお願いします。
URLをクリックして、「ご協力ありがとうございました」のメッセージがご使用
のブラウザに表示されれば投票完了です。
良かった:
http://www.ObjectClub.jp/community/object_ml/estimate?vol=E008-11&choice=0
普通:
http://www.ObjectClub.jp/community/object_ml/estimate?vol=E008-11&choice=1
イマイチ:
http://www.ObjectClub.jp/community/object_ml/estimate?vol=E008-11&choice=2

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━2 n d ■━
■
┗【設計】ソフトウェアのお言葉[20] - オブジェクト指向設計はモジュール設計

こんにちは、天野勝です。
今回のお言葉は「オブジェクト指向設計はモジュール設計」です。『コードコ
ンプリート− 完全なプログラミングを目指して』[*1]のP.189には「オブジェ
クト指向プログラミングの世界では、[設計]とはシステム内のそれぞれのモ
ジュールを設計することを意味する。」とあります。
今回も筆者の独断と偏見で、解釈、解説してみます。

●モジュールとは
「モジュール」とはなんでしょうか?
語感が似ている言葉で、「プロシージャ」がありますが、これとは何が違うの
でしょうか?
調べてみると、諸説があり、何が正しいのかよく分かりませんでした。これで
は、説明がしにくいので、ここでは以下のように定義することにします。

 プロシージャ: ある一連の処理を呼び出し可能にしたもの
 モジュール  : 関連性のあるプロシージャとデータ構造をまとめたもの

プロシージャは、C言語では関数と呼ばれ、Javaではメソッドと呼ばれていま
す。モジュールは、C言語ではソースファイルとして実現されるのが一般的で
す。Javaでは、一つのクラスを一つのソースファイルに格納することが推奨さ
れていますが、実はこれがモジュールの考え方と同じなのです。もっと極端に
考えると、クラスそのものがモジュールなのです。

●設計の大原則は「高凝集、疎結合」
実は、筆者はモジュールとオブジェクト指向はまったく接点がないものだと思っ
ていました。しかし、今回のお言葉に出会い、そして調べていくうちに、どう
やら根本的には同じところを目指しているのだという考えにいたりました。
そもそも、設計では「高凝集、疎結合」を目指すという大原則があります。
あまたの設計技術がありますが、その根幹は似ていて当然ですよね。

●オブジェクト指向言語の機能を使うことがオブジェクト指向設計ではない
根幹が似ているということは、モジュール設計の指針がオブジェクト指向設計
にも使えるわけです。確かに、モジュール強度の考え方は、そのままオブジェ
クト指向設計をする上でとても役に立ちます。
また、その逆でモジュール設計でありがちな失敗が、オブジェクト指向設計に
おいても再現されてしまいます。お互いに無関係なデータ構造と、プロシージャ
を一つのモジュールとして、まとめてしまうというのは、よくある失敗例です。
モジュールの利点を活かせているとは言いがたいです。
オブジェクト指向の場合はどうでしょうか。一つ問いあげるので考えてみてく
ださい。

 オブジェクト指向プログラミングの考え方と、オブジェクト指向言語のどち
 らが先に世の中に存在したでしょうか?

まず、考え方としてのオブジェクト指向プログラミングが先に存在し、そして
そのプログラミングを支援するために、言語が登場してきたという背景があり
ます。オブジェクト指向言語がなくても、オブジェクト指向プログラミングを
してきた先人がいます。重要なのは、その考え方なのです。オブジェクト指向
言語が備えているオブジェクト指向の機能を使うことが重要なのではありませ
ん。
しかし、数あるオブジェクト指向言語には、様々なオブジェクト指向の機能が
備わっています。そのような機能が備わるには、その背景に潜む言語設計者の
考えがぎっしり詰まっているはずです。そのような背景を想像してみると、
その言語を今以上に活かすヒントになることと思います。

●おわりに
モジュール設計とオブジェクト指向設計の関連から発展して、オブジェクト指
向プログラミングの考え方の重要性について説明をしました。
本記事が、皆さんなりのオブジェクト指向プログラミングの考え方を考えるきっ
かけになれば幸いです。

本連載は今回の第20回で終了させていただきます。
次回から、新ネタで連載をいたします。
どうぞ、お楽しみに。(天野勝)

[1]:『コードコンプリート − 完全なプログラミングを目指して』
    著:スティーブ マコネル、訳:石川 勝  アスキー(1994)
    http://www.amazon.co.jp/o/ASIN/4756102107/xpjp-22
    第1版です。第2版ではありません。
_______________________________________________________________________
この記事への評価にご協力をお願いします。
URLをクリックして、「ご協力ありがとうございました」のメッセージがご使用
のブラウザに表示されれば投票完了です。
良かった:
http://www.ObjectClub.jp/community/object_ml/estimate?vol=L001-19&choice=0
普通:
http://www.ObjectClub.jp/community/object_ml/estimate?vol=L001-19&choice=1
イマイチ:
http://www.ObjectClub.jp/community/object_ml/estimate?vol=L001-19&choice=2

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━3 r d ■━
■
┗【アンケート】気になるシステム業界 ホントのところ

今週は「資格を取るワケは?」のホントのところ。前回のアンケートでは、読
者のみなさんがこれから取りたいと思っている資格について、聞いてみました。
多くの方のご回答、ありがとうございました。なんと、アプリケーション
エンジニアが1番。僅差でプロジェクトマネージャが2番手という結果でした。
さて、更に気になったのはその理由。資格を取るワケについても、正直なとこ
ろを、聞かせてくださいね。

  自分の勉強のため。
     http://www.ObjectClub.jp/special/kininaru/vote?vol=160&choice=0
  会社や上司の薦め。
     http://www.ObjectClub.jp/special/kininaru/vote?vol=160&choice=1
  仕事をする上で、どうしても必要なため(無いとできないなど)。
     http://www.ObjectClub.jp/special/kininaru/vote?vol=160&choice=2
  転職するときのため。
     http://www.ObjectClub.jp/special/kininaru/vote?vol=160&choice=3
  資格手当てなどを期待して。
     http://www.ObjectClub.jp/special/kininaru/vote?vol=160&choice=4
  エンジニアとしてのたしなみ。
     http://www.ObjectClub.jp/special/kininaru/vote?vol=160&choice=5
  それは秘密です。
     http://www.ObjectClub.jp/special/kininaru/vote?vol=160&choice=6
  ちょっと語らせて!
     詳細をこのメールに返信ください!!

アンケート結果はオブジェクト倶楽部サイト上にて公開します。お楽しみに。
なお、前号「資格取りますか?」の結果は公開中。ぜひご覧下さい。
⇒http://www.ObjectClub.jp/special/kininaru/vol159/PlonePopoll_results2
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━--■--●--■
■
┗編集後記

こんにちは、編集人です。連休の間に台風と地震という大きな災害がありまし
た。読者のみなさん、そして、みなさんの大切な人たちに、早く笑顔が戻る日
が来て欲しいと思います。天災はやりきれないものですね。
さて、世の中はそろそろ夏休みモード。旅行会社の調べによると、今年は例年
にまして海外旅行予定者が多いとのことでした。読者の皆さんは、いかがでしょ
うか?安全に気をつけて、そして、すばらしい休暇を楽しんできてくださいね。

今週の強引な一言
*** 触らぬ神に祟りなし(ことわざ)***
関わり合わなければ、わざわいを招くことはないという意味。
メンバーの顔色を伺って「言いにくいな」とか、早く帰りたいから「黙ってい
よう」と、その場をしのいだとしても、後々大きな出来事となってしまうとい
うことはありませんか?気がついたなら、関わりあいましょう。
(上田雅美)

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━--■--●--■
● ご意見、ご感想は         ⇒このメールに返信ください
〇 配信中止、アドレス変更は ⇒http://www.ObjectClub.jp/community/object_ml/help/
〇 免責事項、過去の記事は   ⇒http://www.ObjectClub.jp/community/object_ml/
■ 発行:オブジェクト倶楽部 ⇒http://www.ObjectClub.jp/
■ 編集代表:平鍋  健児
Copyright (c)2003-2007 オブジェクト倶楽部. All Rights Reserved.
powered by Eiwa System Management, Inc.