アカウント名:
パスワード:
「一画面に収まらない関数はダメ」とか、「ネストが深ければダメ」とか、これって処理内容を無視した評価基準ではないでしょうか。処理内容によっては、そういったやり方がベストな場合もあると思います。
オブジェクト指向にしてもそうです。アクセッサを使わずに、変数をpublicで公開しても良い場合もあると思います。変数のチェックをしない場合のアクセッサには、どれほどの意味があるのでしょうか?多態性を使わずにswitchで切り替えたほうがシンプルな場合もあります。staticなpublic関数?大いに結構じゃないですか、シンプルで最もオーバーヘッドが小さな実装法だと思います。
画一的な基準で評価するのは工学的アプローチと言えますが、ソフトウェアは芸術的・職人的な側面もありますから。
ほかはともかく、アクセッサに関しては同意できないなぁ……。アクセッサを経由しないメンバ変数へのアクセスを許すと、仕様変更に弱くなりますから。不具合の追及も困難ですし。
メンバ変数がオブジェクトだったらどうですか?
個人的には、「アクセサを使わないと仕様変更に弱くなる」と言う状況なら、メンバ変数にアクセスできると言う点で、アクセサの使用に関わらず、すでに仕様変更には弱い気がする。
まあ、アクセサを使うことはあるけど、仕様変更に強くするためというよりは、値の書き換えの場所を探しやすくするため。
メンバ変数が隠蔽されていれば、メンバ変数の仕様を変更してもアクセサで隠蔽できますが、直接アクセスできるようにしてしまっていた場合にはどうにもならない。って話ですよ。
アクセサとはメンバ変数にアクセスするためのメソッド。インターフェースを実装に依存しないように設計するなら、メンバ変数の存在が分からないわけですから、インターフェースにアクセサと言うものは存在しません。実装レベルでアクセサに相当するものができたとしても、それは結果であって、アクセサを作ろうとしたわけではないのですから、それをアクセサとは呼びたくはありませんし、呼んでもらいたくもありません。
一方で、実装に依存した設計をする場合においては、アクセスを制御しやすいようにアクセサを作ることはありますし、制御する必要がないならメンバ変数をpublicにします。その場合の実装の変更ではクラスの外の変更を伴いますが、あるレベル以上のインターフェースにおいては、何ら変更が生じないわけで、そういうレベルから見れば、単なる実装の変更に過ぎません。
要は、どのレベルのインターフェースを維持するかを考慮することが重要であって、闇雲に実装の隠ぺいを求めれば、単純な処理なのに複雑なコードになって、悪いコードの見本になりますよ。
アクセサを書くのに手間がかからないからと言って、アクセサは実装を隠蔽するのに役に立たないという事実に変わりはない。そもそも、アクセサはメンバ変数へのアクセスを制御するためのものであって、実装を隠蔽するためのものではない。実装を隠蔽しないんだから、仕様変更に強くはない。
もちろん、アクセサは便利だから使うし、簡単に書けるなら、自分にとってそれはありがたいことだけど、アクセサを書く手間は非常に些細な問題でしかない。
もう、それはアクセサじゃないよ。実装が隠蔽されるんだから。
アクセサが実装を隠蔽するためのものだと思っているなら、その考えはさっさと捨てた方がいい。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
UNIXはシンプルである。必要なのはそのシンプルさを理解する素質だけである -- Dennis Ritchie
杓子定規な評価基準 (スコア:3, 興味深い)
「一画面に収まらない関数はダメ」とか、「ネストが深ければダメ」とか、これって処理内容を無視した評価基準ではないでしょうか。
処理内容によっては、そういったやり方がベストな場合もあると思います。
オブジェクト指向にしてもそうです。
アクセッサを使わずに、変数をpublicで公開しても良い場合もあると思います。
変数のチェックをしない場合のアクセッサには、どれほどの意味があるのでしょうか?
多態性を使わずにswitchで切り替えたほうがシンプルな場合もあります。
staticなpublic関数?大いに結構じゃないですか、シンプルで最もオーバーヘッドが小さな実装法だと思います。
画一的な基準で評価するのは工学的アプローチと言えますが、ソフトウェアは芸術的・職人的な側面もありますから。
Re: (スコア:1)
ほかはともかく、アクセッサに関しては同意できないなぁ……。
アクセッサを経由しないメンバ変数へのアクセスを許すと、仕様変更に弱くなりますから。
不具合の追及も困難ですし。
Re: (スコア:0)
メンバ変数がオブジェクトだったらどうですか?
個人的には、「アクセサを使わないと仕様変更に弱くなる」と言う状況なら、メンバ変数にアクセスできると言う点で、アクセサの使用に関わらず、すでに仕様変更には弱い気がする。
まあ、アクセサを使うことはあるけど、仕様変更に強くするためというよりは、値の書き換えの場所を探しやすくするため。
Re: (スコア:0)
メンバ変数が隠蔽されていれば、メンバ変数の仕様を変更してもアクセサで隠蔽できますが、直接アクセスできるようにしてしまっていた場合にはどうにもならない。って話ですよ。
Re: (スコア:0)
アクセサとはメンバ変数にアクセスするためのメソッド。インターフェースを実装に依存しないように設計するなら、メンバ変数の存在が分からないわけですから、インターフェースにアクセサと言うものは存在しません。実装レベルでアクセサに相当するものができたとしても、それは結果であって、アクセサを作ろうとしたわけではないのですから、それをアクセサとは呼びたくはありませんし、呼んでもらいたくもありません。
一方で、実装に依存した設計をする場合においては、アクセスを制御しやすいようにアクセサを作ることはありますし、制御する必要がないならメンバ変数をpublicにします。その場合の実装の変更ではクラスの外の変更を伴いますが、あるレベル以上のインターフェースにおいては、何ら変更が生じないわけで、そういうレベルから見れば、単なる実装の変更に過ぎません。
要は、どのレベルのインターフェースを維持するかを考慮することが重要であって、闇雲に実装の隠ぺいを求めれば、単純な処理なのに複雑なコードになって、悪いコードの見本になりますよ。
Re: (スコア:0)
アクセサはメンバ変数の完全上位互換として使用できるので、外部に公開するものをメンバ変数のままにしておくメリットはどこにもない。そうなってない言語は今すぐ捨てるべき。
Re: (スコア:0)
アクセサを書くのに手間がかからないからと言って、アクセサは実装を隠蔽するのに役に立たないという事実に変わりはない。そもそも、アクセサはメンバ変数へのアクセスを制御するためのものであって、実装を隠蔽するためのものではない。実装を隠蔽しないんだから、仕様変更に強くはない。
もちろん、アクセサは便利だから使うし、簡単に書けるなら、自分にとってそれはありがたいことだけど、アクセサを書く手間は非常に些細な問題でしかない。
Re:杓子定規な評価基準 (スコア:0)
Re: (スコア:0)
もう、それはアクセサじゃないよ。実装が隠蔽されるんだから。
アクセサが実装を隠蔽するためのものだと思っているなら、その考えはさっさと捨てた方がいい。