常連

## テーマ、知りたいこと

なぜ特にＭＶＣフレームワークなどで、サーバーはステートレスが原則なのに動的クラスを使うんでしょうか？

## 背景、状況

サーバーはステートレスで状態を持たないにもかかわらず、クラスになっているのか分からないです。
modelはstaticなのも多いですが、コントローラーやサービスクラスが動的なのはどうしてですか？
全部静的クラスでいいのではないでしょうか。
もしかしてＤＩなどをやる都合でしょうか？

オブジェクトが状態を保持していい事あるのでしょうか。

諸兄のご意見を伺いたく存じます。


なぜフレームワークなどで、サーバーはステートレスなのに動的クラスを使うんですか？

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

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

### 前提

現在LaravelをAPIサーバーとして、認証にLaravel Sanctumを使ってNextjsでフロントエンドの構築を行なっています。

- バックエンド → api.ドメイン (EC2 auto scale) ...リポジトリA
- フロントエンド(要ログイン) → app.ドメイン (Vercel isg + csr + ssr) ...リポジトリB 
- ランディングページ(非ログイン) → ドメイン (Vercel ssg + isg) ...リポジトリC

ここまで全く問題なく所謂よくある設計です。≒ ベストプラクティス

さらにマルチログインに関してもguardを使うことでユーザー用と管理者用でログインセッションを分けることができます

---

ここからが質問内容であり
管理者サイトを作るための選択肢がいくつか存在します。

#### 1. Laravel製のリポジトリAで管理しbladeファイルを返す

api.ドメイン/admin以降にアクセスした場合、bladeファイルを返します

```php　[web.route]
Route::middleware([])->group(function () {
    Route::prefix('admin')->group(function(){
        Route::get('/', function(){
            return blade file
        });
    });
});
```
**メリット**
- 他2つに比べてリポジトリが増えないので管理が楽。
- ユーザーが操作するようなリッチな機能や操作性も必要なく、サービスクラスやリポジトリクラスを使い回すことができる。
- サーバーが増えない。

**デメリット**
- api.ドメイン/adminというapi感があるURLなのにbladeが帰ってくる。
- URLを知ってるとユーザーがアクセスできてしまう。ログインページが表示されるだけでそもそもダサい。

**追加されるエンドポイント**
- api.ドメイン/admin ~

#### 2. nextjs製のリポジトリDを新たに作り管理する

admin.ドメインにNextjsを置き、
api.ドメイン/adminに対しリクエストを行いjsonファイルをNextjsで処理

```php　[web.route]
Route::middleware([])->group(function () {
    Route::prefix('admin')->group(function(){
        Route::get('/', function(){
            return json
        });
    });
});
```

**メリット**
- バックエンドとフロントエンドの書き方が変わらない。 ( 現状と同じようにバックエンドの人はjson返せばいい、フロントエンドはjson受け取ってjsxに流し込むだけでいい )
- なんかかっこいい

**デメリット**
- 他2つに比べてコード量が多い。
- わざわざvercelで管理するほどのものなのか？
- リポジトリが増える。
- URLを知ってるとユーザーがアクセスできてしまう。ログインページが表示されるだけでそもそもダサい。
- admin用のAPIエンドポイントが存在することがバレる

**追加されるエンドポイント**
- api.ドメイン/admin ~
- admin.ドメイン ~

#### 3. Laravel製のリポジトリDを新たに作り管理する

admin.ドメインにLaravelを置き、
リポジトリAと同じDBを共有する(.envのDB_HOST)

```php　[web.route]
Route::middleware([])->group(function () {
    Route::get('/', function(){
        return blade file
    });
});
```

**メリット**
- 管理？保守？は辛いが副作用が少ない？
- 完全にユーザーと分かれてるので分岐処理が減り可読性が高まる。
- ユーザーが操作するようなリッチな機能や操作性も必要ないのでbladeで十分。
- 一番やっすいEC2を用意して使うときだけ起動すれば、安いしセキュリティ○。

