常連

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

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

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

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

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

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

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

### 実現したいこと
フロントエンドをVue、バックエンドをJavaでWebアプリを作成しています。
バックエンドでのAPIの実装のパターンで2つのケースを想定しているのですが、どちらが一般的な手法であるかを知りたいです。

### 発生している問題・分からないこと
複合的なデータが更新されるケースでのAPIの実装方法がわからないです。

例えば、販売管理システムを考えると、
お客様からの注文を受けた時点で営業担当が何らかのフォームにデータを入力することで、お客様の情報や注文情報などが顧客テーブルや注文テーブルにインサートされると思います。

1つのフォーム処理で複数のテーブルに更新が走るケースでの実装方法ですが、
①バックエンドのAPIをREST APIで実装していた場合、以下のようなURIになると思います。
/api/customer (顧客の新規作成)
/api/order (注文の新規作成)
このような場合、フロントエンドでは顧客のデータを更新するためのAPIをそれぞれ2回呼び出すのでしょうか？

②もしくは複合データモデルを作っておいて、
/api/orderreceive
のようなAPIを一度だけ呼び出したら、その中で顧客の新規作成も注文の新規作成も行われるような形でしょうか？

①だとフロント側の呼び出しが冗長になるのと、API呼び出しを繰り返すことでパフォーマンスに悪影響が出るのではと思っていて、
②だとバックエンドをREST APIで実装していた際に、RESTの原則に反する実装になってしまわないかと思っています。

私はWeb開発初心者のため、認識に間違いがあれば、指摘いただけますと幸いです。また、情報に不足があれば、可能な限り補足しますので、コメント頂けたらと思います。よろしくお願いします。



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

```
特になし
```

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

##### 上記の詳細・結果
書籍等もいくつか確認しましたが、初心者向けの書籍では求めている情報を見つけられませんでした。

### 補足
特になし

フロントエンドとバックエンドのデータをやりとりする際のAPI実装について

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

形式手法はほんとうに流行っていないのか。それとも形式手法は使われる現場が少ないだけなのか。
現状を巡る形式手法について意見交換できたら幸いです。

## 背景、状況

タイトルの通り、大学の課題で「形式手法の利用があまり流行っていないとする議論を調べ、その根拠を考察して下さい」と出ました。
英語で調べたら議論が出ることは確認していますが、日本語で調べると形式手法について議論している場面が少ないので、テラテイルで意見交換の場を設けてみました。

正直、組み込み開発や人命に関わる内容（病院や航空などのシステム）では多く使われているのを知っている以上、この書き出しと課題は少し悪意を感じる書き出しと感じています。

大学の課題で「形式手法の利用があまり流行っていないとする議論を調べ、その根拠を考察して下さい」と出た。

日頃メソッドを作るとき、パラメータがプロパティに存在するものはメンバを参照、そうでない場合は引数を追加するというような規則でコードを書いていますが、これってベストプラクティスなんでしょうか？

私としては、ユーザが必要最小の単位でパラメータを渡せれば楽だと、書く側もプロパティで使いまわせれば余計なパラメータの再定義を割けて楽だと、そのように思っていました。

しかし、いっそパラメータを引数に明示することでメソッドの処理が何のデータを要しているかが明確になったり、メソッド単位での単体テストが楽になるかもといった反対の視野もあるのかなと考えてポリシーを決めあぐねてしまいました。

もしそういった、広く共有される知見に沿ってないなら是正したいので質問しました。
特にそういうのがなければ個人的なご意見でも結構です。

OOPでメソッドへパラメータ受渡しに引数とプロパティのどちらを使うか

### わからないこと、回答してほしいこと
AndroidアプリをKotlinで開発する際、DB接続やIO処理のような一般的に重い処理は非同期で行うような設計思想になっていると思うのですが、仮にinsertが失敗したとか、DBにおいて重複禁止項目のバリデーションエラーに引っかかったなどは、どのようにユーザーに伝えるのが一般的なのかわからないのですが、
こういったアプリの基本的な処理についてのサンプル(入門)プログラムなどは公式から提供されていないのでしょうか？

# 補足、前提
(そもそもDBサーバーに接続に行くのがスマホからだと微妙でAPIサーバーを立てろみたいな意見もありそうですが、すでに利用しているソフトウェアについて、モバイル対応とかもあるとは思うので。。。)

## 関連してUIのトーストについて
以前自分は、トーストは非推奨で、スナックバーを利用すべきというのを見た記憶があり、今回質問の際に再検索してみたところ、以下の内容がヒットしました。
https://developer.android.com/reference/android/widget/Toast

内容からして私が以前確認した、トーストは非推奨というのは誤訳かなにかを確認しただけなのかなと思うのですが、特に理由なくトーストを利用してよいのでしょうか？

## 質問内容のおさらい
非同期処理の実行結果に対してUIに伝えるためのサンプルなどはあるでしょうか？
ユーザーエクスペリエンスのために、UIを思うように動かせないような処理(例えばポップアップによる選択)なども極力してはいけないという認識ですが、
サーバーとの処理はどのくらいかかるかわからず、画面遷移や応答の確認を待たず、即アプリを終了するなどのユーザー操作が考えられますが。

こういうアーキテクチャというか、スマホアプリの設計をする上で必須レベルの情報ってどこで参照すればよいのでしょう？

# お詫び
※話したいことが多すぎてまとまりがないと感じるかもしれませんが、これでも一つの議題に絞ってそれ以外の内容は省いているつもりです。
恐縮ですがよろしくお願いします。

AndroidアプリにおけるDB処理のインタラクティブな

あるユーザーのリクエストから別のユーザーの情報を更新してもいいのでしょうか。
例えば、Webアプリのゲームを作っていて、
あるユーザーから別のユーザーとバトルするというリクエストが送られてきた場合、自分と相手のHPを減らします。
このとき同じリクエスト内で自分のHPと相手のHPを更新してしまうと、別のユーザーの情報を更新できることになってしまいますが問題でしょうか？

同じリクエスト内では相手のユーザーの更新はせず攻撃を受けたイベントだけを記録し、相手ユーザーからのリクエストがあったときにイベントをまとめて処理する。などをしたほうがいいのでしょうか？

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

あるユーザーのリクエストから別のユーザーの情報を更新してもいいのか

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

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

## 背景、状況

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

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

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


設計相談