常連

### 前提・実現したいこと
読み込んで、結果を出したいのですが。。。


### 発生している問題・エラーメッセージ

```
> 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のエラーについて　オブジェクトがありません とエラーが出ます

## Javaの抽象クラスとインタフェースの使い分け

> 抽象クラスとインターフェースの違いについてある程度理解できたのですが、
> 実際にどういったシチュエーションで用いられるのか、その区別がつきません。

例えば、
抽象クラスは抽象メソッドに加え、具象メソッドを記述でき、
インタフェースにおいても、defaultを用いれば処理を書ける、
のであれば、抽象クラスで出来ることがインタフェースを使っても実現できる、と思うのです。

抽象クラスとインタフェースで、修飾子や多重継承などの違いがあることは理解できたのですが、
**具体例が思いつかなくて、現状の理解度に満足していません**。

この機能を抽象クラスで実装しよう、インタフェースで実装しようと決めてになるのは、どういったシチュエーションですか？

具体的な例をあげてもらえると嬉しいです。

## 質問内容をまとめます

> 抽象クラスとインターフェースの具体的な利用方法は？

以上、よろしくお願い致します。

Javaの抽象クラスとインタフェースの使い分け

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

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





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

### 実現したいこと
該当のソースコードについて、
26,27行目の`// インスタンス作成`では`$this`が参照できるのに対して、
28,29行目の`// アクション実行`ではできない理由を知りたいです。

### エラーメッセージ
```
PHP Fatal error:
Uncaught Error:
Object of class ParentClass could not be converted to string
in /workspace/Main.php:29
```

### 該当のソースコード
```php
<?php
class ChildClass
{
    public function hoge(): string
    {
        return 'hoge!!';
    }    
}

class ParentClass
{

    private string $className;
    private string $actionName;

    public function __construct(
        string $className,
        string $actionName,
        ) {
        $this->className  = $className;
        $this->actionName = $actionName;
    }

    public function toto(): string
    {
        // インスタンス作成
        $instance = new $this->className(); 
        // アクション実行
        return $instance->$this->actionName();
    }

}

$instance = new ParentClass('ChildClass', 'hoge');
echo $instance->toto();
```

### 試したこと
次の`titi`や`tata`のような形でエラーの解消はできました。

```php
class ParentClass
{

    // 省略

    public function titi(): string
    {
        // インスタンス作成
        $instance = new $this->className(); 
        // アクション実行
        return $instance->{$this->actionName}();
    }
    
    public function tata(): string
    {   
        // インスタンス作成
        $instance = new $this->className(); 
        // アクション実行
        $actionName = $this->actionName;
        return $instance->$actionName(); 
    }    
}

$instance = new ParentClass('ChildClass', 'hoge');
echo $instance->titi();
echo $instance->tata();
```

ですが`toto`において「なぜインタンス作成で同じようなエラーにならないのか」がよく理解できない状態です。

そこが知りたいので、インスタンス作成とアクション実行における`$this`の取り扱いの違いという質問になりますでしょうか。

ご回答よろしくお願い致します。

### 補足情報（FW/ツールのバージョンなど）
PHP 8.1.9 です。


インスタンス作成とアクション実行における`$this`の取り扱いの違い

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

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

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

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

### 実現したいこと

getterを利用せずに`Player::isInWorld()`を実装したい。(可能なら)

### 前提

「アクセッサ書く実装は真のカプセル化ではない」、「本番の開発でgetterを書くことは99%ない」などの記事や動画を拝見させていただきました。そこで示されている例題などは納得しました。アウトプットのために、自分でもgetterを使わずにクラス設計できるか試してみました。

### 発生している問題・エラーメッセージ

そこで、プレイヤーが世界(ある範囲)の中に存在するかしないか、というメンバ関数を実装しようとしました。直面した問題が、「座標クラス(Point)のデータメンバにgetterを書かないと範囲内かどうか比較できないのでは？」というものです。

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