**デメリット**
- サービスクラスやリポジトリクラスなどの再実装が必要。 ( 管理者が追加するデータはユーザーは参照しかしないので100％コピペ再実装というわけでもない ) →正直ここ次第な気がする
- リポジトリが増える。
- 若干、他2つよりかはセキュリティが劣る。 ( 攻撃対象が増える ) でもワンチャン高まる

**追加されるエンドポイント**
- admin.ドメイン ~

---

**おそらくこの3パターンになるかと思われますが、どれが一般的な実装なのでしょうか？
もしくは好みでも、理想論でも大丈夫です。**

僕が取りこぼしたメリットとデメリットもあったら教えて欲しいです。

記載されていないパターン4、リポジトリBで管理する app.ドメイン/admin は多分sanctum周りでしんどいのとランディングページが分かれてるので管理者も分けるのが適切だと結論づけ排除しました。

作業者/管理者は僕一人ですが、サービスのスマホアプリ化などに伴って作業者/管理者の追加も発生する可能性があります。( 作業者...エンジニア、管理者...操作する人 )

またlaravelとnextjsは別にruby on railsとnuxtjsとかで置き換えてもらって構いません。

laravel9とnext14 app routerで実装してますが、バージョンとかもどうでも良いです。
実装経験年数は両者3-5年以上はあり実装自体の不安はありません。



管理者サイトのエンドポイントについて

前提
現在、要件定義フェーズを任されています

発生している問題・エラーメッセージ
要件定義書を書く際、「機能」をどう捉えるとうまく要件定義ができるのかがわからず、自信のないまま作成している状態です。
要件定義を行う際の「良い思考法」、「参考となる書籍・情報源」、または要件定義をうまく行うための「トレーニング方法」など、要件定義のスキルを向上させる一助となるものを教えていただけないでしょうか？

調査したこと
UML図として、状態遷移図やDFD、シーケンス図など様々な観点で機能を捉え、記述する方法があるということを調査しました。

※意図的に内容が抹消された質問 という修正依頼が来ていますが、そのようなことはしておりません。ご安心ください。

要件定義のスキルを向上させたい

### 実現したいこと
テーブルで、textとfileのいずれかをもつテーブルを作成する場合、
データタイプを区別するための、data_typeのカラムは必要でしょうか？



### 発生している問題・分からないこと
質問の背景

フロントはReactでバックエンドはRailsのでAPIとして実装しています
バックエンドで、textかfileのいずれかを必ず保存するバリデーションを追加したいのですが、

textからfileのどちらともないだけバリデーションエラーを出すだけで、APIの設計的に良いのか
あるいは、data_typeカラムも作成し、フロントからは data_typeとtext or fileをわたした方が良いのか迷っています

ご回答いただけますと幸いです



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

```
特になし
```

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

##### 上記の詳細・結果
自分的には、data_typeと text かfileの両方を設定した方が良いのでは？と思っています
理由はフロントの制御任せになると思った為です


### 補足
特になし

enumのカラムの追加の必要性

## 様々な条件があるクーポンのドメインモデリング

注文情報・顧客情報・期間限定セールなどに応じて
・注文全体への割引
・特定の商品への割引
・特定のカテゴリ（ブランド）への割引
・割引ではなく、固定金額になる。（クーポンを使うと200円など）
・送料無料
・回数制限
など

ドメインを跨いで影響する様々な仕様を持つクーポンと注文クラスについてのドメインモデリングについて

他の方がどのようにクラスを実装するか、お聞きしたいです。

## 状況
特に既存のシステムがあるわけではなく、注文と注文に対して使用できるクーポンがある場合にどのようにモデリングしたらいいだろうという意見交換です。

#### 概要
・OrderクラスはCouponの配列を持ったImmutableなクラス。
・OrderDetailクラスは商品情報を持った注文詳細クラス（各注文商品の金額を持つ）
・CouponクラスはCouponInterfaceを使用することで、様々な仕様のクーポン機能が可能

