プログラミングの設計が分からない

テーマ、知りたいこと

設計は何に着目すればいいのでしょうか。
オブジェクト指向などの本も読んでみましたがよくわからないです。

vendingMachine (自動販売機) を例にとると

① 仕様に着目 (動詞メソッド風?)
(1) storeJuice ジュースを保管する
(2) coolJuice ジュースを冷やす
(3) checkPayment 支払いを確認する
(4) outputJuice ジュースを排出する

② 場所に着目 (名詞クラス風?)
(1) juiceStore ジュースの保管場所
(2) cooler ジュースの冷却器
(3) moneyBox 金銭管理箱
(4) vent ジュースの排出口

③ 目的物に着目 (名詞データが主役のクラス風?)
(1) storedJuice 保管されたジュース
(2) coolingJuice 冷やされたジュース
(3) boughtJuice 支払いが確認されたジュース
(4) outedJuice 排出されたジュース

本やネットでクラスが名詞でメソッドが動詞と学びましたが
どうにでも書けてしまえませんか？
それとも何か基準やルールでもあるのでしょうか。
着目するところやコツがあれば教えていただきたいです。

追記1
"どうにでも" というのは少々乱暴な言い方でした。すみません。
言いたいことは、自動販売機の例でいうところの、仕様に着目しても場所に着目しても目的物に着目しても分かりやすさと保守性があれば、どのような設計を選んでも構わないのかということです。

追記2
着目したテーマ(仕様/場所/目的物 etc.)によって、同じ動きをするプログラミングの関数名が動詞句(メソッド)になることも名詞句(クラス)になることもあるということなのでしょうか。(例えば、juiceStoreクラスにcountJuiceメソッドがあったとして、構成によってはjuiceStoreコンポーネントのjuiceCounterクラスにもなる？)

追記3
#6を読んで疑問に思ったのですが、クラスは「AはBをする」に縛られるのでしょうか。「AがBになる」で作らないほうがいいのでしょうか。例えば、ぬるいジュースから冷たいジュースになるということで normalTemperatureJuice クラスと coolingJuice クラスを作るという設計はNGですか。

追記4

0. 状況整理

悩む方向が間違っているのかもわかりませんが、悩んでいることをまとめ直しました。
(1) シナリオの着眼点
(2) クラス(名詞句)/メソッド(動詞句)の使い分け
(3) 共通クラス/メソッドの置き場とネーミング

※青は名詞句黄緑は動詞句。

1. 設計の大枠

vendingMachineの大枠を実体面(ハードウェア)から考えた。

さらにvendingMachineの大枠を動作面(SVO)から考え直した。

疑問①-1: SVOからのアプローチの語法
「vendingMachineのオーナーがjuiceを追加した。」という動作面(SVO)からのアプローチでは、juiceクラスがjuiceSettingのようなネーミングになるのか。storeManagement とstoreManager ではどちらになるのか。一般的なルールはあるのか(そもそも、クラスの命名自体もわかっていない。)

疑問①-2: 着眼点の違うシナリオの混在 1/2 (粒度の等しいクラス)
自販機の実体面からアプローチしたクラスとオーナーの動作面からアプローチしたクラスの混在など、着眼点の違いがあるクラスの併存はよくあることなのか、避けていることなのか、例外的に事情があれば許容されるのか。(実体面に着目しても動作面に着目しても、どのようにも書けるのではないかという疑問はこのようなことに端を発している。)シナリオに制約や経験則的に破綻しやすいケースはあるのか。

2. 汎用性があるクラスへの再編

juiceクラスは汎用性が無いため、itemクラスに再編した。
ここではoden(おでん)はfoodのほうが良いのではないかという再々編の余地を残しているがこの設計で大きな影響はない。

疑問②-1: 着眼点の違うシナリオの混在 2/2 (クラスとメソッド)
自販機の実体面から考えられたクラス内にオーナーの動作面から考えられたメソッドという、以下のような構成もありえるのか。