```c++
#include <iostream>

// 座標(x,y)
class Point
{
public:
    Point(int x = 0, int y = 0)
    {
        m_x = x;
        m_y = y;
    }

private:
    int m_x;
    int m_y;
};


// 2次元世界(ただの四角形)
class World
{
public:
    World(Point start = {0, 0}, Point end = {640, 480})
    {
        m_start = start;
        m_end = end;
    }

private:
    Point m_start; // 始点
    Point m_end;   // 終点
};


// プレイヤー
class Player
{
public:
    Player(Point point = {0, 0})
    {
        m_point = point;
    }

    // プレイヤーが世界の範囲内に存在するか?
    bool isInWorld(World world)
    {
        ////////////////////////////////////
        // アクセッサを使わずに実装できるか?
        ////////////////////////////////////

        return true;
    }

private:
    Point m_point;
};


int main(void)
{
    Player player = {{20, 30}}; // 座標(20,30)
    World world;                // (0,0)..(640,480)

    // プレイヤーは世界の範囲内にいる?
    bool exist = player.isInWorld(world);

    return 0;
}

```

### 試したこと

getterを書いていいなら単純な座標比較で可能でした。getterを書かずに実装はできませんでした。

### なぜPlayerクラスに実装しようとしたのか

google翻訳で「プレイヤーは世界の中にいる」を翻訳したら"the player is in the world"と翻訳されたので、主語であるプレイヤークラスに実装することにしました。

### 補足情報（FW/ツールのバージョンなど）

コンパイラ: g++



[カプセル化]getterを利用せずに範囲内判定を実装できるか

### 前提
C#(WPF)にてクイズゲームのようなアプリを開発しています。
オブジェクト指向についての理解が浅く、どのようにクラスの設計したらよいか迷っています。

### 実現したいこと

クイズのコンテンツ(png,mp3等)をローカルに配置し、それらを参照して画面に表示させたり、音声を再生させるつもりです。
そこで1問のクイズを表すQuizクラスを作成しました。機能としてはローカルの読み取りを行い、適切な形に成形してプロパティにセットするといった内容です。(コンストラクタの引数で取得したいコンテンツ郡を指定しています。)
作っている中で、コンテンツを読み取ることはQuizクラスの責務ではないような気がしていて、クラスを分離したほうが良いのではないかと感じています。しかし具体的にどのようにクラスを設計したら良いかがよく分かりません。
この場合、どのように設計すると良いのでしょうか？

### ソースコード
Quizクラス
```C#
using System;
using System.Collections.Generic;
using System.Collections.ObjectModel;
using System.IO;
using System.Linq;

namespace QuizSample
{
    public record Quiz
    {
        private readonly string _contentsPath = @"resources\quizset";

        /// <summary>
        /// 難易度
        /// </summary>
        public string Level { get; init; }

        /// <summary>
        /// 問題文画像
        /// </summary>
        public Question Question { get; init; }

        /// <summary>
        /// 回答ボタン画像
        /// </summary>
        public ReadOnlyCollection<Answer> Answers { get; }

        /// <summary>
        /// </summary>
        /// <param name="level">問題の難易度</param>
        /// <param name="number">問題フォルダの番号</param>
        public Quiz(string level, int number)
        {
            //対象ファイルを取得
            var quizFolder = _contentsPath + @"\" + level + @"\" + number;
            string[] quizElements = Directory.GetFiles(quizFolder);

            //Questionを生成
            var questions = new List<Question>();
            var questionImgPath = quizElements.Where(o => o.Contains("question.png"));
            var questionVoicePath = quizElements.Where(o => o.Contains("question.mp3"));
            var questionPaths = questionImgPath.Zip(questionVoicePath, (iPath, vPath) =>
                new { ImgPath = iPath, VoicePath = vPath });
            foreach (var path in questionPaths)
            {
                var question = new Question(path.ImgPath, path.VoicePath);
                questions.Add(question);
            }
            Question = questions[0];

            //Answersを生成
            var answers = new List<Answer>();
            var answerPath = quizElements.Where(o => o.Contains("answer", StringComparison.CurrentCulture));
            foreach (var path in answerPath)
            {
                var answer = new Answer(path);
                answers.Add(answer);
            }
            Answers = answers.AsReadOnly();
        }
    }
}

```
```コンテンツディレクトリ構成
resources
    └─quizset
       ├─easy
       │  └─1
       │          answer1-correct.png
       │          answer2.png
       │          answer3.png
       │          question.mp3
       │          question.png
       │
       ├─hard
       │  └─1     answer1-correct.png
       │          answer2.png
       │          answer3.png
       │          question.mp3
       │          question.png
       │
       └─normal
          └─1     answer1-correct.png
                  answer2.png
                  answer3.png
                  question.mp3
                  question.png
```
### 補足情報（FW/ツールのバージョンなど）
Visual Studio 2022
C#10.0
WPF
