アカウント名:
パスワード:
「一画面に収まらない関数はダメ」とか、「ネストが深ければダメ」とか、これって処理内容を無視した評価基準ではないでしょうか。処理内容によっては、そういったやり方がベストな場合もあると思います。
オブジェクト指向にしてもそうです。アクセッサを使わずに、変数をpublicで公開しても良い場合もあると思います。変数のチェックをしない場合のアクセッサには、どれほどの意味があるのでしょうか?多態性を使わずにswitchで切り替えたほうがシンプルな場合もあります。staticなpublic関数?大いに結構じゃないですか、シンプルで最もオーバーヘッドが小さな実装法だと思います。
画一的な基準で評価するのは工学的アプローチと言えますが、ソフトウェアは芸術的・職人的な側面もありますから。
void long_line_function() throws LongLineException;void many_lines_function() throws ManyLinesException;
こうですか?わかりません><
一画面というのは変な基準だと思いますがネストが深いのは改善すべきだと私の心のメトリックスは言ってます。ネストを浅くする何らかのロジック変更が効率がよくわかりやすくなることが多いです。経験上ね。
実際、ネストが深くなりすぎると”大本(1階層目)の判定基準がなんだったか解らなくなりがち”ですからね。特に他人のコードだと。
1画面も変な基準ですが、余りに階層が深くなったり、IFの中が長すぎるなら、関数化して、大本には何をしたいか、何を関数化したかコメントした方が、可読性は上がると思います。
「一画面に収まる」は前世紀ではそれなりに意味のある基準でした。パンチカードでプログラムを入力していた頃は物理的に80桁に収めねばなりませんでしたし、コーディングやメンテを粗末なキャラクタ端末とviで行なっていた頃は80桁を超えて行が折り返してしまうとまともに編集出来ない場合がありました。今となっては何の意味もないわけですが。
今となってもコードレビューのために1画面、1ページに収めてとかの要望がありますよ。杓子定規に真丸必要はないとは思っていますが。
ほかはともかく、アクセッサに関しては同意できないなぁ……。アクセッサを経由しないメンバ変数へのアクセスを許すと、仕様変更に弱くなりますから。不具合の追及も困難ですし。
「こんな事もあろうかと」と言いたいがために、あるかどうかわからない将来の拡張に備えて、余分なコードを追加するというのはむやみにコードが間延びして、良くないです。拡張が必要になった時に、ごっそり書き換えれば済む話です。
だから、パラメータを右から左に渡すだけのアクセッサーには反対です。(逆に、値チェック以上の重たい処理をアクセッサーに入れるのも別の理由でダメ)
ただし、不特定多数に公開されるライブラリーにおいてはこの限りではなく、予防的にアクセッサーにするのはありだと思います。
そもそも、オブジェクト指向技術は基本的にライブラリーを作る場合に必要な技術であり、普通のプログラムでの使用は、弊害のほうが大きのではないかと思います。
C#みたいに言語で保障すべきなんだよなー
メンバ変数がオブジェクトだったらどうですか?
個人的には、「アクセサを使わないと仕様変更に弱くなる」と言う状況なら、メンバ変数にアクセスできると言う点で、アクセサの使用に関わらず、すでに仕様変更には弱い気がする。
まあ、アクセサを使うことはあるけど、仕様変更に強くするためというよりは、値の書き換えの場所を探しやすくするため。
メンバ変数が隠蔽されていれば、メンバ変数の仕様を変更してもアクセサで隠蔽できますが、直接アクセスできるようにしてしまっていた場合にはどうにもならない。って話ですよ。
アクセサとはメンバ変数にアクセスするためのメソッド。インターフェースを実装に依存しないように設計するなら、メンバ変数の存在が分からないわけですから、インターフェースにアクセサと言うものは存在しません。実装レベルでアクセサに相当するものができたとしても、それは結果であって、アクセサを作ろうとしたわけではないのですから、それをアクセサとは呼びたくはありませんし、呼んでもらいたくもありません。
一方で、実装に依存した設計をする場合においては、アクセスを制御しやすいようにアクセサを作ることはありますし、制御する必要がないならメンバ変数をpublicにします。その場合の実装の変更ではクラスの外の変更を伴いますが、あるレベル以上のインターフェースにおいては、何ら変更が生じないわけで、そういうレベルから見れば、単なる実装の変更に過ぎません。
要は、どのレベルのインターフェースを維持するかを考慮することが重要であって、闇雲に実装の隠ぺいを求めれば、単純な処理なのに複雑なコードになって、悪いコードの見本になりますよ。
「アクセサを使わないと仕様変更に弱くなる」といったのが気に障ったなら、「メンバ変数を直接アクセスするインタフェースは仕様変更に弱くなる」といってもイイよ。
アクセサを書くのに手間がかからないからと言って、アクセサは実装を隠蔽するのに役に立たないという事実に変わりはない。そもそも、アクセサはメンバ変数へのアクセスを制御するためのものであって、実装を隠蔽するためのものではない。実装を隠蔽しないんだから、仕様変更に強くはない。
もちろん、アクセサは便利だから使うし、簡単に書けるなら、自分にとってそれはありがたいことだけど、アクセサを書く手間は非常に些細な問題でしかない。
もう、それはアクセサじゃないよ。実装が隠蔽されるんだから。
アクセサが実装を隠蔽するためのものだと思っているなら、その考えはさっさと捨てた方がいい。
仕様変更が入らない箇所をあらかじめ見極められるケースなら大丈夫でしょ?よく言われるのは、24ビットRGBの各色のバイト値とか、3次元での位置を表すクラスとか。
でも、そんなクラスは少ししかないし、アクセッサを使わなかった弊害が大きすぎるので、プログラマの質が確保できないプロジェクトなら、アクセッサ必須は同意できる。
アクセッサ必須のルールを採用したプロジェクト(質が確保できないプロジェクト)からは、ボレロの太鼓の音に合わせて行進しだした感じがする。# タン、タタタ、タン、タタタ、タンタン……
最近の言語って専用のアクセサメソッド構文とかがあって、そういう場合でも文法的に同じに扱えるようになってない?Javaとかは今でもそういう構文なくてひたすら setXXX(), getXXX() なんだっけ(最近のはよく知らない)
アクセサにしておけば、(クラス継承型の言語の場合)派生クラスとか(プロトタイプ型言語の場合)クローン後のオブジェクトで振る舞いを変えることできますよね。インターフェース志向ってやつですね。
>変数のチェックをしない場合のアクセッサには、どれほどの意味があるのでしょうか?
ブレークポイント設定できる。え?ウォッチ式でいいじゃんって?
要するに、複雑なコードとは何かが定まらないと議論にならないよね。まあ、そこから議論を始めるってことになるんだろうけど。
なんでそんなの読むのがデフォなんだ?
雑談が広まらないじゃないか
タレコミeggy / 編集hylomで元ソースをあたらないなんてありえんだろ。
なんで威張ってると思うんだ?
アスペ乙。
複雑なニュースには複雑な記事が必要
とりあえず「アクセッサ」の「ッ」について説明を要求したい。
自分は「アクセッサ」の呼び名で覚えましたが、最近はアクセサが主流なんですかね。プロセッサに倣ったものでしょうかね。
「マジックナンバー7±2」という人間の能力の限界がありますが、これを考えると、一画面に収まるとか、深すぎるネスト、といったものには、それなりに根拠があるのかもしれません。(・∀・)
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
私はプログラマです。1040 formに私の職業としてそう書いています -- Ken Thompson
杓子定規な評価基準 (スコア:3, 興味深い)
「一画面に収まらない関数はダメ」とか、「ネストが深ければダメ」とか、これって処理内容を無視した評価基準ではないでしょうか。
処理内容によっては、そういったやり方がベストな場合もあると思います。
オブジェクト指向にしてもそうです。
アクセッサを使わずに、変数をpublicで公開しても良い場合もあると思います。
変数のチェックをしない場合のアクセッサには、どれほどの意味があるのでしょうか?
多態性を使わずにswitchで切り替えたほうがシンプルな場合もあります。
staticなpublic関数?大いに結構じゃないですか、シンプルで最もオーバーヘッドが小さな実装法だと思います。
画一的な基準で評価するのは工学的アプローチと言えますが、ソフトウェアは芸術的・職人的な側面もありますから。
Re:杓子定規な評価基準 (スコア:2)
結果、殆どの関数が50行で足りない物が結構出て来たなぁ
Re: (スコア:0)
void long_line_function() throws LongLineException;
void many_lines_function() throws ManyLinesException;
こうですか?わかりません><
Re:杓子定規な評価基準 (スコア:1)
一画面というのは変な基準だと思いますが
ネストが深いのは改善すべきだと私の心のメトリックスは言ってます。
ネストを浅くする何らかのロジック変更が効率がよくわかりやすくなることが多いです。
経験上ね。
Re: (スコア:0)
実際、ネストが深くなりすぎると”大本(1階層目)の判定基準がなんだったか解らなくなりがち”ですからね。
特に他人のコードだと。
1画面も変な基準ですが、余りに階層が深くなったり、
IFの中が長すぎるなら、関数化して、大本には何をしたいか、何を関数化したか
コメントした方が、可読性は上がると思います。
Re:杓子定規な評価基準 (スコア:1)
「一画面に収まる」は前世紀ではそれなりに意味のある基準でした。パンチカードでプログラムを入力していた頃は物理的に80桁に収めねばなりませんでしたし、コーディングやメンテを粗末なキャラクタ端末とviで行なっていた頃は80桁を超えて行が折り返してしまうとまともに編集出来ない場合がありました。今となっては何の意味もないわけですが。
Re: (スコア:0)
今となってもコードレビューのために1画面、1ページに収めてとかの要望がありますよ。
杓子定規に真丸必要はないとは思っていますが。
Re:杓子定規な評価基準 (スコア:1)
ほかはともかく、アクセッサに関しては同意できないなぁ……。
アクセッサを経由しないメンバ変数へのアクセスを許すと、仕様変更に弱くなりますから。
不具合の追及も困難ですし。
Re:杓子定規な評価基準 (スコア:1)
「こんな事もあろうかと」と言いたいがために、あるかどうかわからない将来の拡張に備えて、余分なコードを追加するというのはむやみにコードが間延びして、良くないです。拡張が必要になった時に、ごっそり書き換えれば済む話です。
だから、パラメータを右から左に渡すだけのアクセッサーには反対です。(逆に、値チェック以上の重たい処理をアクセッサーに入れるのも別の理由でダメ)
ただし、不特定多数に公開されるライブラリーにおいてはこの限りではなく、予防的にアクセッサーにするのはありだと思います。
そもそも、オブジェクト指向技術は基本的にライブラリーを作る場合に必要な技術であり、普通のプログラムでの使用は、弊害のほうが大きのではないかと思います。
Re: (スコア:0)
C#みたいに言語で保障すべきなんだよなー
Re: (スコア:0)
メンバ変数がオブジェクトだったらどうですか?
個人的には、「アクセサを使わないと仕様変更に弱くなる」と言う状況なら、メンバ変数にアクセスできると言う点で、アクセサの使用に関わらず、すでに仕様変更には弱い気がする。
まあ、アクセサを使うことはあるけど、仕様変更に強くするためというよりは、値の書き換えの場所を探しやすくするため。
Re: (スコア:0)
メンバ変数が隠蔽されていれば、メンバ変数の仕様を変更してもアクセサで隠蔽できますが、直接アクセスできるようにしてしまっていた場合にはどうにもならない。って話ですよ。
Re: (スコア:0)
アクセサとはメンバ変数にアクセスするためのメソッド。インターフェースを実装に依存しないように設計するなら、メンバ変数の存在が分からないわけですから、インターフェースにアクセサと言うものは存在しません。実装レベルでアクセサに相当するものができたとしても、それは結果であって、アクセサを作ろうとしたわけではないのですから、それをアクセサとは呼びたくはありませんし、呼んでもらいたくもありません。
一方で、実装に依存した設計をする場合においては、アクセスを制御しやすいようにアクセサを作ることはありますし、制御する必要がないならメンバ変数をpublicにします。その場合の実装の変更ではクラスの外の変更を伴いますが、あるレベル以上のインターフェースにおいては、何ら変更が生じないわけで、そういうレベルから見れば、単なる実装の変更に過ぎません。
要は、どのレベルのインターフェースを維持するかを考慮することが重要であって、闇雲に実装の隠ぺいを求めれば、単純な処理なのに複雑なコードになって、悪いコードの見本になりますよ。
Re: (スコア:0)
「アクセサを使わないと仕様変更に弱くなる」といったのが気に障ったなら、
「メンバ変数を直接アクセスするインタフェースは仕様変更に弱くなる」といってもイイよ。
Re: (スコア:0)
アクセサはメンバ変数の完全上位互換として使用できるので、外部に公開するものをメンバ変数のままにしておくメリットはどこにもない。そうなってない言語は今すぐ捨てるべき。
Re: (スコア:0)
アクセサを書くのに手間がかからないからと言って、アクセサは実装を隠蔽するのに役に立たないという事実に変わりはない。そもそも、アクセサはメンバ変数へのアクセスを制御するためのものであって、実装を隠蔽するためのものではない。実装を隠蔽しないんだから、仕様変更に強くはない。
もちろん、アクセサは便利だから使うし、簡単に書けるなら、自分にとってそれはありがたいことだけど、アクセサを書く手間は非常に些細な問題でしかない。
Re: (スコア:0)
Re: (スコア:0)
もう、それはアクセサじゃないよ。実装が隠蔽されるんだから。
アクセサが実装を隠蔽するためのものだと思っているなら、その考えはさっさと捨てた方がいい。
Re: (スコア:0)
+αの説明なしに、あれをカプセル化とか言ってるような声のでかいのかいるから、Javaしかやってないって人のレベルは、9割ぐらいの確率で底辺確定なんだよな。
Re: (スコア:0)
仕様変更が入らない箇所をあらかじめ見極められるケースなら大丈夫でしょ?
よく言われるのは、24ビットRGBの各色のバイト値とか、3次元での位置を表すクラスとか。
でも、そんなクラスは少ししかないし、アクセッサを使わなかった弊害が大きすぎるので、
プログラマの質が確保できないプロジェクトなら、アクセッサ必須は同意できる。
アクセッサ必須のルールを採用したプロジェクト(質が確保できないプロジェクト)からは、
ボレロの太鼓の音に合わせて行進しだした感じがする。
# タン、タタタ、タン、タタタ、タンタン……
Re: (スコア:0)
最近の言語って専用のアクセサメソッド構文とかがあって、
そういう場合でも文法的に同じに扱えるようになってない?
Javaとかは今でもそういう構文なくてひたすら setXXX(), getXXX() なんだっけ(最近のはよく知らない)
Re: (スコア:0)
アクセサにしておけば、(クラス継承型の言語の場合)派生クラスとか(プロトタイプ型言語の場合)クローン後のオブジェクトで振る舞いを変えることできますよね。インターフェース志向ってやつですね。
Re:杓子定規な評価基準 (スコア:1)
>変数のチェックをしない場合のアクセッサには、どれほどの意味があるのでしょうか?
ブレークポイント設定できる。
え?ウォッチ式でいいじゃんって?
屍体メモ [windy.cx]
Re: (スコア:0)
要するに、複雑なコードとは何かが定まらないと議論にならないよね。
まあ、そこから議論を始めるってことになるんだろうけど。
Re:杓子定規な評価基準 (スコア:1)
なんでそんなの読むのがデフォなんだ?
the.ACount
Re: (スコア:0)
雑談が広まらないじゃないか
Re: (スコア:0)
タレコミeggy / 編集hylom
で元ソースをあたらないなんてありえんだろ。
Re:杓子定規な評価基準 (スコア:1)
なんで威張ってると思うんだ?
the.ACount
Re: (スコア:0)
アスペ乙。
Re: (スコア:0)
複雑なニュースには複雑な記事が必要
Re: (スコア:0)
とりあえず「アクセッサ」の「ッ」について説明を要求したい。
Re: (スコア:0)
自分は「アクセッサ」の呼び名で覚えましたが、最近はアクセサが主流なんですかね。
プロセッサに倣ったものでしょうかね。
マジックナンバー7±2 (スコア:0)
「マジックナンバー7±2」という人間の能力の限界がありますが、これを考えると、一画面に収まるとか、深すぎるネスト、といったものには、それなりに根拠があるのかもしれません。(・∀・)