処理過程も見方によっては目的となり、また逆もあり、名詞句なのか動詞句なのかの違いだけで内容が同じ関数に関してクラスとメソッドには大きな隔たりが無いように感じているが、どのようにクラスとメソッドの住み分けを進めればいいのか。
一旦すべての構成をドメイン/クラスとった樹形図のような名前空間に落とし込み、そこからさらに”名前空間をつくる程でもない処理”をメソッドとして扱っても設計できそうだが、メソッドはそのように捉えるべきではないのか。

3. 共通するメソッドの扱い 1

各クラスに以下のメソッドが付加された。

処理が共通するおまけ飴メソッドのaddRedCandyとaddBlueCandyを一つのaddCandyメソッドにまとめitemクラス配下とした。

疑問③-1: 関連度/粒度/抽象度
addCandyメソッドはjuiceクラスとtoyクラスで使われodenクラスには使われないが、配置する場所はitemクラス下で良いのか。それともjuice/oden/toy の粒度や抽象度に合わせてcandyクラスやadditionクラスを作り管理すべきなのか。

疑問③-2: メソッドの拡張性
addCandyメソッドにredやblueといった名詞句のタグ付けは可能か。(メソッド(動詞句) = 構成の行き止まりのようなイメージがあるのですがそんなことは無いですか。)addCandyメソッドに拡張性がないのであれば、candyクラスにしてしまうべきか。

疑問③-3: 冗長性
構成を厳密にしていくとitem/shared/addition/candy/redクラスを拾うことになるが名前空間や関数名は長くなっても構わないのか。引数は4つまでが良いと何かの本で読んだことがあったが、名前空間も読みやすさなどのルールがあるのか。

4. クラスの拡張

additionクラスをsharedクラスに拡張した。
banUpsidedown(天地無用)メソッドもoden以外にも使えそうな抽象性のあるメソッドなのでadditionクラスをsharedクラスとしてこれに移動させた。

疑問④-1: カプセル化と汎用性
オブジェクト指向(カプセル化)と汎用性のあるメソッドに親和性はあるのか。
汎用性のあるメソッド作るほど、元のクラスの中身が減っていくわけで、そうなると行程がいくつもあり肥大化したクラスを除いて、カプセル化を目指さないほうが無難なのではないか。

疑問④-2: 汎用性のあるメソッドのネーミングと名前空間 1/2
共用になりそうなしかし共用になっていないメソッドの配置とネーミングが悩ましいがどうすべきか。shared? option? 一度しか使わないようなメソッドもクラスやメソッドの粒度や抽象度を揃えたとき(シーケンスのレベルや位置が同じとき)共用クラスの中に入るなら、入れるべきなのか。

5. 共通するメソッドの扱い 2

itemが自販機にあるのか無いのかを返すexistItemメソッドを追加した。
itemに関わることなのでitemクラスにあるが、使われるのは自販機の売り切れボタンである。
(existItem? isExists? itemExists? 語法が正しいのか分かりません。)

疑問⑤-1: 再利用性のあるメソッドの置き場
itemクラス内のbanUpsidedownメソッドがdisplayクラスでも再利用性があるという場合はメソッドの場所をitemクラスとdisplayクラスの共用クラスに変更したほうが良いのか。

疑問⑤-2: 分類場所優先か利用場所優先か
existItemメソッドはitemクラス内で一度も使われない。しかし、itemクラスに分類されるメソッドである。だがdisplayクラスで呼び出されるという場合、existItemメソッドはitemクラス(分類場所)内に置いておいていいのかdisplayクラス(利用場所)へ移動させたほうがいいのか。

回答24件

Zuishin

総合スコア28660

投稿2023/03/12 04:36

編集2023/03/12 04:58

「どうとでも設計できるからどうとでも設計して良いのではないか」という質問自体が既に破綻しています。
「良い設計」を一言で言えば、「人が読んで理解しやすく保守しやすいもの」となり、具体的には次のような原則が挙げられます。

