常連

オブジェクト指向について、あちらこちらで当たり前のようにオブジェクト指向という言葉を聞きますが、多分ほとんどの人はオブジェクト指向を理解してないんじゃないかと思うことがあります。

まず、オブジェクト指向のデメリットについて

大規模な開発だとオブジェクト指向を導入するにあたってクラス図やドキュメントを整理しないといけないわけですよね？
これだと、オブジェクト指向を使っているのか、オブジェクト指向に人間が使われているのか、意味不明じゃないですか？

また、中規模、小規模な開発だとオブジェクト指向は色んなところにプログラムを分散させることが出来るというデメリットしかありませんし、従来の手続き型プログラミングのデメリットである、ネストや関数の呼び出しが深くなりすぎて、可読性がない、みたいなことも解消される訳もなく、デメリットが単に増えているだけな気がします。

建前上たくさんのクラスに別れているとか、ソフトウェアアプリケーションを作る上でフレームワークが強要してくるとかならまだ分かるし、そもそもそのレベルなら別にオブジェクト指向云々ってあんまりどうでもいい気がするのですが、

オブジェクト指向って言葉だけが独り歩きしている気がします。
知っていて偉いとか知ってないとダメだみたいな雰囲気すらありますが、考え方のひとつ、選択肢のひとつでしかないですよね？
で、何よりこれだけオブジェクト指向という言葉が広まりながら、ほとんどの人がデメリットにもメリットにも気づいてないのが、1番不可解です。

皆さんのオブジェクト指向に対する見解はどんな感じですか？

なお、こういう内容で必ずカプセル化がどうとか言う人がいますが、カプセル化って処理を隠しているだけでなんの本質的なものでも無いですよね？別にオブジェクト指向じゃなくてもできるし。これをデメリットではなくメリットとしてあげる人は、ニワカだと思います(この考えが間違っていれば指摘お願いします)。

オブジェクト指向を理解していればメリットデメリットの一つや二つは簡単にあげられると思います。

そもそもオブジェクト指向について知らないので見解もないし、代替案を提示してください、等の回答は不要です。