Orderクラス
```php
<?php
namespace App\Beer;

use App\Beer\Interface\CouponInterface;

class Order {

    private ?int $id;

    private int $price;

    private Customer $customer;

    private OrderDetails $orderDetails;

    private Coupons $coupons;

    private DeliveryFee $deliveryFee;

    public function __construct(
        ?int $id,
        int $price,
        Customer $customer,
        OrderDetails $orderDetails,
        Coupons $coupons,
        DeliveryFee $deliveryFee,
    ) {
        $this->id = $id;
        $this->price = $price;
        $this->customer = $customer;
        $this->orderDetails = $orderDetails;
        $this->coupons = $coupons;
        $this->deliveryFee = $deliveryFee;
    }

    public function getId(): ?int {
        return $this->id;
    }

    public function getPrice():int {
        return $this->price;
    }

    public function getTotalPrice():int {
        return $this->price + $this->getDeliveryFee()->getValue();
    }

    public function getCustomer():Customer {
        return $this->customer;
    }

    public function getOrderDetails(): OrderDetails {
        return $this->orderDetails;
    }

    public function getCoupons():Coupons {
        return $this->coupons;
    }

    public function getDeliveryFee():DeliveryFee {
        return $this->deliveryFee;
    }

    public function addCoupon(CouponInterface $coupon) {
        $this->coupons = $this->coupons->addCoupon($coupon);
    }

    public function addOrderDetail(OrderDetail $orderDetail) {
        $this->orderDetails->addOrderDetail($orderDetail);
    }

    public function hasProduct(Product $product):bool {
        return $this->orderDetails->hasProduct($product);
    }
}
```
OrderDomainService
```php
<?php
namespace App\Beer\DomainService;

use App\Beer\Coupons;
use App\Beer\Order;
use App\Beer\Interface\CouponInterface;

class OrderDomainService {

    public function __construct(
        
    ) {
        
    }

    public function couponIsApplicable(Order $order, CouponInterface $coupon):bool {
        // TODO:: すでに適用されているクーポンとの状況も確認する必要がある
    
        return $coupon->isApplicable($order);
    }

    public function applyCoupon(Order $order, CouponInterface $coupon): Order {
        $order->addCoupon($coupon);

        $appliedOrder = $this->calculateCouponsOrder($order);

        return $appliedOrder;
    }

    private function calculateCouponsOrder(Order $order):Order {
        $orders = [];
        $coupons = $order->getCoupons()->asArray();

        $combinations = $this->permutation($coupons);
        // クーポンの適用順で最も最小金額になる組み合わせを探す
        foreach ($combinations as $coupons) {
            $couponCollection = new Coupons($coupons);
            $appliedOrder = $couponCollection->apply($order);
            $orders[] = $appliedOrder;
        }
        // 最小注文金額のOrderを返す
        $minTotalPriceOrder = $this->getMinTotalPriceOrder($orders);

        return $minTotalPriceOrder;
    }

    private function getMinTotalPriceOrder(Array $orders):Order {
        $totalPrices = [];
        foreach($orders as $order) {
            $totalPrices[] = $order->getTotalPrice();
        }

        $minTotalPriceIndex = array_keys($totalPrices, min($totalPrices))[0];

        return $orders[$minTotalPriceIndex];
    }

    // 本来は渡された配列の順列を返す
    private function permutation(array $arr): array {
        return [
            [$arr[0],$arr[1]],
            [$arr[1],$arr[0]],
        ];
    }
}
```
Couponsクラス
```php
<?php
namespace App\Beer;

use App\Beer\Interface\CouponInterface;

class Coupons {

    private Array $coupons;

    public function __construct(
        Array $coupons,
    ) {
        $this->coupons = $coupons;
    }

    public function asArray():Array {
        return $this->coupons;
    }

    public function addCoupon(CouponInterface $coupon):self {
        $this->coupons[] = $coupon;

        return new Coupons($this->coupons);
    }

    public function apply(Order $order): Order {
        foreach($this->coupons as $coupon) {
            $order = $coupon->apply($order);
        }

        return $order;
    }
}
```

