実行制限のある関数の記述方法

例えば変数aが有効なときにのみ動作すべき関数xがあったとします。
この場合、以下の2パターンの書き方ができると思うのですが、どちらの書き方がよいでしょうか。

1.呼び出し元で変数aを判定してからxを呼び出す

c
1main()
2{
3	if(a){
4		x();
5	}
6}
7
8x()
9{
10	// 処理
11}

2.x内でaを判定し、無効なら処理しない

c
1main()
2{
3	x();
4}
5
6x()
7{
8	if(a){
9		// 処理
10	}
11}
12もしくは
13x()
14{
15	if(!a) return;
16	// 処理
17}

1は、
xを呼び出す理由が明確であるが、呼び出し元が煩雑である。

2は、
xの呼び出し元はすっきり書けるが、処理が不要な場合でもxを呼んでしまう。

個人的にはプログラマの意図がわかる1を推したいですが、安全面で言えば2なんだと思います。
1と2をあわせるのが一番無難だと思いますが、過剰な気もします。
またこのようなデザインパターンを紹介している文献などありましたら教えてください。

Stripe

2017/10/13 09:15

変数aと関数xの関係は？

行動規範の内容に同意します

回答5件

ベストアンサー

もし関数xがガッツリ変数aに依存している場合は、
関数x内で止めれば良く、2は有力な選択肢かと思います。

しかし、関数xは変数aの値によらず動作可能であれば2はありえません。
何の関係もない変数aが横から出てきて、関数xの動作をせき止めるのは、
関数xの挙動や可能性が大幅に制限され、実行すべき所で実行出来なくなる危険があります。

私の考えは1寄りですね。
mainは関数x実行前に変数aを確認しておくべきでしょう。
信号を見もせずに横断歩道を渡り始め、クラクションを鳴らされ慌てて戻るようなものですからね。

コードリーディングの時も
関数xにジャンプしにいって読みに行ったものの、
最初の行で変数aにせき止められて何も動作せずに戻って来ることになります。
読みに行かなきゃよかった。

意味のない往復をやることになるので、
if (a) x();程度で済むならmainにif文を書いた方が可読性が上がる可能性もあります。

しかし、2の思想の設計も数多くあります。
HaskellのモナドやJavaScriptライブラリのjQueryでは
とりあえず実行してみて、失敗しても安全に着地してくれるという設計で作られています。

これはこれで一貫していて美しいので、
最終的には好みやプロジェクトでの合意に落ち着く問題かと思います。

もし1を採用した場合、頻度次第では憂鬱になるかと思います。
頻度が多い場合の回避策としてこんな手法を考えました。

C
1main ()
2{
3  try_x();
4}
5
6try_x ()
7{
8  if (a) x();
9}
10
11x ()
12{
13  // 処理
14}

関数xをラッピングし、変数aの顔色を伺う関数try_xを登場させます。
こうすることで、関数xはシンプルに保たれますし、mainもとりあえず関数xを呼んでみるという使い方ができるようになります。

投稿2017/10/13 07:34

編集2017/10/13 08:18

miyabi-sun

総合スコア21158

ttyp03

2017/10/13 07:45

やはりaがどれだけxに依存しているかが判断材料になりますか。ラッパー化するアイデアは思いつきませんでした。処理の部分が重ければ可読性の向上も見込めそうです。

ttyp03

2017/10/13 07:52

編集ありがとうございます。色々な意見を聞きたかったので、特に前提条件はありません。 xとaの依存度、呼び出し元の数など。横断歩道の例えが笑えましたｗうまい。

miyabi-sun

2017/10/13 07:58

一旦これで編集完了とします。横断歩道の考え方も、HaskellのモナドやJSライブラリのjQueryはこの思想で、とりあえず試してみて、ダメでも値無しのまま安全に着地する設計思想ですね。一貫していれば美しいと思います。究極的には好みかもしれませんね。

miyabi-sun

2017/10/13 08:05

やっぱり信号の下りは混ぜちゃダメだと思うので編集します。

行動規範の内容に同意します

例外処理のないC言語では、呼び出し先でエラーが発生した場合に予期せぬ動作を起こす可能性があります。
それを防ぐために可能な限りエラーチェックをした上で関数呼び出しを行うということは不測の事態に備えるためには有効なアプローチかと思います。
なので、基本的には1.の方の対処とした方がよいかと思います。

引数にnullを渡すと落ちる関数があるとして、nullで落ちるのが悪いのか、nullを渡すのが悪いのかというところです。
これはたとえ例外処理を実装した言語であったとしても、どちらかといえば呼び出し元がきちんと対応すべきものだと思います。
関数xはあれもこれも全部をお世話してあげられるわけでもありません。
もちろん、関数xはそのような制約があることを説明すべきだとも思います。

ただし、すべてのエラーの可能性を事前にチェックできるかというと、それも困難です。
十分チェックしていても、それでもエラーが起きるような場合にどのように対処するかといった話は、下記のページ等が参考になるかと思います。

IPA ISEC　セキュア・プログラミング講座：C/C++言語編　第6章フェイルセーフ：体系だてたエラーハンドリング

投稿2017/10/13 06:54

編集2017/10/13 06:58