プログラマというお仕事

 コメント一覧 (13)

1. • 1. ohfuji
   • 2013年09月24日 18:34
   • はじめまして、調べごとをしていて見つけました。１点コメントがあります。
     
     ＞オブジェクトの状態が不定になる可能性がひとつだけ残っています。
     
     「一つだけ」と言われていますが、実装によりますが、残念ながら他にもオブジェクトの状態が不定になる可能性が少なくとも１つあります。もう少し正確に説明すると状態が不定にならないようにすると面倒な問題が出てきます。
     オブジェクト指向プログラミングの難しいところの１つは、こういった理想（カプセル化）と現実（日付クラスの実現）のギャップにあります。カプセル化をきちんと行うにしても現実には漏れが発生し簡単な例でも開発が面倒になるところです。
     
     上記の点についてコメント頂ければと思います。
     
2. • 2. 管理人
   • 2013年11月21日 19:29
   • ohfuji様
     当ブログにコメントを頂きありがとうございます。すっかり放置状態なのでコメントに気付くのが遅くなってしまいました。大変申し訳ありません。
     
     さて、「他にもオブジェクトの状態が不定になる可能性がある」とのことですが、出来ましたらそのようなケースについて具体的にお教え頂くことはできますでしょうか。当方としても非常に興味のある話ですので、ぜひ参考にさせて頂ければと思います。
3. • 3. ohfuji
   • 2013年11月21日 22:46
   • ごく基本的なことなのでご自身で見つけてほしかったのですが、以下が例になります。
     
     MyDate d = new MyDate(); // 2000/1/1
     d.addDay(30); // 2000/1/31
     d.setMm(2); // 2000/2/31 ?
     
     予め補足しますと、私が指摘している問題点は、日付関係のクラスを作成する際に、setYyやsetMmなどの特定の要素を設定するようなメソッドを作ることが不適切ということです。.Netの日付クラスを参照してみて下さい。
     
     一つ質問しますが、管理人さんはクラスを作ったことがありますでしょうか？あればどういったクラスを作ったか教えて下さい。
     
4. • 4. ymstry
   • 2014年07月03日 18:41
   • ohfuji様
     横からレスポンスすみません。
     
     以下はこのブログを最初から拝見していた感想です。
     2000/2/31というものが発生しないように、制御するための「カプセル化」ではないでしょうか？
     
     かなり昔の書き込みなので、見てないとは思います。
     管理人だけでもレスしていただけると嬉しいです。
5. • 5. ohfuji
   • 2014年07月03日 20:51
   • ymstryさん
     
     >2000/2/31というものが発生しないように、制御するための「カプセル化」ではないでしょうか？
     
     ということであれば、
     
     MyDate d = new MyDate(); // 2000/1/1
     d.addDay(30); // 2000/1/31
     d.setMm(2);
     
     で、d.setMm(2)を呼び出した後、dには何が入るべきでしょうか？またsetMmはエラー処理を行うとしたらどのように行えばよいでしょうか？
     
6. • 6. 管理人
   • 2014年09月23日 19:14
   • ymstry様
     
     コメント頂きありがとうございます！おっしゃるとおりです。
     この「超入門」シリーズの第４回の記事に書いたとおり（また当記事の始めにも、おさらいの意味でサラっと書いてますが）2月31日とならないように setMm() 関数の中で引数の値をチェックして、何かしらの対処をしておくべきだと言っています。
     
     「何かしらの対処」とは、例えばmmを2にすると同時にddには28を代入してしまうとか、あるいは変数の値は変更せずに、いっそ例外を返してしまう方がいい場面だってあるかもしれません。もっと言うとそもそもmmやddを別個にセット出来るようにするのが間違いで
     setMmDd(int mm, int dd) という関数で月日を常にペアでセットさせるようにする手だって考えられます。
     
     これらの対処の方法はオブジェクト指向的にはどれが正解というのはありません。記事では説明のために日付というかなり単純なデータの例を使っていますが、実際のアプリケーション開発では、このようなクラスの挙動は対象の業務の仕様により決まります。業務にとってふさわしい挙動となるようクラスを設計すればいい話です。
     オブジェクト指向的な観点から言える事はただ一つ、とにかく「2月31日みたいなおかしな状態のオブジェクトが、一時たりとも生存している状態だけは避けなければいけない」という点です。
     