ProductCouponクラス
```php
<?php
namespace App\Beer;

use App\Beer\Enums\CouponTarget;
use App\Beer\Enums\DiscountType;
use App\Beer\Interface\CouponInterface;

class ProductCoupon implements CouponInterface {

    private String $couponCode;

    private int $specificPrice;

    private Product $product;

    public function __construct(
        String $couponCode,
        int $specificPrice,
        Product $product
    ) {
        $this->couponCode = $couponCode;
        $this->specificPrice = $specificPrice;
        $this->product = $product;
    }

    public function isApplicable(Order $order): bool {
        return $order->hasProduct($this->product);
    }

    public function apply(Order $order):Order {
        $appliedOrderDetails = [];
        foreach($order->getOrderDetails()->asArray() as $orderDetail) {
            if ($orderDetail->getProduct()->getProductCode() == $this->product->getProductCode()) {
                $appliedOrderDetail = new OrderDetail(
                    $orderDetail->getId(),
                    $this->specificPrice,
                    $this->product,
                );
                $appliedOrderDetails[] = $appliedOrderDetail;
            } else {
                $appliedOrderDetails[] = $orderDetail;
            }
        }
        $orderDetails = new OrderDetails($appliedOrderDetails);

        $appliedOrder = new Order(
            $order->getId(),
            $orderDetails->getTotalPrice(),
            $order->getCustomer(),
            $orderDetails,
            $order->getCoupons(),
            $order->getDeliveryFee(),
        );

        return $appliedOrder;
    }

    public function getCouponTarget(CouponTarget $couponTarget): CouponTarget
    {
        return CouponTarget::PRODUCT_CODE;
    }

    public function getDiscountType(DiscountType $discountType): DiscountType
    {
        return DiscountType::SPECIFIC_PRICE;
    }
}
```

CouponInterface
```php
<?php
namespace App\Beer\Interface;

use App\Beer\Enums\CouponTarget;
use App\Beer\Enums\DiscountType;
use App\Beer\Order;

interface CouponInterface {

    public function isApplicable(Order $order): bool;

    public function apply(Order $order):Order;

    public function getCouponTarget(CouponTarget $couponTarget):CouponTarget;

    public function getDiscountType(DiscountType $discountType):DiscountType;
    
}
```

### 聴きたい意見
#### クーポンの割引の適用処理をOrderクラスで行うべきか、OrderDomainServiceで行うべきか

Orderクラスからクーポンの適用処理を行おうとすると、金額を変更したOrderDetailや DeliveryFeeを持ったOrderクラス（自分自身）を返す必要があり、不自然な処理になっている気がします。

一方、OrderDomainServiceにOrderとCouponクラスを渡し、割引が適用されたOrderクラスを受け取るようにすると
適用処理はDomainServiceに任せているのに、Orderはどのクーポンが適用されているか把握する必要があるためCoupon配列を持っているという違和感を感じます。

現状、OrderDomainServiceで実装する方が良いと考えていますが、他の方法も含めて意見を聴きたいです。


注文とクーポンのドメインモデリングについて

### 今の状況
現在、あるゲームを作ろうと考えておりクラス設計から入っています
ゲーム制作自体はいくらか経験しており、ある程度のひな型は出来ているのですが...
いつも、別クラスの情報が欲しい
→ コンストラクタの引数に対して予め参照を持たせる
→ 大量の引数に加え道中のクラスのコンストラクタにも引数を渡し必要があり大変
といった事態になっております。

### 例
例えば、初代マリオのような2Dアクションゲームを画面分割で4人同時に遊べるゲームを作りたいとします。
各々の画面に移動に必要なゲージが用意されており、移動する度に消費される要素があります。

