Developers Summit 2011 http://codezine.jp/devsumi/2011/

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

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

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

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

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

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

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

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

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

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

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

12. 番外編: コメントの良くない使い方 「何やら怪しげな取引をしている」 // 立ち会いは強く当たって // 流れでお願いします // ----2010.05.10 Enapyon r(-◎ω◎-)n++; // 了解いたしました！ // では流れで少し踏ん張るよ。// ----2010.05.10 Kasugapee

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

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

15. きちんと命名する 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);

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

35. 手続き型プログラミング // 「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で割れるものを」「コンソール出力」それぞれが変更になるときどうなる?

36. オブジェクト指向プログラミング 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); } }} 「整数の」 が変更になるときどうなる?

37. ジェネリック プログラミング 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); } }}

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

39. Let’s enjoy programming!