https://ja.wikipedia.org/wiki/SOLID

可能な限り汎用的な部品に分割することを心がけましょう。
それ以上の説明は、どの説明を読んでもわからなかったという人には難しすぎます。
理解するために必要な前提知識をまず得ましょう。

一例として、coolJuice には汎用性がありません。
自動販売機で売られる飲み物はジュースとは限らず、温度も冷たいとは限らないからです。
また飲み物の現在の温度によっても必要な処理は変わるはずです。
それらを全てひとまとめの処理として実装するのではなく、小さな部品として作成し、いくつかの部品を組み合わせてさらなる部品とし、それらをさらに組み合わせ、構造化しましょう。
そうすれば、新商品に対応するために自販機ごと変えなくて済むでしょう。

dameo

総合スコア943

投稿2023/03/12 04:41

編集2023/03/14 12:28

設計に特にルールはありませんが、悪い設計からは悪い実装しか生まれません。
悪い実装はコストに跳ね返ってきます。

どうにでも書けてしまうように見えて、こう書くと実装時に破綻したり、分かりにくかったり、遅かったり、将来書き換えにくくなったりということがあります。そういう問題をできるだけ避けるには、コードのパターンとしてこう書くべき、という言い方もできるのですが、設計でも防げるのではないでしょうか。そう思ってくれれば、設計だと「どうにでも書けてしまう」ということはないかと思います(ある程度自由度はありますが)。

「仕様に着目しても場所に着目しても目的物に着目しても」に、何か意味があるようには思えませんでした。不都合がないならどうでもいいです。
よくある自販機問題は、分析/設計がそれぞれどういうものかを体験してもらう程度の意味合いしかないと思います。

質問の3/14追記分について

要件がないのに設計の良し悪しもなく、実装した場合具体的な不都合があるケースだけ除外できればいいです。

疑問①-1: SVOからのアプローチの語法
一般的なルールはありません。SVOとかどうでもいいですが、分かりやすいと思う名前にしましょう。
個人的な意見では、他のに合わせてくださいというだけ。ルールや名前自体も統一は必要です。

疑問①-2: 着眼点の違うシナリオの混在 1/2 (粒度の等しいクラス)
着眼点とか見え方とかあんまり気にしないでいい。
とにかく他と同じように書ける部分は可能な限り全てそう書いてくれればいいだけ。
無理なく汎化できるなら括りだせばいいだけ。
破綻するならモデリングをやり直せばいいだけ。

疑問②-1: 着眼点の違うシナリオの混在 2/2 (クラスとメソッド)
疑問③-1: 関連度/粒度/抽象度
いろいろな書き方あるけど別に書きたいように(保守性が高いと思う形に)書けばよく、正直どうでもいい。

ここまで、どういう設計が綺麗と思うか？という話なので、主観にしかならない気がします。
実害がなければ何でもいいです。
とにかく理由がなければ分かりやすさのために統一だけ意識してください。

疑問④-1: カプセル化と汎用性
あります。

疑問④-2: 汎用性のあるメソッドのネーミングと名前空間 1/2
好きにしていいです。

疑問⑤-1: 再利用性のあるメソッドの置き場
itemクラスの内部(静的)クラスでいいです。
別にdisplayクラスの内部(静的)クラスも作ります。
両方に完全に共通するなら、よりpublicな別パッケージに出します。

疑問⑤-2: 分類場所優先か利用場所優先か
existsInVendingMachineくらいの意味なんですね。もしそうならdisplayには使えません。
displayからitemへの関連/依存くらいに設計するかと思います。

感想

悩むくらいなら手を動かして、全ケース見てしまいましょう。疑問点がいくらか狭まるはずです。ある程度自力で解を得られた段階で他人に確認してみましょう(ある程度できてますが)。十分な検討なしに疑問の全てを他人に聞いていても成長しません。

