Q&A
『オブジェクト指向』タグがあるので、それをつけてみると良いかもです。
オブジェクト指向を学習中の初心者です。クラスとかインスタンスだとか、基本的な概念はそこそこには理解できてるつもりです。
そして、実装にあたってオブジェクト指向のエクササイズの9つのルールなるものを知り、それに関するサイトを色々と見てみました。
そこで、このルールに乗っ取るとたくさんのクラスが生まれ、クライアントから樹木状に伸びていくと思います。そうするとそのプロジェクトを初めて見る人にとっては把握するのがむしろ大変になりませんか？
扱いやすいようにしたとしても中身の細かい仕様を見たいときはあると思いますし、そうしたときにAを理解するにはB1とB2を理解する必要があって、B1にはC1とC2があって...というようでは扱いづらいのではないでしょうか?それとも、この手法は一般的には用いられていないものなのでしょうか？
あ、本当ですね！英語名で検索してました。ありがとございました！
> そのプロジェクトを初めて見る人にとっては把握するのがむしろ大変になりませんか？
質問者さん自身が書かれているように、あくまで「初めて見る人」にとってであって、長らく付き合う人にとってはそうではない可能性の方が高いです。
同じプロジェクトとずっと付き合っていく場合はまさしくそうだと思いますが、他のプロジェクトに取り組んで、またその後前のプロジェクトに戻って機能を取り付けたいとなったとき、それぞれのクラスの仕様やどのオブジェクトがどのオブジェクトに作用しているかなどを覚えているかっていうと厳しいんじゃないでしょうか？不躾な質問でしたら申し訳ないです
クラス分けしてプログラム作っている人達は分ける事が目的ではないですから、分けない方が良いと思えば分けないですよ。
その点について誤解なく質問されてますか？
確かに言われてみればそうですね。
では例えば、「全てのプリミティブ型と文字列型をラップする」というルールなどがありましたが、これもある程度無視しても良いんですかね？個人の裁量である程度柔軟に取り組んでいく形ですか？
不躾な質問とまでは思いませんが、質問の主旨としてはむしろ「オブジェクト指向で細かくクラス分けすることについて、いずれたくさんクラスが分かれてくると、そのプロジェクトを始めて見た、あるいはあまり理解が及んでいない人にとっては理解しづらくないでしょうか？」と言うアンケート的な質問なのでしょうか。つまり、自然とクラスが分かれてきてそのことによるメリットを享受するか否かは問題ではない、と。
分類してわからなくなる規模なら、分類しないともっとわからないと思います。
ああ、hentaimanさんが既にコメントされていましたね。その通りだと私も思っていて、「オブジェクト指向プログラミングをするにはクラスを分けなければいけない」という発想からだと「なぜ分けなきゃいけないの？」の疑問につながります。そうではなく、自然と考えると対象によっては継承を含んだクラス階層になったり別のクラスに自然に分かれていきます。そこまで考える必要が無いならこだわる必要はないです。「オブジェクト指向のエクササイズの9つのルール」とやらを見てみましたが、どちらかというとコーディング標準に近い指針だと思います。
そういう意図ではなくて、自分のスタンスとしてまず複雑に枝分かれしたプロジェクトは作った本人であっても細部まで記憶することは難しいことではないのかというものがあって、分けてメソッドで記述されることによるコード単体の可読性の向上やテストが行いやすいなどのメリットがあるにしても扱いづらさがどうしても無視できないのではないかという質問です。ただ、y_waiwaiさんもおっしゃっていた通り、単純に慣れれば問題になくなるのであればこの質問は解決にさせていただこうかなという思いです
なるほど、分けることは自然に行われるものであって目的になってしまってはいけないんですね。納得しました
複雑に枝分かれし、多くのクラスが密接に依存しあって、すべて記憶しないと読めないのはただの失敗でしょう。適切にカプセル化できていないだけです。
人に何か話すとき、とりとめなく時系列で話しながらあちこちに話が飛ぶようなやりかただとわかりにくくなります。
しかし話の流れと要点を整理し、まず主題が伝わってから細部を説明する方法をとるとわかりやすくなります。
ソースコードを読む際にも、実行される順にひたすらフローを追わなければならないものと、適切にモジュール化されているものでは読みやすさが違います。細かな部分をすべて隠蔽したまま概観をつかむことができれば、細部の実装を飛ばして読むことができます。
細かくクラス分けされていない場合、隠蔽された部分がそれだけ少ないということなので負担は増えます。
確かにそうですね。基本的な部分を失念していました。非常に納得しました。よろしければZuishinさんに回答をしてもらって、BAを差し上げて終了とさせてもらってもよろしいでしょうか？
dodox86さん、hentaimanさんの意見も非常に参考になりました。長い質問に丁寧に答えてくださって本当に助かりました。ありがとうございました。
できれば全員にBA差し上げたい所ですが、個人的に納得のいったZuishinさんにBA差し上げたいと思います。皆さん本当にお付き合いくださってありがとうございました
ここは質問修正依頼のコメントなので、BAにはできませんよ。
設計上、クラスにする必要があるからクラスで分けているだけで、
それ以外の何物でもないと思いますが。
クラスベースなら、クラス中心の設計にならざるを得ないのもありますし、
言語にもよるかと。
クラス分けすることが目的になってはいけないだけであって、
その設計が必要な要件だったからそうした、という基準が、プログラミングには必要だと思います。
他にも有用な回答がつくと思うので、もう少し待ってみたらどうでしょうか。私のコメントは、クラス分けする利点のほんの一部でしかなく、実際にはテストやポリモーフィズムや依存性注入の観点からクラス分けを考えることが多いのではないかと思います。
miyabi_takatsukさん
確かにそうですね。hentaimanさんも仰っていたとおり、手段と目的を履き違えてしまったようです。貴重な意見ありがとうございました。
Zuishinさん
わかりました。もう少し寝かせてみようと思います。ありがとうございます
> 「全てのプリミティブ型と文字列型をラップする」というルールなどがありましたが、
前提条件無しにそれだけ言われても判断つきませんが、問答無用でそれをルールとしているなら間抜けですね。たまたまそれが有効だった開発を経験をした、時の止まったおじいちゃんプログラマーが決めたルールとか？
> 手段と目的を履き違えてしまったようです。
とは言うものの、先人達の経験によって築き上げられたデザインパターンは基本的に有用なものなので、デザインパターンに沿って作る事を目的としても結果オーライな事がほとんどでしょう。
この辺は疑問を感じて質問するよりも手を動かして経験する方が良いかと。
なるほどです。とりあえず、既存のプロジェクトを細かいクラスにリファクタリングしていこうと思います。いざやってみるとどこまで区切ってクラスで取るかなど色々と難しいですが、自分のできる精一杯デザインパターンを踏襲して経験を積んでいこうと思います。
回答4件
0
こんにちは。
クラスを細かく分け、階層構造を作ると追い辛くなるのではという意見は良く理解できます。
しかし、オブジェクト指向におけるクラスの分割、階層化はそもそも「追う」ことを前提にしていません。
「抽象化とは何か」という話になってしまうのですが、クラス分けが実現しているのは「物事を行うために、知らなければならない範囲を小さくする」という概念です。
例えば、とある会社があるとします。この会社の「人事部」に「書類の作成」を依頼する際に、人事部の下に沢山の課があって、どの課にどんな社員が属しているかを考える必要はありません。
例えば、プログラムで「ファイルを読み込む」とき、どうやってファイルパス文字列からデータの格納位置を割り出しているのか知る必要はありません。
例えば、コンピュータを「使う」とき、CPU の中を電気がどのように通っているのかを知る必要はありません。
クラスの分割とは、「知らなければならないこと以外を分離する」という考えのもとで行われるのです。
「A を理解するには B1 と B2 が必要」というのは、言い換えると「A を使うのに B1 と B2 を知る必要はない」ということです。
投稿2020/11/16 01:05
総合スコア4252
補足欄でいろいろな方に教えていただいたのですが、それを実践しているうちに忘れてしまって、返信が非常に遅くなってしまいました。本当に申し訳ないです。
たしかにクラスの基本的な考えってそのとおりですよね。失念しておりました。非常に参考になる意見ありがとうございました。高評価もたくさんついているので非常に迷いましたが、個人的に自分が開発する際にドキュメントを作るという発想がなかったのでBAを他の方につけさせていただきましたが、自分で開発するにしてもそのクラスの内部を把握していなくても使用できるような構造を心がけようと思います。改めて回答ありがとうございました
0
「オブジェクト指向エクササイズ」の9のルールというのは、ToughtWorks アンソロジーという本の中で Jeff Bay 氏が紹介している方法ですが、
これはあくまでも、よいオブジェクト指向プログラミングができるようになるための「練習方法」であって、「思考停止してこれに従っていれば自動的に良いプログラムが出来上がる魔法の方法」ではありませんし、これらのルールはそのまま本番で適用することを意図したものではありません。
他の回答者さんも言っているように、「小さいクラスがふさわしいときは小さくするのが良い。そうでないときは小さいクラスにはしない」というのが実際のプログラマーが考えていることですが、これはトートロジーであって、「どういうときに小さいクラスにするのが良いのか？」「小さいクラスにはどういう利点があって、どういう欠点があるのか？」というのは、実際に自分で小さいクラスを実装してみなければ「体得」することはできません。
詳しいことが知りたれば、書籍を読んでください。ネットでアマチュアが書いた無料の記事や、Q&Aサイトで聞いただけではわからない知識というものは、あります。
投稿2020/11/17 02:02
総合スコア1448
補足欄で皆様に教えていただいたとおり、自分で色々とやっていたら忘れてしまい、返信が遅くなって本当に申し訳ないです。
なるほど、自分でやってみることが大切なのですね。クラスでかくのが億劫になっていましたが、また挑戦してみようと思います。個人的に自分の状況に合う方にベストアンサーをつけさせていただきましたが、非常に参考になる意見でした。ありがとうございました
0
ベストアンサー
そこで、このルールに乗っ取るとたくさんのクラスが生まれ、クライアントから樹木状に伸びていくと思います。そうするとそのプロジェクトを初めて見る人にとっては把握するのがむしろ大変になりませんか？
そのために普通のプロジェクトではドキュメントを作成します。
ドキュメントのスコープや形式は色々ありますが、それらはシステムを理解する手助けをするものである、という共通の目標があります。
あなたのプロジェクトに今後入ってくるメンバーが把握するのが大変だ、と感じるようであれば、把握するために必要になるドキュメントを作成してください。
また、設計段階で抽象化のレベルをちゃんと意識して、適切な命名を行っていれば、ある程度構造を把握するための手助けにもなります。まず抽象度の高いものに着目し、具象的な命名となっているもの（つまり詳細な実装）をひとまず飛ばして読み進めることで、大まかな設計の意図はある程度汲み取れます。
質問文で提起している問題点はクラスの関係性についてのものだと思いますが、これを表現するためのUMLという記法もあります。関係をビジュアルとして表現できるため、ドキュメントとしてUMLを書いたり、コードからUMLを生成するツールを使うなどして、補助的に利用する場合もあります。
投稿2020/11/15 11:42
総合スコア8947
回答有り難うございます！皆さんに補足欄などで教えていただき、自分で色々とやっているうちに回答を見せていただくのが本当に遅くなってしまいました。
ドキュメントを作ろうという意見は非常に納得いたしましたので、ベストアンサーをつけさせていただきます
0
オブジェクト指向やらクラスやらと言っても、コードの構造がわかりやすいようにやってるモノなので、あなたの思うようにすればいいと思います。
まあ、言語の学習度合いや、経験などでそのわかりやすさってのは変わってきますんで、ベテランさんが提唱するわかりやすさってのは初心者のあなたは理解しづらいと思います。
まずはとにかくいろいろやってみて経験を積んでいくことでしょうね
投稿2020/11/15 02:10
総合スコア88053
あなたの回答
tips
プレビュー
