Swiftにおけるプロトコル指向設計の考え方についての質問

Question

前提・実現したいこと

Swiftにおけるプロトコル指向設計の考え方

最近Swiftの勉強を始めました。
Java経験者です。
Swiftは色々な書き方があって何を勉強するか悩みましたが、
今後普及していくであろうことを見込んで最近発表されたSwiftUIを使ってみることにしました。
一通り基本構文を勉強し、さっそく一本アプリを作ってみようとしたところで、
オブジェクト指向の考え方との違いで躓いてしまいました。
例えば、次のような実装を行う場合、どのような設計にするべきなのでしょうか？

作りたい機能例

商品名	値段	個数	購入日
みかん	50	10	2019/10/18
りんご	100	5	2019/10/18

こんな感じのテーブルに、複数画面に渡って情報を入力して登録を行いたいです。
画面１：商品名入力
画面２：値段入力
画面３：個数入力
画面４：購入情報の確認
各画面にあるTextFieldに購入情報を入れ、最後の画面で購入情報を出力し、
情報を確認して決定ボタンを押したらテーブルに登録される

購入情報のクラスを作り、インスタンス化して最初の画面にオブジェクトを渡す
→商品名の変数に格納し、次の画面にオブジェクトを渡す
・・・・
→最後の画面でオブジェクトの情報からテーブルに登録
上記の手順で考えていましたが、この実装はやはり設計思想的に好ましくないのでしょうか？
好ましくない場合、どのような実装にするべきなのでしょうか？

また、上記とは別の質問になってしまうのですが、
上記の画面１〜３が全て同じ構成（タイトル・テキストフィールド・次へボタンが入ったView）だとすると、
Viewに準拠してタイトル・テキストフィールド・次へボタンを定義したプロトコルを作成して、それに準拠させる形で実装するのかなと思っていたのですが、
この考え方は間違っているのでしょうか？
とういうのも、テキストビューやボタンを配置するのはbodyの中になると思うのですが、
bodyを実装すること自体はプロトコルで定義できても、その中身まで定義する手段が分からず、どうやって実装すればいいのか分かっていない状態です。。。

Comments

[t_obara]

ユーザ的に、個々の情報を別画面で入力させられるのは苦痛かと思います。
少なくとも画面1〜3は同じ画面にした方が良いですよね。勉強のためにあえてという事であれば良いのですが。

> 購入情報のクラスを作り、インスタンス化して最初の画面にオブジェクトを渡す
→商品名の変数に格納し、次の画面にオブジェクトを渡す

私もそのようにすると思います。何か気になる点はあるのでしょうか？先に提示した画面を一つにする構成であっても同様な形になるかと思います。

[SwiftGanbaruMan]

申し訳ありません、返信が遅くなってしまいました。
UI的に問題があることは承知していますが、アプリの構想的に別画面で入力したいので、あえてという認識でお願いします。

> 私もそのようにすると思います。何か気になる点はあるのでしょうか？先に提示した画面を一つにする構成であっても同様な形になるかと思います。

ご回答ありがとうございます。
プロトコル指向なのにこのようなオブジェクト指向的な設計をしてしまって問題ないのでしょうか？もしかしたらプロトコル指向で考えたら一画面毎に書き込むのでは。。。？と思った次第です。
また、上記とは別の質問になってしまうのですが、
上記の画面１〜３が全て同じ構成（タイトル・テキストフィールド・次へボタンが入ったView）だとすると、
Viewに準拠してタイトル・テキストフィールド・次へボタンを定義したプロトコルを作成して、それに準拠させる形で実装するのかなと思っていたのですが、
この考え方は間違っているのでしょうか？
とういうのも、テキストビューやボタンを配置するのはbodyの中になると思うのですが、
bodyを実装すること自体はプロトコルで定義できても、その中身まで定義する手段が分からず、どうやって実装すればいいのか分かっていない状態です。。。（こちら質問文にも記載させていただきます）

Answer 1

プロトコル志向という点で懸念を示されていたのですね、あまり深く捉えておりませんでした。
今回の例題では特にプロトコルを持ち込まなくても良いと考えていました。

画面１〜３が全て同じ構成（タイトル・テキストフィールド・次へボタンが入ったView）だとすると、

Viewに準拠してタイトル・テキストフィールド・次へボタンを定義したプロトコルを作成して、それに準拠させる形で実装

敢えて共通画面コンポーネントを作成し、それを利用するだけで処理が全く同じで、実装が楽になるのであればプロトコルを利用しても良いと思いますが、処理にそれぞれ違いがあるのであれば、見通しも悪くなりがちでわざわざ導入する必要がないと思われます。
UIライブラリを構成するのであれば、考えても良いかもしれません。

例えばですが、以下Qiita記事の「共通のUIコンポーネントを持ったViewへ共用関数を提供する」という部分が期待している内容かと思います。
https://qiita.com/xxxAIRINxxx/items/c076edc1ffb680a45c25

ただ、StoryBoardで接続が切れそうですし、ソースコードの見通しも悪くなり勝ちなのでUI部品の共通化は個人的にはやらないと思いますが。
それより画面自体を共通化して、データだけを差し替える形で実装を進めると思います。

イメージとしては、TableViewのDataSource delegateですかね。

Comments

[SwiftGanbaruMan]

ご回答ありがとうございます。
まさにご提示いただいた記事のようなことをやろうとしていました。

＞ それより画面自体を共通化して、データだけを差し替える形で実装を進めると思います。
そうですね、一旦その形で実装してみようと思います。
親身にご相談に乗っていただきありがとうございましたm(__)m