ここで書くのはどうかとも思いますが、本に書いてある内容は考え方など、大抵アイデアレベルの話だと思います。実際にやれば問題点が山のように積まれるので、知識として活用し、完全に適合するケースだけいいとこ取りできればOK。普通にやっても上手くできる人たちが、さらによくするために考えたアイデアくらいに思ってくれればいいような気がします。ただし挑戦的なプロジェクトで、そういう人たちが集まって何か作るなら、要件外のあらゆるケースを考え尽くした最善の方法(でも大抵一番シンプルなのになる)を考えてください。

episteme

総合スコア16614

投稿2023/03/12 06:00

編集2023/03/13 04:13

どうにでも書けてしまえませんか？

どうにでも書けますよ。

自販機の利用者から見れば「"商品名"と"価格"の組が複数個あり、現金と引き換えに商品を提供するハコ」に見えるでしょうし、
電力会社から見れば「電力を消費する鉄のハコ」に見えるでしょう。ジュースが欠品してるか冷えてるかなんて電力会社にしてみれば「しらんがな」です。

視点次第で設計は変わります。

jimbe

総合スコア12648

投稿2023/03/12 06:49

編集2023/03/14 11:04

何の何を設計するのかの”対象”がはっきりしないのが問題のように思います。
例の "自販機の設計" とは、何を設計するのでしょうか。
・自販機全体の制御プログラム
・自販機を設置する最適な場所を探すプログラム
・自販機で販売するものの最適な組み合わせを探すプログラム
・自販機のシミュレータ・ゲーム?
それぞれ扱う情報も使う人も全く違い、当然機能も違いますし、分かり易さも保守性も基準はそれぞれに違うのでは無いでしょうか。

何やら色々追加されているようですが…抽象化したいのか具体化したいのかよく分かりません。
「banUpsidedown メソッドもおでん以外にも使えそうな抽象性のあるメソッド」で思わず（失礼ながら）笑ってしまいました。おでんの天地無用と同時に使うモノが想像付きません。
何かの究極的なモノを探しているようで、意見とかよりあれは？これは？で終始してしまいそうです。

dameo

総合スコア943

投稿2023/03/12 07:03

補足です。
自販機の問題は、大昔からオブジェクト指向入門時によく出される課題の題材の1つです。うん十年前、私がやらされたときは、要件定義もほとんどない状態から「とりあえず分析/設計してみろ」的に出されて、その後当時のコンサルから大仰な説明で四の五の言われた記憶があります。質問者さんの件も多分それに近い状態なのだと思いますよ。

xebme

総合スコア1083

投稿2023/03/12 07:18

編集2023/03/12 07:57

欠けている2つの観点

システムは人間抜きに成立しません。システムの利用者をユーザーと呼ぶと、ユーザーはどのようにシステムを利用しますか。

ユースケース、シナリオ

利用の仕方をユースケース、ユースケースの具体例をユースケースシナリオと呼びます。自動販売機から商品を買うまでに、ユーザーと自動販売機はどのようなやり取りをしますか。途中でやめるシナリオがあるし、金額が不足しているシナリオがあるし、お釣りが必要なシナリオもある。偽硬貨のシナリオも。

シナリオのステップをSVO(主語、動詞、目的語)文で記述してください。

ユーザーは..円硬貨を自動販売機に投入する。
自動販売機は硬貨を受け入れ、硬貨を調べる。
…

シナリオはオブジェクトの振る舞いをつなぐものと見ることができます。S,Oに現れるオブジェクトを整理して、Vを割り当てると、ほぼ大きなクラス設計はできたことになります。よく考えてみると、シーケンス図を先に描き、振る舞いを特定して、クラス図に反映しているだけと思うかもしれません。

制約

もう一つの観点は、シナリオから導かれるシステムの制約です。列挙します。

商品の値段に満たない硬貨しか投入されていないのに、商品を排出してはならない
商品の在庫がないのに、販売ボタンを点灯してはならない
…

オブジェクトは内部状態を持ち、矛盾が起きない条件として制約を課すことができます。制約が破られるとオブジェクトを破棄しなければならない。

