設計手法

[C#]自動プロパティの必要性（その２）

myugaru (myugaru@wankuma.com) — Mon, 31 Mar 2008 11:08:00 GMT

[C#]自動プロパティの必要性

ちょっと私の知識不足が補われたところなので忘れないように整理します。

１．バイナリ互換主張派vsソース互換主張派

アセンブリ分割を考慮するとフィールド公開されたものを後からプロパティ公開に変えることができない、ということですね。

（追：プロパティを期待するリフレクションがフィールドを期待するそれより多いという意見をシャノンさんに頂きました。・・・深すぎて、そろそろめまいがしてきた（と中途半端に逃げる・・・））

これについては中さんのような「ソース互換主張派」がいらっしゃいます。

私もなんとなくソース互換寄りかもしれません。

むしろ今のところ遊びでC#やっていますのでDLL分割して片方だけコンパイルするって状況にはなりにくいです。

２．setter privateで読み取り専用プロパティ派vs readonlyで読み取り専用プロパティ派

読み取り専用プロパティをどう扱うかで状況は変わると思いますので対決しちゃうのは無理があるかも知れません。私はなんとなくreadonlyにしておいて、コンストラクタで初期値設定するほうが読み取り専用を強調してるようで好きです。

それと別ですが、

【A】public int Width { get; private set; }

となっているくらいならば、

【B】private int _Width;

public int Width { get { return _Width; } }

としちゃうほうが私は好きです。

というよりも「設計の最初っからリードオンリーなんだよっ」ってプロパティ作ることってそんなに多いですか？？

「最初はプライベート→あとからやっぱり公開」の状況のほうが私には多かった気がします。例を挙げれば継承されたクラスのプライベートメンバーをやっぱり公開しよう、とかそういうやつです。なのでそういう意味でも【B】にするケースが私の中では多いように思います。

●めげずに結論言っちゃうぞ

前エントリーと同じですが・・・やっぱ私には自動プロパティの必要性は相当ひくいって事になりそうです。

[C#]自動プロパティの必要性

myugaru (myugaru@wankuma.com) — Mon, 31 Mar 2008 09:49:00 GMT

C# 使ってる人、自動プロパティってどうなんですか？

土日は丸々新作ゲームでつぶしてしまったmyugaruです＾＾；おはようございます。

追記：赤字で色々追加しております。結局このエントリー自体が無意味になりつつありますが、私のようにDLL分割しない場合、コンストラクタでフィールド初期化しますよ、って場合は有効だと弱く主張したいと思います・・。

追記：中さんは私の元意見に賛同だそうです。ちょっとだけ強気になれそうなmyugaruでした＾＾テヘ

追記：ごちゃごちゃしてきたのでまとめなおしています→[C#]自動プロパティの必要性（その２）

本題。

【１】public int Width { get; set; }
【２】public int Width { get; private set; }
【３】public int Width { private get; set; }

まず【１】は

【１'】public int Width;

と同義である。同義なら短い【１'】を使う。（←同義ではありませんでした。まとめなおした方をご覧ください）

次に【２】は

【２'】public readonly int Width;

とコンストラクタで初期値を設定するのなら同義である。同義として使う場合なら短い【２'】を使う。

（追記訂正：↑【２】と【２'】は同義ではありませんでした。オノデラさんのコメント参照ください。オノデラさんありがとうございました。）

最後に【３】。書き込み専用プロパティ（＠＠；）？
これの必要な場面に未だかつて出くわした事がない。
こういう例があるよ、とコメントに書かれそうですが、
プロパティで実装するなら読み取れるべきです。
書き込み専用になる必要性があるならインターフェースとしてメソッドを公開すべきです。
「そうじゃない」と自信を持って反論のある方にはぜひ説得力あるコメントをいただきたいですが、
仮にじゃあそんな説得力ある反論があるとすれば、
C#言語開発者レベルの人がそれを見逃すとは考えられません。
それともそのうちwriteonlyというキーワードが増えるんでしょうか？

【１】や【２】をたとえば単純な参照では無いプロパティに将来置き換える可能性がある、
という反論をする人もいるかと思いますが、
【１'】や【２'】を書いておいてその単純参照じゃないコードに書き直す手間とどっちが多いですか？
具体的には以下の【４】のようなコードへです。

【４】
private int _Width;
public int Width { get { return _Width; } set { _Width = value; } }

頭で考えてるだけじゃなく手で実際にやってみることをお勧めします。
【１】や【２】にしたところで【４】にするための追加コード量は圧倒的に多くなんらメリットを感じません。

●結論
自動プロパティは当面、私には全く不要な機能です。
私に説得力ある自動プロパティの良さを教えてくださる方がいれば遠慮なくコメントください。（↓もう来ちゃいましたね；；）

●書き込んで30分で抗議のお便りが（＾＾；

アセンブリ分割してリンクするような場合、最初にフィールド公開しちゃうと後でプロパティ化できないと抗議のめーるが某身内の方から寄せられました（しかも携帯メールへ＾＾；；；）

おっしゃるとおりです。私が悪かった・・・。だって私そんなアセンブリDLL分割するような規模の開発したことねーんだよっっ！（負け惜しみにもなってないorz）

[C#][VB.NET] コーディング標準.PDF

myugaru (myugaru@wankuma.com) — Mon, 24 Mar 2008 20:23:00 GMT

ずいぶん前にC#コーディング標準のPDFがあるのを見つけたのだが、

昨日VB.NETバージョンを見つけた。忘れないようにエントリー。

著者のお二人に敬意を表したいと思います。ありがとうございました。

C#コーディング標準（(C) Copyright 2002 河端善博）
http://www.kawabata.com/dotnet/CodingStdCS.pdf

VB.NET コーディング標準（(C) Copyright 2002 太陽システム(株)中西庸文）
http://www.objectclub.jp/community/codingstandard/CodingStdVB.pdf

3/25 追記

じゃんぬねっとさんによると「Microsoft が推奨するガイドラインに違反している箇所が多い」

そうです。利用程度の判断はそれを踏まえて各自の責任でお願いいたします。

追記２

MSDNにあるガイドライン（はつねさんより）

追記３

よねけんさんによると「（中略）今となっては十分な内容ではない」そうです。

確かに2002年に書かれている文献ですので現在のC#やVB.NETにはそぐわない規則、

足りない規則が多々あると思われます。

追記４

じゃんぬねっとさんによるとMicrosoftのガイドラインも参考程度が良いようです。

委譲というのは２通りあります～私の理解した答っぽいもの

myugaru (myugaru@wankuma.com) — Mon, 24 Mar 2008 18:37:00 GMT

●前エントリー

多重継承をコンポーネント技術で考える

多重継承を前提に考えなければ・・・

●元ネタ

実装を委譲できる言語を作ればいいのかもしれない

●大元のネタ

http://d.hatena.ne.jp/m-hiyama/20080304/1204615775

（↑の檜山さんの方で何か動きがあるようです。明日以降にエントリーするとかしないとか・・・。楽しみですね）

●まず委譲というのは２通りあります

class A
{
    public event EventHandler MouseClick;
    public void OnMouseClick()
    {
        if (MouseClick != null) {
            MouseClick(this, new EventArgs());
        }
    }
}
    
class B
{
    A a = new A();
    
    public B()
    {
        a.MouseClick += new EventHandler(MouseClick);
    }
    
    public void MouseClick(object sender, EventArgs e)
    {
        Console.WriteLine("マウスが押されました");
    }
}
    
class C
{
    B b = new B();
    
    public void MouseClick()
    {
        b.MouseClick(this, new EventArgs());
    }
}

上のコードでクラスＡもクラスＣもクラスＢへ処理を委譲しています。
処理を自分ではなく相手にゆだねるというのが委譲の仕組みです。
インスタンスが必ず関与します。
ただし含まれる方が委譲しているのか委譲されているのかというのは
上記でわかるようにどちらも実現が可能です。

●凪瀬さんと私の会話での委譲

私は凪瀬さんはクラスＣを想定していると考えました。
私はこのクラスＡの形を私はコンポーネントであると言いました。
そして、よりＩＤＥにサポートされているクラスＡを推しました。
この時点で実はコンポーネントが委譲であると気付いていませんでした。
ついさっきふっと気が付きこのエントリーを書くに至りました。
どちらも委譲であったために技術的に交換が可能だったわけです。

●ダイアモンド継承

ここでダイアモンド継承を考えます。

class A { Aの部分 }

　　
class B1 : A { Aの部分+B1の追加部分 }
　　

class B2 : A { Aの部分+B2の追加部分 }
　　

class C : B1, B2 { Aの部分+B1の追加部分+B2の追加部分 }

ここで示したダイアモンド継承のクラスＣの中にＡの部分は１つしかありません。
私は前エントリーでこのクラスＣの中にAの部分が２つ含まれると勘違いしました。
それは委譲で表現するという事から考えたためでした。
委譲というのは先に言ったように２通り書けますが、どちらもかならずインスタンスを介する技術だからです。
この場合ですとＢ１とＢ２のインスタンスが必要になり、どちらのインスタンスにもＡの部分は含まれます。
本来のダイアモンド継承はインスタンスを介さない継承でしか作り得ない技術なのです。

●凪瀬さんの考える委譲とは

それでも凪瀬さんが委譲でなんとかできるという理由がなんとなくわかりました。
凪瀬さんはさらにこのダイアモンド継承の図の最後のクラスから外向けのインターフェースを
指して委譲で実現できるとおっしゃっているように思いました。
すなわち

class C : B1, B2
{
    B1 b1;
    B2 b2;
    
    public FuncA()
    {
        b1.FuncA();
    }
}

ここでFuncAはクラスAに含まれるメソッドです。
ここではb1とb2という２つのインスタンスがありメモリ上のＡの部分は両方に存在します。
しかしＣというクラスを外から見るとクラスＣのpublicなFuncAというメソッドは一つです。
そしてこのFuncAがb1かb2のどちらのFuncAを呼び出すかは自由だと言うことだと思いました。
メモリイメージが２つあるというのは論点ではなく、Ｃから外向きインターフェース上のAの部分が一つになるように委譲でも表現可能であるという意味だと捉えました。

凪瀬さんこれで正解でしょうか？

XP精神を思い出した

myugaru (myugaru@wankuma.com) — Mon, 24 Mar 2008 12:23:00 GMT

XPといってもOSのことじゃあなくってeXtreme Programmingのことです。

ここ最近プログラミングで壁にぶち当たっていたのですが、

あっそうだ、と思い出して

うちにあったXP関係の本とか読んでいました。

なんかすごく元気になりました（笑

本を買ったときは適当に読んでしまっていました。

すごくもったいない事してました。

それにしても手法とかコードの美しさにばかり気を取られてましたねえ。

あんまり気合入れて最初にがっちり作ろうとせず、

肩から力を抜いて、とりあえず作ってみて、んでリファクタリング、ですね。

何も言えなくて・・・夏～UMLをとりあえず発明しかけた（汗）

myugaru (myugaru@wankuma.com) — Fri, 14 Mar 2008 20:21:00 GMT

●ドキュメント化不要？

私はC#のプログラムを作るときには、いきなりコンパイラのエディタに向かってがしがし書いてます。
ずいぶん前に使っていたUNIX-Cの時にはさすがにいきなりはプログラムを作れなかったので、ある程度はテキストとして仕様書など書いたりしていました。
あの頃を思い返せば最近のプログラミング環境は本当に素晴らしいなと感じます。

さくさく作れるのは主に２つの素晴らしい技術があるからです。

１つ目はOOP(オブジェクト指向プログラミング)の絶大パワー。
オブジェクトとしてクラスにまとめ、プロパティやらメソッドを実装してNewする。
そういう部品をどんどん作っていく作業、さらにその部品を組み合わせる作業の２フェーズでとても複雑な仕事も簡単にプログラムに表現できてしまいます。

２つ目にIDE(統合開発環境)の絶大パワー。
コードを書くときにほとんど識別子は頭文字一つとタブキーあるいはデリミターとなる記号の入力。これだけで勝手に入力が完成します。
さらにほどよく自動整形されます。
これのおかげでいくらでも長い識別子を作ることも平気になりました。
昔はコード入力の労力を極力省くために”大域的な識別子ほど短く”みたいなダメダメっぽいスタイルでもやっていました（汗）。
もちろんソースは可読性が下がりましたし今思うと本当に非生産的だったと思います。

ほかにも仕様書要らずの理由は
「一人で作っているからドキュメントでの他者との疎通なんていらない」
とか思っています。・・・いや「いました。」

●苦しくなってきた

・・・といった具合に仕様書要らずの楽々環境を手にした私。
なるべく汎用的なゲーム製作用ライブラリを構築しようと
これまでやったことが無いくらいにかなり大掛かりな構想を練って、
どんどんクラスを量産している日々でした。
それがだんだん非常に具合が悪くなってきたのです。
なんだか自分のプログラムを把握しきれなくなくなっているのです。
例えば同じようなクラスがごちゃごちゃ出来て整理がしきれなくなっています。
同じような、なら良いですがうっかり全く同じクラスを作りかねない状況です。

●初めて出くわした問題

私は難題に出くわしたら

・ステップ１ Google先生とがんばる
・ステップ２それでダメなら誰かに聞く（※１）

の２ステップで大丈夫、みたいなエントリーを前に書きました。

Google先生だけでがんばる（その１）

Google先生と一緒にがんばる（その２）

でも１と２だけじゃあどうしようも無い問題もあることに初めて気付きました。

「自分で解決が十分に出来る範囲にあるのにどうしても解決できない」

のです。
・・・本当にどうしたらいいのでしょうか？

※１：ImageUtils画像処理ライブラリの作者でもあるjunkiさんには、このところかなり甘え気味かも知れないなと反省しています。

●あわや車輪の再発明

自分の問題点は何だろう？何がまずいのだろう？
なんともモヤモヤした気分がずっと続いていました。
いや、おぼろげにドキュメント化がキーワードかなあとか思って
やみくもにGoogle先生に聞こうともしたのですが、
なかなか思うような答えにたどり着けません。困り果てました。

実はかれこれ半月以上は悶々としてたのです。
そしてふいにＵＭＬにたどり着いたのです。
自力で既存の車輪を見つけられたのはある種の奇跡です。
あと少し遅かったら・・・
車輪の再発明 - Wikipedia
(o；ω；o)
四角い車輪の再発明 "en:reinventing the square wheel"
「車輪の再発明」をしようとしてさらに役に立たないものを作ってしまうこと。
・ﾟﾟ・（/□＼*）・ﾟﾟ・

●技術って勉強するためじゃなく使うためにあるんだね

ＵＭＬという言葉はネットでプログラムの情報とか見たりするたびに、
あるいはわんくま同盟の多くの方のエントリーアーカイブにも見かけました。
いつも近くにあったと思います。
でも具体的にこういうところで使う技術だというのは気が付いていませんでした
そして自分がそういう窮地に陥るというのも考えていませんでした。
気分はまさにJ-WALK（※２）

考えたら必要も無いのにエントリー立てたりしませんよね。
それはつまり現実のＳＥの人たちが常にこの問題に直面していることを物語っていたのですね。
言い忘れてたかも知れませんが私は今を生きるＳＥでも何でも無いです。

（※２）http://music.yahoo.co.jp/shop/p/53/11579/Y003959

●そうと決まればさっさと始めよう

今はとりあえず以下のページから勉強を始めました。

http://mamezou.net/modules/xfsection/index.php?category=2&start=10&orderby=weight
http://www.objectclub.jp/technicaldoc/uml/
http://www.asahi-net.or.jp/~DP8T-ASM/java/uml/index.html

良さそうなアプリも見つけました。

http://journal.mycom.co.jp/news/2006/05/23/341.html

●勝手なまとめ

今回は私には使える道具が少なかったのが問題だったと判明しました。
ＵＭＬだけが回答じゃないような気もしています。
でも、まずはＵＭＬで少し自分の把握できる範囲が広がりそうに思いました。

本当はわんくま同盟に居てこんなエントリー書いてたら相当恥ずかしいのは承知しています。
ですが私のように同じ様にハマる人は世の中に私だけじゃないと思うんです。
私はわんくま同盟のほかの人のように難しいことは書けないので、
そういうハマる人たちと同じ立場で色々と体験談を残しておいて、
Google先生がいつか誰かのために役立ててくれる事に期待しようと思います。

それにしても我流独学ってのは引率の先生の居ない児童のようなものです。
自分で言うのもアレですがとても危なっかしいです。
私はほかにも色々当たり前のことに気づいて無いと思うので、
もし危なっかしく車道を歩いているのを見かけたなら、
いつでも遠慮なくクラクションを鳴らしてもらえると助かります（汗

今回はいっぱい突っ込みコメントがありそうでちょっと怖い・・・