オブジェクト指向は好き？

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

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の大枠を実体面(ハードウェア)から考えた。
![イメージ説明](https://ddjkaamml8q8x.cloudfront.net/questions/2023-03-14/c233ce27-2837-4c16-b0a1-ee9bc1c84a29.png)
さらにvendingMachineの大枠を動作面(SVO)から考え直した。
![イメージ説明](https://ddjkaamml8q8x.cloudfront.net/questions/2023-03-14/4324fecf-d575-4883-a855-7296dc1c8b50.png)

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

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

### 2. 汎用性があるクラスへの再編
juiceクラスは汎用性が無いため、itemクラスに再編した。
ここではoden(おでん)はfoodのほうが良いのではないかという再々編の余地を残しているがこの設計で大きな影響はない。
![イメージ説明](https://ddjkaamml8q8x.cloudfront.net/questions/2023-03-14/1f7c436d-fd20-48cc-92b9-eb1021dff553.png)

**疑問②-1: 着眼点の違うシナリオの混在 2/2 (クラスとメソッド)**
自販機の実体面から考えられたクラス内にオーナーの動作面から考えられたメソッドという、以下のような構成もありえるのか。
![イメージ説明](https://ddjkaamml8q8x.cloudfront.net/questions/2023-03-14/ed57b481-90ba-4944-9806-0b9d1f100d0f.png)
処理過程も見方によっては目的となり、また逆もあり、名詞句なのか動詞句なのかの違いだけで内容が同じ関数に関してクラスとメソッドには大きな隔たりが無いように感じているが、どのようにクラスとメソッドの住み分けを進めればいいのか。
一旦すべての構成をドメイン/クラスとった樹形図のような名前空間に落とし込み、そこからさらに”名前空間をつくる程でもない処理”をメソッドとして扱っても設計できそうだが、メソッドはそのように捉えるべきではないのか。

### 3. 共通するメソッドの扱い 1
各クラスに以下のメソッドが付加された。
![イメージ説明](https://ddjkaamml8q8x.cloudfront.net/questions/2023-03-14/6db16a0b-25bf-4999-9bc4-fcc3bbdfae39.png)
処理が共通するおまけ飴メソッドの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つまでが良いと何かの本で読んだことがあったが、名前空間も読みやすさなどのルールがあるのか。
 
![イメージ説明](https://ddjkaamml8q8x.cloudfront.net/questions/2023-03-14/38ea61bd-8519-4e78-bec8-cc45ff3348b6.png)
### 4. クラスの拡張
additionクラスをsharedクラスに拡張した。
banUpsidedown(天地無用)メソッドもoden以外にも使えそうな抽象性のあるメソッドなのでadditionクラスをsharedクラスとしてこれに移動させた。
![イメージ説明](https://ddjkaamml8q8x.cloudfront.net/questions/2023-03-14/0fd012e2-ba18-4366-8fdc-064691f2b81b.png)
**疑問④-1: カプセル化と汎用性**
オブジェクト指向(カプセル化)と汎用性のあるメソッドに親和性はあるのか。
汎用性のあるメソッド作るほど、元のクラスの中身が減っていくわけで、そうなると行程がいくつもあり肥大化したクラスを除いて、カプセル化を目指さないほうが無難なのではないか。

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

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

![イメージ説明](https://ddjkaamml8q8x.cloudfront.net/questions/2023-03-14/065303e2-6391-497f-97b3-f7b19b7b9502.png)
**疑問⑤-1: 再利用性のあるメソッドの置き場**
itemクラス内のbanUpsidedownメソッドがdisplayクラスでも再利用性があるという場合はメソッドの場所をitemクラスとdisplayクラスの共用クラスに変更したほうが良いのか。

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





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

JAVAを勉強している者です。説明が下手ですいませんが、「**インターフェース**」って何のメリットがあるんですか？
「**インターフェース**」は

「**派生化してその目的に特化したそれぞれのクラスを統一しておくことでそれらのクラスを気にしなくても、使うことができるもの**」

とか

「**派生化したそれぞれのクラスが、その中身を気にしなくても統一して利用できるようにするためのもの**」（説明が下手ですいません。）

らしいですが、そんなことして何のメリットがあるんですか？開発が短縮されるんですか？

バラバラな（派生化してその目的に特化した）クラスを統一するなら、最初からきちんと完璧に設計すれば早いと思うのですがどうでしょうか？

**わかりやすいような例や例えで教えてくれませんか？  **

よろしくお願いします。

インターフェースって何のメリットがあるんですか？

自分がインスタンスというものを決まり文句としてしか理解できていないからなのですが、シングルトンの重要性があまりわかりません。
調べてみてもいまいちピンきませんでした、インスタンスがなぜ一つじゃないといけないのか,どのような場面でシングルトンを使うのか、どなたか教えて頂けないでしょうか。

シングルトンがなぜ必要なのか

### 前提・実現したいこと
読み込んで、結果を出したいのですが。。。


### 発生している問題・エラーメッセージ

```
> mean(weight)
 mean(weight) でエラー:  オブジェクト 'weight' がありません 
> median(weight)
 median(weight) でエラー:  オブジェクト 'weight' がありません 
> table(weight)
 table(weight) でエラー:  オブジェクト 'weight' がありません 
> var(weight)
 is.data.frame(x) でエラー:  オブジェクト 'weight' がありません 

```

### 該当のソースコード

```R
> getwd()
[1] "/Users/macbook/¥da2020¥"
> library(readxl)
> student<- read_excel("student.xlsx")
                                                                                                                       
> student
# A tibble: 20 x 4
      ID gender height weight
   <dbl> <chr>   <dbl>  <dbl>
 1     1 f         158     60
 2     2 f         187     79
 3     3 m         140     56
 4     4 m         165     55
 5     5 f         167     72
 6     6 f         155     62
 7     7 m         174     68
 8     8 m         142     39
 9     9 m         151     55
10    10 f         178     80
11    11 m         148     51
12    12 f         172     68
13    13 f         191     96
14    14 m         185     88
15    15 m         185     89
16    16 f         172     83
17    17 f         164     82
18    18 m         178     92
19    19 m         164     61
20    20 m         171     59
> View(student)
> edit(student)
   ID gender height weight
1   1      f    158     60
2   2      f    187     79
3   3      m    140     56
4   4      m    165     55
5   5      f    167     72
6   6      f    155     62
7   7      m    174     68
8   8      m    142     39
9   9      m    151     55
10 10      f    178     80
11 11      m    148     51
12 12      f    172     68
13 13      f    191     96
14 14      m    185     88
15 15      m    185     89
16 16      f    172     83
17 17      f    164     82
18 18      m    178     92
19 19      m    164     61
20 20      m    171     59

```

読み込んでいるはずなのですが、オブジェクト 'weight' がありません と表記されます。
原因がわかりません。どう解決すればよろしいでしょうか。
Rは最新、macOS Catalina（10.15.7)です。

Rのエラーについて　オブジェクトがありません とエラーが出ます

## 1.概要

データの操作を行うクラスに、例えばcsvやjson形式のファイルに対する入出力を行うメソッドを実装するべきなのか悩んでいます。

ほかの有名なパッケージではデータをファイルに保存するメソッドはクラス内で実装されています。
一方ソフトウェア工学に基づけばファイルに保存するメソッドはクラス外に実装するべきだと思われます。

どちらの実装も可能です。
将来的なクラスの改変を想定されるときどちらの実装が望ましいでしょうか？

## 2.背景、状況

私は仕事の効率化のために個人的に少しばかりPythonを触っているものです。
検索や並び替えなど簡単なデータの操作を行うクラスを実装しようと考えています。
現時点ではファイルからデータを読み取ることをほとんど前提としています。

想定している前提状況

* クラス外からファイルに保存するのに必要なデータを完全に復元できるだけの情報にアクセスできる
* ただしクラス外から得られるデータはそのままでは適切にファイルに保存できず、保存に際してクラス内での実装に依存した処理が必要になる
  * 例えばクラス初期化に際して与えたlist[float]の数列がクラス外からアクセスするとnumpy.ndarrayとして得られるなど

問題は上記の前提状況でクラス外とクラス内どちらにファイルに保存するメソッドを実装するべきかというものです。

## 3.調査したこと

### 3.1ほかのパッケージでの実装

pandasやほかの自分が利用しているパッケージを3つほど思いつく限り参考にしてみたところ、すべて入力する処理は独立した関数として分割されていますが、出力はインスタンスメソッドとして実装されていました

```python
# pandasの場合
# ファイルからの読み込み(クラスとは独立した関数)
dataframe : pandas.DataFrame = pandas.read_csv("data.csv")
# ファイルへの出力(インスタンスメソッド)
dataframe.to_csv("data.csv")

# sqliteの場合
# dbへの接続(クラスとは独立した関数)
conn : sqlite3.Connection = sqlite3.connect("data.db")
# dbへの書き込み(インスタンスメソッド)
conn.commit()
```

### 3.2ソフトウェア工学的な原則

自分は最近になってSOLID原則などを知るようになった程度なので以下の考えはきちんと理解できていない人間のものだと思います。

SOLID原則における単一責任の原則に基づけば、考えているクラスはデータの改変や操作に集中するべきで、データの保存に関しては分割するべきであるように思われます。
~一方でデータの操作に付随してファイルの入出力はほとんど必要な作業であるので、凝集度を上げるために一つにまとめるべきなのか判断できません。~ 
凝集度を勘違いしていました。凝集度の視点では操作と保存が分割することは欠点にはならないと理解しました。

参考1でもデータを取り扱うクラスと保存するクラスで分割しているようです。

参考 :
* 1.[きれいなコードを書くためにSOLID原則を学びました① \~単一責任の原則\~](https://qiita.com/suzuki0430/items/b13c7c1f637e7cd2146d)
* 2.[設計におけるオブジェクトの責務分配に有効なものさし -凝集度と結合度-](https://www.ogis-ri.co.jp/otc/hiroba/technical/Cohesion_Coupling/Cohesion_Coupling.html)

## 4.自分なりの考え

ファイルからインスタンスを作成する際(入力時)にはクラスのインターフェースに従って入力すればよいので分割するのは簡単ですが、出力する側も分割する場合はクラスの内部につよく依存した形に実装されるように思われます。
例えば数列をクラスの中ではNumpy.ndarrayで保存していた場合、これらをjson形式で保存する関数は数列の部分をlist形式にキャストして保存する必要があります。これはクラス外の実装がクラス内の実装に強く依存しており結合度の高い実装になってしまうように思われます。
したがって自分が実装するならクラスの内部にファイルの入出力にかかわるメソッドを実装します。

先に述べた通り、自分は最近になってSOLID原則などを知るようになった者で上記の自分の考えが正しいのか全く自身がありません。
周りには質問できるようなひとがいないためこちらで質問させていただきます。皆さんのご意見を伺いたいです。

将来的なクラスの改変も予想されるときに
1. クラス外にファイルへの入出力のメソッドを実装する
2. クラス内にファイルへの入出力のメソッドを実装する
どちらがより**理想的で望ましい**実装方法でしょうか?

よろしくお願いいたします。

## 6.最後に

またteratailでの質問はこれが初めてなので質問場所が適切でなかった場合や、タグ付けが正しくないなどあるかもしれません。
その際はご指摘の上、ご容赦頂ければ幸いです。

データクラスがファイルへの入出力の責任を持つべきか？

## テーマ、知りたいこと
オブジェクト指向プログラミングにおいて、包含したクラスで多態性をどう実現するべきかどうかについて質問があります。

## 背景、状況
例としてキャラクターを表すクラスを設計を設計しました。
このキャラクターは、自身の持ち物を管理するInventoryクラスを包含(has a)しています。

```CSharp
public class Inventory
{
    private List<Item> _itemList = new List<Item>();
    public ReadOnlyCollection<Item> ReadOnlyItemList => _itemList.AsReadOnly();

    public void AddItem(Item item)
    {
        _itemList.Add(item);
    }

    public void RemoveItem(Item item)
    {
        _itemList.Remove(item);
    }
}

public class Character
{
    private Inventory _inventory = new Inventory();

    public void AddItem(Item item)
    {
        _inventory.AddItem(item);
    }

    public void RemoveItem(Item item)
    {
        _inventory.RemoveItem(item);
    }
}
```

また、アイテムを出し入れする宝箱など内部にインベントリを持つエンティティを表すクラスも設計することにしました。
宝箱も内部インベントリを管理するInventoryクラスを包含(has a)しています。

```CSharp
public class TreasureBox
{
    private Inventory _inventory = new Inventory();

    public void AddItem(Item item)
    {
        _inventory.AddItem(item);
    }

    public void RemoveItem(Item item)
    {
        _inventory.RemoveItem(item);
    }
}
```

この時、キャラクタークラスと宝箱クラスの間でポリモーフィズムを実現したいと考えました。
どちらも同じくインベントリを持つため、インベントリに関するメソッドを外部に向けて公開するインターフェイスを作成し、
キャラクタークラスと宝箱クラスに適用します。

```CSharp
public interface IInventoryHolder
{
    public void AddItem(Item item);
    public void RemoveItem(Item item);
}

public class Character : IInventoryHolder {}

public class TreasureBox : IInventoryHolder {}
```

しかしながら、このようにインターフェイスを使用して多態性を実現する方法が適切かどうか疑問に思いました。
キャラクターと宝箱という異なるクラスに対してどちらもインベントリを保持しているという点からインターフェイスを共通させることが適切か否かが判断できません。

## まとめ
上記の例において多態性を表現するコーディングは適切なのでしょうか？
また、そもそもオブジェクト指向の作法に則る場合、包含されたクラスでどのように多態性を表現するべきなのでしょうか？


has-a関係と多態性をどのように両立させればよいか

### 前提

インターフェースやポリモーフィズムの勉強中に、「インターフェースはis-aの関係」と言っているサイトや参考書と「インターフェースはcan-doの関係」と言っている学習サイトなどがあり混乱しています。
私としてはis-aの関係でもcan-doの関係でもなりうると考えていますが何が正しいのでしょうか？


下記の自作ソースコードは一応成り立っているので（手塚治虫のロボット的なのが何人もいる状態と仮定）、can-doの関係は成り立つと思います。
また、スッキリわかるjava入門という参考書に、「インターフェースは抽象クラスの一部」とあり、抽象クラスはis-aの関係で継承しているので、インターフェースはis-aの関係でも使えると解釈しています。

### 該当のソースコード

```php
<?php

class Mangaka{
    public function interview(){
        echo "取材をした";
    }
    public function go_sleep(){
        echo "寝る";
    }
}

class TedukaOsamu extends Mangaka implements Doctor{


    function ope(){
        echo "手術をした";

    }
}

interface Doctor 
  {
      //インターフェイスでは、実装することができない。
    //   public function eat();
      
      public function ope();
  }

  $teduka=New TedukaOsamu();
  $teduka->ope();

  ?>
```