結論

シナリオと制約はオブジェクト指向設計でなくても重要で、おそらくどんな設計分析にも有効でしょう。

追記

　dameoさん、ユースケース、シナリオは分析とのご指摘、ありがとうございます。だとすれば、既に問題文に記述されているわけです。名詞も動詞も目的語もあるはず。すると、制約も分析だとすれば、私の言いたいことは「シーケンス図からクラスの振る舞いを特定せよ」だけになります。

ついでながら、ユースケースに登場するユーザーはアクターと呼ばれ、ステムに作用する役割を表します。人の役割だけでなく、外部システムや、システム内部のタイマーが含まれます。

dameo

総合スコア943

投稿2023/03/12 07:31

編集2023/03/12 08:48

定義とか人次第なので適宜読み変えればいいのですが、ユースケース、シナリオは通常、オブジェクト指向だと分析に分類され、設計には入りません。それらは設計の入力に該当します。
https://ja.wikipedia.org/wiki/%E3%82%AA%E3%83%96%E3%82%B8%E3%82%A7%E3%82%AF%E3%83%88%E6%8C%87%E5%90%91%E5%88%86%E6%9E%90%E8%A8%AD%E8%A8%88
質問者さんの想定次第ですね。

名詞も動詞も目的語もあるはず。すると、制約も分析だとすれば、私の言いたいことは「シーケンス図からクラスの振る舞いを特定せよ」だけになります。

分析にもクラス図は使用できます。それらは概念モデルとして対象の振る舞いを規定しているだけになり、設計上のクラス(一応実装と1:1に対応するものとします)に対する制約には必ずしもなりません。もちろんこういうのはプロセス(工程)として何を作るか、どういうものとするか、みたいな話に依存するので、プロジェクトの規定に依存します。ようは分析アウトプットはあまり正確な記載のない要件定義から、明確な仕様を規定し、要求者(顧客)と合意するための資料、と個人的には考えています。
設計に近い形での仕様合意ができることが利点です。

設計上のシーケンス図などの動的な振る舞いを表すモデルは、設計上の対応するクラス図などの静的なモデルに対して整合を求めます。それらは設計時に書くものであり、入力ではありません。

まあ質問者さんの意図はよく分かりませんが、「こうしなければならないか？」は知りたいようなので、それに対しては「(要件次第なので必ずしも)しなくていいよ」でいいのかと思います。一言で言えば「要件が足りないので、誰も答えを持っていない」というだけです。

xebme

総合スコア1083

投稿2023/03/12 09:25

編集2023/03/12 10:37

追記3
#6を読んで疑問に思ったのですが、クラスは「AはBをする」に縛られるのでしょうか。「AがBになる」で作らないほうがいいのでしょうか。

もちろん、自動詞を使うSVは自律的に動くスレッドならありえます。自動販売機のなかで自律的に動くものがあればそうしてください。SVO、SVの両方が考えられるとしましょう。

追記：主語がクラス自身で状態問い合わせを行うメソッドがあります。

is...() 自分自身の状態をtrue/falseで返す。
contains(...)

メソッド名が三人称単数形なら主語はクラス自身、それ以外のメソッドは命令形の使役だと思いますが、シナリオ内では自律的ではなく常に他のオブジェクトから駆動されます。このあたりになるとたとえばなしに使った英文法から離れてしまいます。

xebme

総合スコア1083

投稿2023/03/12 09:37

追記2
着目したテーマ(仕様/場所/目的物 etc.)によって、同じ動きをするプログラミングの関数名が動詞句(メソッド)になることも名詞句(クラス)になることもあるということなのでしょうか。

あると思います。ポリモーフィズムを考慮すれば、Vが具体的なものから総称的なクラスやインターフェイスになることが考えられます。適切な例かどうかはわかりませんが。

#10

xebme

総合スコア1083

投稿2023/03/12 09:53

