2011/02/17 Developers Summit 【17-D-3】LT-3 「Microsoft .NET 上でのマルチパラダイムプログラミング」

LT-3Microsoft .NET 上でのマルチパラダイムプログラミング
～ソースコードにラブ注入～
17-D-3
小島富治雄
福井コンピュータ株式会社技術開発部シニアエキスパートこみゅぷらす代表

自己紹介
小島富治雄
デブサミ参加は8回目

これまでのあらすじ
デブサミ2007コードの品質こそがビジネスを成功させる!～コードの品質を上げるために命名編～
デブサミ2008「きれいなコードは好きですか?」～品質の高いソースコードを書くコツ～
デブサミ2009美しいソースコードのための考え方

きれいなコードを書くコツ
「名前重要」
(まつもとゆきひろ氏)

名前付けのプラクティス
概念と名前を一致させる
同じ概念には同じ名前を付けて、異なった概念には違う名前を付ける
1つの独立した概念のみを表す名前を付ける
抽象的な概念には抽象的な名前、具体的な概念には具体的な名前を付ける
抽象的すぎて伝わりにくい概念は、メタファ (譬え) で表す

コメントで命名は得策でない

コードに書けないことのみをコメントにする。

番外編:コメントの良くない使い方

番外編: コメントの良くない使い方
「説明になってない」
// ここで n を ++ するとちゃんと動く
// ---- 2008/11/08 Shigapyon r(-◎ω◎-)
n++;

「会話をしている」
// ここで n を ++ するとちゃんと動く
// ----2008/11/08 Shigapyon r(-◎ω◎-)n++;
// ↑ ここでやることに何か意味があるんでしょうか?
// 上でやっちゃダメなんでしょうか?
// ---- 2008/11/09 蓮舫

「会話をしている (しかもトピズレ)」
// バレンタインデーなのに帰れないなんて
// 意味が分からない (; ;)
// ----2011/02/14 Shigapyon r(-◎ω◎-)n++;
// ですよねー// ----2011/02/14 Yamapee

「何やら怪しげな取引をしている」
// 立ち会いは強く当たって
// 流れでお願いします
// ----2010.05.10 Enapyon r(-◎ω◎-)n++;
// 了解いたしました！
// では流れで少し踏ん張るよ。// ----2010.05.10 Kasugapee

「コメントで命名は得策でない」のつづき

コメントで命名は得策でない
// もし閏年 (4で割れて 100で割り切れ
// ないか 400で割り切れる) だったら
if (y % 4 == 0 && y % 100 != 0
|| y % 400 == 0) {
// UI にその年を表示する
string s = string.Format(“{0}年n”, y);
// s は表示する文字列
Console.WriteLine(s);
……}

きちんと命名する
static boolCanDividedBy(this int dividend, int divisor)
{ return dividend % divisor == 0; }
static boolIsLeapYear(this int year)
{ return year.CanDividedBy(4) && !year.CanDividedBy(100)
|| year.CanDividedBy(400); }
if (year.IsLeapYear())
UI.ShowYear(year);

ソースコード自身に説明させる

「何に名前を付けたいか」?
ユースケース?
部品?
機能?
状態?
分類?

「何に名前を付けたいか」?
設計/実装時のモデル要素

名前で或る意味を表す。同じ名前を持つものは、同じ意味を持つ

変数名やクラス名、メソッド名などは、「実装/設計モデルを記述するためのボキャブラリ」(小島)

自分の設計/実装モデルをどういう語彙で記述することにするのか

自然でシンプルな語彙で記述するのがわかりやすい

"Beauty Is in Simplicity"
｢文章にしろ、和音にしろ、リズムにしろ、美しく、優雅なもの、優れたものはすべて、シンプルである｡」(プラトン)
「美しいコードとは、シンプルなコードのこと」(ヨルン・オルムハイム、『プログラマが知るべき97のこと』より)

プログラミングでもっとも基本的な原則
単一責務の原則 (Single Responsiblility Principle: SRP)
「変更する理由が同じものを集め、違うものを分ける」
「SRP が最も重要な原則だ」(Robert. C. Martin、『プログラマが知るべき97のこと』より)

プログラミングにおけるポピュラーなパラダイム
手続型
オブジェクト指向型
関数型
ジェネリックス
など

パラダイムによって名前の付け方が変わる
手続き型:手続きに名前を付ける
オブジェクト指向型:対象物に名前を付ける

「銀の弾丸」はないが、複数のパラダイムを適材適所で用いることでSRPに近づける

排他的な分け方だけですめば分ける方法は一つで良い。単一のパラダイムでOK。そうでない場合は複数の分け方が必要。即ちマルチパラダイム。

新しいパラダイムを取り入れるために複数の言語を

何故複数の言語を学ぶのが得策か。
言語は考え方のフレームワークになる (言語が、考え方を枠にはめてしまう) から。
言語が持っていないパラダイムに気付けない。

「金槌しか持っていなければ、すべての問題は釘に見える」(アブラハム・マズロー)

複数の言語に触れる ― 私の体験
英語を学んで、考え方が変わるのを感じた
Cを学んで、考え方が変わるのを感じた
C++を学んで (以下略)
それがパラダイムシフト

複数の言語に触れる例
ハイブリット型 (パラダイム追加型)
C
-> C++
-> C#
-> F#
純粋型 (研究者タイプのあなたに)
Pascal
-> Smalltalk
->Haskell

パラダイムによって記述が変わる例

手続き型プログラミング
// 「1から40までの」「整数の」「3か5で割れるものを」「コンソール出力」
for (int number = 1; number <= 40; number++) {
if (number % 3 == 0 || number % 5 == 0)
Console.WriteLine(number);
}
「 1から40までの」「3か5で割れるものを」「コンソール出力」それぞれが変更になるときどうなる?

オブジェクト指向プログラミング
public abstract class Filter{ public abstract bool IsMatch(int number); }
public abstract class UI{ public abstract void Show(int number); }
public class TheCommand{ public Filter Filter { get; set; } public UI UI { get; set; } public void Run(IEnumerable data) { foreach (int number in data) { if (Filter.IsMatch(number)) UI.Show(number); } }}
「整数の」が変更になるときどうなる?

ジェネリックプログラミング
public abstract class Filter<T>{ public abstract bool IsMatch(T item); }
public abstract class UI<T>{ public abstract void Show(T item); }
public class TheCommand<T>{ public Filter<T> Filter { get; set; } public UI<T> UI { get; set; } public void Run(IEnumerable<T> data) { foreach (T item in data) { if (Filter.IsMatch(item)) UI.Show(item); }
}}

関数型プログラミング
public void Run(IEnumerable<T> data,
Func<T, bool> isMatch,
Action<T> show) {
data.Where(isMatch).ToList().ForEach(show);
}

Let’s enjoy programming!

2011/02/17 Developers Summit 【17-D-3】LT-3 「Microsoft .NET 上でのマルチパラダイムプログラミング」

by Fujio Kojima on Feb 18, 2011

Accessibility

Categories

Tags

Upload Details

Usage Rights

1 Embed 53

Statistics