7. • 7. ohfuji
   • 2014年09月23日 20:48
   • 久しぶりにご返信がいただけましたが、
     ＞これらの対処の方法はオブジェクト指向的にはどれが正解というのはありません。
     
     ということではなく、私のコメントを繰り返しますが、setYyやsetMmなどの特定の要素を設定するようなメソッドを作ることが不適切ということです。
     例外を発生させるとか28をセットするとかがダメということです。なぜダメか解りますでしょうか？
     ちなみに、
     setMmDd(int mm, int dd)
     もダメですね、理由は解りますでしょうか？
     
     堂々巡りになりますので正解を書きますと
     
     ＞「2月31日みたいなおかしな状態のオブジェクトが、一時たりとも生存している状態だけは避けなければいけない」
     
     というような条件をオブジェクトに課した場合、setYyyyMmDdのように年月日を同時にセットしなければ一貫性が保てないということです。
     
     これがオブジェクト指向の難しいところです。カプセル化を徹底させ、きちんと動かすには適切なインタフェースを作成しなければダメですが、これには経験が必要で、一見動作するように見えるが実は思わぬバグが入ったクラスを作ってしまう訳です。28や例外を入れるとクライアントプログラムで思わぬ不具合が生じることになるでしょう。
     
     管理人さんはこのMyDateクラスを業務で使用したことがあるでしょうか？
     あるとすればどのようなエラー処理を追加されたのでしょうか？
8. • 8. wat
   • 2014年11月23日 20:21
   • MyDate d = new MyDate(); // 2000/1/1
     d.addDay(30); // 2000/1/31
     d.setMm(2); // 2000/2/31 ?
     
     って、何だ？
     そもそも、MyDate d= new MyDate();は２０００／１／１にはならない。
     このクラスには、コンストラクタが設定されていないんだからwww
     
     したがって２行目ですでにこのシステムは破綻している。
     したがって、メソッドによるバグ回避策が破綻する可能性がでてくるのは、newした直後であり、管理人氏の
     『オブジェクトの状態が不定になる可能性がひとつだけ残っています。それはオブジェクトをnewした直後です。』
     という命題は、論破されていない。
     
     
     
9. • 9. 管理人
   • 2015年10月07日 17:01
   • ブログアンテナ登録のご連絡 お世話になります。貴サイト拝見しまして、同様のテーマを集めたニュースサイトを運営配信しております。非常に良いコンテンツを配信されており勝手ながらアンテナに追加させていただきました。(以下URLのヘッダはスパム対策で外しています）quiccastarter245.kiramori.net/an/anprogram/　相互リンクぜひご検討いただければ幸いです。管理人
10. • 10. root
    • 2016年05月03日 15:55
    • バースデーといった日付の場合、それをセットするメソッドはその日付が実在するかどうかをチェックすればいい。ということですね。
      setLenient()なんてのがあるんだからそれを使えばいいと。
      しかしGoogleって便利ですね。
      
11. • 11. 管理人
    • 2016年05月05日 02:10
    • root様
      当ブログにコメント頂きありがとうございます。
      
      ＞日付が実在するかどうかをチェックすればいい
      まあ、この場合そういう事になりますね。
      より一般的には、クラスの複数のメンバ変数が互いに矛盾した値にならないようチェックする、という事です。
      
      説明の為の例を日付という単純すぎるデータにしてしまったからなのか何なのか、記事の主旨とは全く関係ないピントはずれな攻撃をしてくるバカがいて話が随分それてしまった感がありますね。より平たく言えば、変数がおかしな値にならないようにする、というただそれだけの事なんですけどね。
12. • 12. nbs
    • 2016年06月28日 21:54
    • 記事拝見しました。オブジェクトの主体性を保持したいというオブジェクト指向の本質を見抜いている、非常に納得のいく説明でした。
      
      さて、Ohfujiさんのコメントについてですが、構造化プログラミングでの業務を長くされてきたように感じます。
      みなさん言ってらっしゃる通りsetプロパティに例外処理を記述せねばならないのは間違いないでしょう。
      Ohfujiさんは、この例外処理を、変数を一つに纏めてsetプロパティを一元化し、1箇所に記述したいのではないでしょうか。
      
      しかし、それはやはりオブジェクトをまとめて例外処理に投げるという構造化プログラミング的視点のように思えます。
      オブジェクト指向的には年月日はそれぞれ独立して機能する必要があるのではないでしょうか。
      その観点からいえば、年月日はそれぞれ分けてプロパティを定義した後で、それぞれのsetプロパティに例外処理を記述する方が好ましいと思います。
13. • 13. 管理人
    • 2016年06月30日 02:44
    • nbs様
      当ブログにコメント頂きありがとうございます。
      少しでも参考になられた点がありましたら嬉しいです。
      
      当ブログの記事の中でもこの記事が一番反響があるようで、多くのご意見を頂いています。
      日付を題材にしてしまった事による混乱もあるように思います。
      一般的なクラスの話として「クラスには全てのメンバ変数をまとめてSetする関数を１つだけ作るべきです。じゃないと一貫性（って何の事かわからんが）が保てませんよ」と言われたら、賛成する人はまぁいないでしょう。
      
      反省の意味で、基本的には全く同じ主旨の内容を別の題材を例にしてあらためて書いてみようかとも考えています。