分析にもクラス図は使用できます。それらは概念モデルとして対象の振る舞いを規定しているだけになり、設計上のクラス(一応実装と1:1に対応するものとします)に対する制約には必ずしもなりません。

はい、そのようなことはよく承知しております。#6からのわたしの論点は次になります。

分析を経ずして (理解せずして)設計はできない。

質問者さんが設計の前提をどう考えるかが明らかになれば議論が変化するでしょう。

#11

dameo

総合スコア943

投稿2023/03/12 10:11

#10
議論のための議論は好きではないですね。

分析を経ずして (理解せずして)設計はできない。

は、ちょっと言い過ぎかと…。単純にどういう設計が良い設計なのか聞きたいなら、要件を全て満たしており、

誰にでも分かりやすく
十分な速度が出ていて
柔軟になっている

ということだと思うのですが、質問者さんはどちらかというと良い設計というよりは、やってはいけない設計を聞いているようなので、「分かりやすさと保守性」がある前提の話をしている以上、それなら特にルールはないよね、と言ってるだけですよ。

「分かりやすさと保守性」のいずれかが崩れるのであれば、必要な前提をつけて例でも挙げてそこを説明してあげればいいのではないでしょうか？

#12

xebme

総合スコア1083

投稿2023/03/12 13:12

編集2023/03/12 20:54

改めて質問を読み直しました。

質問

どうにでもできる名詞、動詞を使うしか設計方法がないのか。拠り所にする設計原則はないのか

回答

分析段階では名詞、動詞を使ってラフスケッチを作るしかないでしょう。クラス設計は振る舞いを中心に行ってください。設計原則をあげてみます。

ロバート・C・マーチン『アジャイルソフトウエア開発の奥義』SOLID(Zuishinさんの回答)
バートランドメイヤー『オブジェクト指向入門第2版原則・コンセプト』
エリック・ガンマ、他『オブジェクト指向における再利用のためのデザインパターン』

以下はMITの講座です。いま受講できるかわかりません。もとになったのはリスコフのC++講座です。その内容も公開されているはず。

オブジェクトではなく(MVCなどの)アーキテクチャをもとに役割を固定してクラスを設計する方法があります。ユースケース駆動設計もあります。

#13

fana

総合スコア11658

投稿2023/03/13 02:39

編集2023/03/13 03:56

回答されている他の方と違って，私は素人なので，悩まれている雰囲気はわかる気がします．

着目するところやコツがあれば

そもそもそれが書いてあるのが，各種の本だったりするのだと思うのです．
でも，私くらいの素人だと（というか単に私の頭の問題なだけかもですが）【読んだから→なんかできる】とはなかなかならないわけで…

さらに言えば，ろくにわかってない状態でこのような場所で問うてみたところで，やっぱわからんのですよ．
（わからないから問うハズなのに，わからない状態で問うてもわからないという…）

で，そんな素人からの後ろ向きな(?)アドバイス(??) ですが…
「経験者いわく…」の話を聞いておくことには価値がありますが，それはそれとして，
今々「これ」という結論を無理に出そうとしない方が良いんじゃないかな，と思います．

どのような設計を選んでも構わないのか

ここの構う/構わないとは一体誰が決めるんでしょう？　っていうのを忘れないことが大切なんじゃないかな，とか．
上から言われた通りに作らなきゃならない立場にいるのでもなければ，判断の主体は自身なわけですよね．
その意味では "どうにでも" して良いわけで，何か適当に本なりをちょっとかじったからといって，いきなり本来存在していたはずのこの自由度を過度に制限してみてもあまり良いことはないであろうと思います．

例えば，やり方として　AとBとC　が現時点で考えられるとして，どれでも動くものができるのであれば
AとBとCの関係というのは
「Aだけが唯一 OK なのであり，BとCは絶対的に NG です」という形ではなくて
「何らかの評価基準において　A >> B >= C　かな」みたいな話になるのだと思うのです．

