常連

### 実現したいこと
オブジェクトの入ってる配列をループで動かしていきたいです。

### 発生している問題・分からないこと
staff.xには情報とx座標がはいっています。staff.positionはwindowをmember2でわったx座標が、格納されています。
staff.xは移動する情報でstaff.positionはその情報をしまう箱のような役割をしています。この情報を箱にしまうループがうまくいきません。
forループでは、配列であらわすと、例えばint data【5】＝｛1，2，3，4，5｝があったとして、キーボードで要素数の1を入力したら1，3，4，5，2，というようにループでずれ、次にキーボードで0を入力したら、3，4，5，2，1となります。
つまり、入力された数字が配列の末尾にいき、入力された数字より後ろが前倒しになるということです。
このとき入力される数字はclickedIndexになります、この動きがうまくいきません。
また、
int []data=new int[member2-clickedIndex+1];のmember2-clickedIndex+1というのは先程例に上げた配列の要素数がmember2にあたり、キーボードで入力したものがclickedIndexにあたるので、clickedIndex以降の数字をループで動かすために
int []data=new int[member2-clickedIndex+1];となっております。
プログラムではstaff.position［j］に入ってるstaff.xを見つけ出して、別の箱に移動させらるように準備をしています。

この箱の移し替えの作業が例に上げた配列のループのように動かすにはどうしたらいいでしょうか？

プログラム初心者で言葉足らずなとこもありますがよろしくお願いいたします。



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

```processing
void setX() {
  int j=0;
  int []data=new int[member2-clickedIndex+1];
  if (clickedIndex!=-1) {
    
if (clickedIndex < member2 && clickedIndex >= 0) {
if (staff[clickedIndex].isTimerOn && clickingTimer) {
　while (j<member2) {
if (staff[j].position==member2) {
 int tmp=staff[j].x;
  for (int k=clickedIndex;
  k<=member2-1; k++) {
 for (int i =clickedIndex+1; i <=member2; i++) {
 if (staff[i].position==k) {
    data[k]=staff[i].x;
 }
 }
 for (int i=0; i<=member2; i++) {
 if (staff[i].position==k+1) {
            data[k]=staff[i].x;
  }
   }
  print(data[k]);
  }
    staff[clickedIndex].x=tmp;
          ｝
          j++;
        }
        clickingTimer=false;
      }
    }
  }
}
```

### 試したこと・調べたこと
- [x] teratailやGoogle等で検索した
- [x] ソースコードを自分なりに変更した
- [x] 知人に聞いた
- [x] その他

##### 上記の詳細・結果
GPTや調べてコードを変えてみましたが、交換したいところが初期値から動かなかったり、交換してほしいところに表示されません。

### 補足
説明が難しく伝わっわてない部分もあるかもしれませんがどうかお願いいたします。

processingでオブジェクトの配列を交換したい

## 以下2冊のどちらがおすすめでしょうか？

[Adaptive Code　～　C#実践開発手法　第2版](https://www.amazon.co.jp/Adaptive-Code-%EF%BD%9E-C-%E5%AE%9F%E8%B7%B5%E9%96%8B%E7%99%BA%E6%89%8B%E6%B3%95-%E7%AC%AC2%E7%89%88-Gary-McLean-ebook/dp/B07DJ2BL4Y/ref=sr_1_1?crid=AN43Z7E5LEM0&dib=eyJ2IjoiMSJ9.N1mmwXYtBkSbpsYhEJggJ0LMU6sF_7VjIg-F8n6Ac8fnRCGcHue9PCXZyojgN2SJGehgmMHg9MA6vto-r9ghgCep-TkWnoZDnvfaos_kAeA89QfX7B8sMSBJkufSCT0xkHPttSxpatr78Z8FHBJzpjjrnmj2G362ROR7douvgzScNTkuZycwqNrDVqxc3R_73KjzUj3XGR78eThnZfGYdRVteYzo501pcBn16OBxP27M4lJm2a8gSqJd34WIpmXRIcDwhYcjg4lyPH993Jp-DJDqDj55Aczxm5023zrN838.wtt-KGqT3_Xou-bcL70cTpRIc-pLKI5uOCSqAc84mO0&dib_tag=se&keywords=adaptive+code&qid=1713521832&sprefix=adaptive+%2Caps%2C205&sr=8-1)
[アジャイルソフトウェア開発の奥義 第2版](https://www.amazon.co.jp/%E3%82%A2%E3%82%B8%E3%83%A3%E3%82%A4%E3%83%AB%E3%82%BD%E3%83%95%E3%83%88%E3%82%A6%E3%82%A7%E3%82%A2%E9%96%8B%E7%99%BA%E3%81%AE%E5%A5%A5%E7%BE%A9-%E7%AC%AC2%E7%89%88-%E3%82%AA%E3%83%96%E3%82%B8%E3%82%A7%E3%82%AF%E3%83%88%E6%8C%87%E5%90%91%E9%96%8B%E7%99%BA%E3%81%AE%E7%A5%9E%E9%AB%84%E3%81%A8%E5%8C%A0%E3%81%AE%E6%8A%80-%E3%83%AD%E3%83%90%E3%83%BC%E3%83%88%E3%83%BBC%E3%83%BB%E3%83%9E%E3%83%BC%E3%83%81%E3%83%B3/dp/4797347783/ref=sr_1_1?crid=3KRRNXVC1TP2P&dib=eyJ2IjoiMSJ9.rd2DLDLztNBUWuDfACcY29t584e0lYpe45o_EEBSc8XGjHj071QN20LucGBJIEps.m6R4axDZpB0Ysa6qc3ONPNkAa1KINMJGtretLmeJlJI&dib_tag=se&keywords=%E3%82%A2%E3%82%B8%E3%83%A3%E3%82%A4%E3%83%AB%E9%96%8B%E7%99%BA%E3%81%AE%E5%A5%A5%E7%BE%A9&qid=1713521848&sprefix=%E3%82%A2%E3%82%B8%E3%83%A3%E3%82%A4%E3%83%AB%E9%96%8B%E7%99%BA%E3%81%AE%2Caps%2C184&sr=8-1)

## 質問者について

- オブジェクト指向を用いた設計を学びたいプログラマ
- 上記2冊の評判が大変良いため興味を持っている
- Java、C#ともに経験あり
- デザインパターンはTemplate MethodとSingletonくらいしか知らない初学者
- アジャイル開発はDeveloperとして経験あり

## 期待していること

目次を見たところ内容が2冊とも似ており、決定的な違いは言語くらいの印象なので、「自身が業務で使用している言語が記載されている方の書籍を買えば良いのでは？」という漠然とした理由しか思い浮かばず...。なので、2冊それぞれに対する感想やおすすめ理由など、買うに至る他の理由を探しており、皆様の意見を頂戴したいです。
「2冊とも止めてこの本を買うべき」や「2冊とも買うべき」などの第三の意見も歓迎です。

どちらの書籍がおすすめでしょうか？

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

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

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

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クラス(利用場所)へ移動させたほうがいいのか。





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

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

## 背景、状況
例としてキャラクターを表すクラスを設計を設計しました。
このキャラクターは、自身の持ち物を管理する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();

  ?>
```



インターフェースはis-aの関係かcan-doの関係かどちらが正しいのでしょうか？

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

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

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