管理しやすくする為に、GameManagerで各Managerを生成し
GameManagerから呼ばれる、Init(), Update(), OnGameStart(), OnGameEnd()などの関数が呼ばれ
各々のマネージャにある同名の関数が呼ばれるようにします。

```
GameManager
├ InputManager
├ AnimManager
├ UIManager 
├ PlayerManager
.....└ Player * 4
```

そこで、今回はPlayer.Update()内にて入力を検知し、移動したいと考えました。
ですがそれには別クラスの参照がそれぞれ必要です。

具体的には
・InputManagerでボタンを十字ボタンをどれだけ押したか
そもそも移動出来る状態にあるか確認する必要があります。

・移動出来た場合は、AnimationManagerで移動アニメーションの描画
更にUIManagerで移動に応じてゲージを減らさなければなりません。

こういった状況ではいつも、先にPlayerManager以外を生成して
PlayerManagerのコンストラクタでそれぞれの弱参照を渡したりしています。

```C++
GameManager::GameManager{
  m_input = std::make_shared<InputManager>();
  m_anim = std::make_shared<AnimManager>();
  m_ui = std::make_shared<UIManager>();
  m_player = std::make_shared<PlayerManager>(m_input, m_anim, m_ui);
}

PlayerManager::PlayerManager(
  std::weak_ptr<InputManager> input,
  std::weak_ptr<AnimManager> anim,
  std::weak_ptr<UIManager> ui){

  for(int i = 0; i < 4; i++){
    m_playerVec.push_back(Player(input, anim, ui));
  }
}
```
正直、とても面倒です...

### 結局何が聞きたいのか
以下の2点です。
1 - このように別クラスの参照を多く持たなければならない場合は、どのようにするべきなのか
(引数をすべて1つの構造体で纏めるとか...?、シングルトンパターンで特定の情報だけ公開させるとか...?)

2 - そもそもこの「社長に課長から平社員まで作らせて、初日に必要書類全部渡す」スタイルが良くない気がするのですが
ゲーム設計を学ぶ上で何か参考にしたほうがいいところとかありますか？

ようやく基本構文が分かるようになったので、設計も進めていきたいです。
よろしくお願いします。


C++でゲームのクラス設計をしていますが、別クラスの参照が必要なためコンストラクタの引数が非常に多くなってしまう

### 聞きたい事

main(String[] args)を持つクラスをどう扱うのか。
また、どのクラスが持つべきなのか。

### 前提及び現状

Javaで自習のアウトプット兼、英語勉強用に英単語出題ソフトを作っています。
一度完成はしたのですがプログラミングの練習としてより洗練・改善できるように何度も作り直しています。
初めて作った時から思っていたのですが、Mainクラス（正確に言うとmain(String[] args)を持つクラス）はどのように扱うべきなのでしょうか？
現状は以下の通りGUIクラス（GUI全体を管理するようのクラス）にMyFileIOクラスを用いて英単語を読み取る等の処理を預けているのですが、これならばGUIクラスにmain(String[] args)メソッドを入れればいいのですが、GUIクラスが全体を管理するべきなのか？と思っています。
ただこのソフトではGUI以外に主に処理がないのでこのソフトに限ればGUIクラスに入れるのが最適なのでしょうか？
また単語を読み取るのを別スレッドにする場合GUIクラス内で生成するべきか、Mainクラスで両方の管理をすべきなのか。

### 現状の「main(String[] args)」の場所（★の付いているクラス）
```
MyDictionaly
┗ GUI ━ GUIクラス
┃　　　┗ FirstPanelクラス
┃　　　┗ ProblemPanelクラス
┃　　　┗ ：
┃　　　┗ ：
┃
┗ Systems ━ Wordクラス
┃　　　　　┗ MyFileIOクラス
┃　　　　　┗ ：
┃　　　　　┗ ：
┃
┗ Mainクラス ★
```

### Mainクラスのソースコード

```Java
import GUI.GUI;

public class Main {
  public static void main(String[] args){
    GUI g = new GUI();
    g.show();
  }
}
```


設計相談