で，この「何らかの評価基準」とかいうやつが自分の中から湧いてくるには，やはり相応の訓練/経験/反省/etc が必要なのだと思います．
要は，目の前の問題がまだ例題であるうちに「クソみたいな（と後から自身で評することができる）設計」なりを試してみるしかないっすよ，っていう．
（このような場所を使うにしても，そのような試行過程で出てきた具体的な疑問等についての話をする（＝話の焦点を絞る）方が，それに対しての「経験者いわく…」の話が少しはわかりやすいものになる…かな？）

#14

xebme

総合スコア1083

投稿2023/03/13 20:25

MVCアーキテクチャーパターンで思い出したのですが、MVCで設計すると自動販売機を状態機械とみなすでしょう。この設計では、分析シナリオがモデルの状態遷移に還元されてしまいます。

観点を変えることが「どうにでもなる」への回答の一つかなと思いました。

#15

ttb

総合スコア67

投稿2023/03/14 00:47

私なら・・・

自販機には、
販売、保管(とそれを適温にする)「機能」が求められる。
それを実現するための「ハードウェア」である、ボタン、ランプ、コイン分別機、コイン保管箱、商品保管庫、加温・冷却機がある。

とすると、システム全体として、販売機能、保管機能を大枠として、
もう1階層下に、
販売機能>販売管理
販売機能>コイン管理
保管機能>在庫管理
保管機能>適温制御
といった構成にする。

あと、ハードウェアごとに〇〇コントローラを作っておく（例えば加温・冷却機なら、保管場所番号と温度を設定したら、あとはその中でうまく制御してくれるようなクラス）。各コントローラは、先の管理・制御機能から呼び出せるようにしておく。

といった思考で設計していくと思います。
(こんなふうにザックリ設計したあと、具体化してみて、まずいところを修正していく感じ。)
参考になれば幸いです。

#16

退会済みユーザー

総合スコア0

投稿2023/03/14 04:06

追記3について。

一般的にクラスベースのオブジェクト指向では、インスタンスは生成から破棄まで、元となるクラスが変わることはありません。
ある商品がcoolingJuiceクラスのインスタンスであれば、最後までcoolingJuiceクラスのインスタンスです。
つまり「AがBになる」ことはありません（正確には、クラスAのインスタンスが、クラスBのインスタンスになることはない）。
そのため、温度のようなモノは通常インスタンスの状態（属性）として管理します。

ただし、状態を表すクラスを作るケースもありますが、ここでは言及しません。
興味があればデザインパターンのStateパターンを調べてみてください。
（このパターンであっても、同一インスタンスのクラス自体が変わることはありません）

設計は……難しいですよね。

質問者さんが書かれている仕様（振る舞い）に関し、ある程度関連することをまとめて、
一つのクラスとするのが基本かと思います。

例えば自販機であれば、（業者の担当者が）商品を補充できる、
（客が購入すると）商品を排出できる、（売り切れ表示のために）商品の売り切れ判定ができるといった、
商品を管理する機能をひとまとめにして、商品管理（もしくは保管庫）クラスを考えるイメージです。

#17

ttb

総合スコア67

投稿2023/03/14 23:15

編集2023/03/14 23:17

ここまで色々考えてらっしゃるのであれば、そろそろ、手を動かす時期なのかなとも思います。自分でプログラミング言語を触って、システムをいくつも組み上げてみる。そうすると、色々「あそこまて抽象化するのはやりすぎだった」とか、感覚が養われていくのかな、と思います。
例えば自販機でいうと、世の多くの自販機は、「ジュース、おでん、おもちゃ」ほど細かい分けられ方はされておらず、商品はすべて円筒形である前提で、種類は「温・冷」の2つしかありません(もしかしたら「温・冷・無」の3つかもしれないですが)。おもちゃを入れる場合は、(もし無(加温も冷却もしない)モードが無い場合、ソフトウェア上対応できませんが、そこは使う人間側の判断で、おもちゃを円筒形の筒にいれ「冷」モードで使うことでしょう)