GithubHelp home page GithubHelp logo

Comments (70)

uhooi avatar uhooi commented on June 23, 2024 1

継承されていないクラスには何も考えずに final を付けたい
https://github.com/sachiko-kame/architecture_iOS/blob/feature/MVP/sample/sample/ViewController.swift#L11

from architecture_ios.

sachiko-kame avatar sachiko-kame commented on June 23, 2024 1

面白くもありつい笑ってました！✨

from architecture_ios.

sachiko-kame avatar sachiko-kame commented on June 23, 2024 1

@sachiko-kame
こんな感じの内容が続きますが、大丈夫でしょうか…？

一旦休憩で、続きは後ほど見ます！

はい！とても助かります！
ありがとうございます！！✨

from architecture_ios.

sachiko-kame avatar sachiko-kame commented on June 23, 2024 1

です！
あとちょっとコメント編集しましたー

はい！！実は変更後すぐにみて確かに！となっていました。
ありがとうございます！🙇‍♀️

from architecture_ios.

sachiko-kame avatar sachiko-kame commented on June 23, 2024 1

@uhooi

現時点で指摘頂けたところ修正しました！
本当にありがとうございます！勉強になります！🙇‍♀️

76a8d89

from architecture_ios.

sachiko-kame avatar sachiko-kame commented on June 23, 2024 1

@uhooi

レビューがとても分かりやすかったのが大きかったかと思います！

自分であやふやだったり悩んでいたことなどもuhooiさんのおかげで解消できたので本当に助かりました！✨

本当にありがとうございます！🙇‍♀️✨

from architecture_ios.

sachiko-kame avatar sachiko-kame commented on June 23, 2024 1

自分はViewに単体テストを書きたくなく、できる限りViewに分岐（if, switch）を入れたくないので、 presenter.itemGet() メソッドの戻り値はオプショナル型じゃない方がいいです！
https://github.com/sachiko-kame/architecture_iOS/blob/feature/MVP/sample/sample/ViewController.swift#L59

分岐はPresenter側のメソッドに入れて、あとTableViewのデータソースで取得するのではなく、 viewDidLoad() などで予め取得するといいと思います！

データソース以外の取得方法がそもそもわかっていなかったので考えます！

from architecture_ios.

sachiko-kame avatar sachiko-kame commented on June 23, 2024 1

変数名で、 numberOfItems より普通に itemCount でいいと思いました笑
https://github.com/sachiko-kame/architecture_iOS/blob/feature/MVP/sample/sample/Presenter.swift#L12

そこまで配慮できていなかったです！汗
ありがとうございます！
以後気をつけます！

from architecture_ios.

sachiko-kame avatar sachiko-kame commented on June 23, 2024 1

変数名で、 numberOfItems より普通に itemCount でいいと思いました笑
https://github.com/sachiko-kame/architecture_iOS/blob/feature/MVP/sample/sample/Presenter.swift#L12

これは私も実は『itemCount派』です。
どっちも良いと今英和辞書で調べてはっきりしたので『itemCount』に変更したいと思います！

ちなみに、
『number』の方がいいのか調べて
『number』は『数』とでるのに対して、『Count』は『数える』で出てきたので『number』の方がいいのかな？と『numberOfItems』にしてしまいました汗

from architecture_ios.

sachiko-kame avatar sachiko-kame commented on June 23, 2024 1

ModelもUIKitのインポート禁止〜！笑
https://github.com/sachiko-kame/architecture_iOS/blob/feature/MVP/sample/sample/Model.swift#L9

すみません！

from architecture_ios.

sachiko-kame avatar sachiko-kame commented on June 23, 2024 1

これは私も実は『itemCount派』です。
どっちも良いと今英和辞書で調べてはっきりしたので『itemCount』に変更したいと思います！

そもそも items.count を返してるので、素直に同じ名前を使っていいと思いました笑

確かに！同じ名前の方がしっくりきますよね！

from architecture_ios.

sachiko-kame avatar sachiko-kame commented on June 23, 2024 1

『アイテムを取得した』の中でアイテム取得の処理を書くというイメージの方がしっくりくる感じですかね？

すみません勘違いしました、、
これはViewから呼ばれているメソッドですね。
そしたら基本的にメソッドは動詞始まりがいいと思うので、 getItem() がいいと思います！

英語構文的に
i get item(SVO)ですもんね汗
修正します！

from architecture_ios.

sachiko-kame avatar sachiko-kame commented on June 23, 2024 1

このあたりもclassにはすべて final を付けるクセを付けるといいと思います！
https://github.com/sachiko-kame/architecture_iOS/blob/feature/MVP/sample/sample/Parts/Cell/TableViewCell.swift#L15

継承したくなったら外せばいいので笑

ありがとうございます！
そういって頂けるとfinalつけやすくなります。

from architecture_ios.

sachiko-kame avatar sachiko-kame commented on June 23, 2024 1

@IBOutlet や @IBAction には基本 private を付けて、外部からのアクセスを防ぐと、UIが外から変更されないことが保証されます！
https://github.com/sachiko-kame/architecture_iOS/blob/feature/MVP/sample/sample/Parts/Cell/TableViewCell.swift#L20-L22

ありがとうございます！
修正します！

from architecture_ios.

sachiko-kame avatar sachiko-kame commented on June 23, 2024 1

そしたら基本的にメソッドは動詞始まりがいいと思うので、 getItem() がいいと思います！

すみません、 get○○() はゲッターにしか付けたくないので、 loadItem() や fetchItem() などのほうがいいですね〜

勉強になります！
変更します！✨

from architecture_ios.

sachiko-kame avatar sachiko-kame commented on June 23, 2024 1

とりあえず以上です！

あとは単体テストを書いてみるのがいいと思います。
自分はアーキテクチャを「テストを書きやすくするため」にあると思っていて、「あ、ここテスト書きづらいな」と思ったら設計が悪いことが多く、設計の良し悪しに気づきやすくなります！
Viewは手動でテストすることが多いので、まずPresenterからテストを書くのがオススメです〜

ありがとうございます！
色々試行錯誤しながら試して考え反映していきたいと思います！
本当にありがとうございました！！✨

from architecture_ios.

sachiko-kame avatar sachiko-kame commented on June 23, 2024 1

DispatchQueue.main.async はViewでやればいいと思います！
https://github.com/sachiko-kame/architecture_iOS/blob/feature/MVP/sample/sample/Presenter.swift#L46

viewの処理開始一番最初に書くか、実際に描画している所で書くかの違いなのですかね？

はい！
描画の直前に書くと、そのメソッドを呼ぶたびに書かなくて済むので👍
あとは好みかもしれませんが、描画しないPresenterにこの処理があると違和感を感じます。

非同期の後に処理が遅くなるということでここに入れているのかな？と思いました。
正直今回の場合描画が遅いとかはなさそうなので『DispatchQueue.main.async』を書く必要がないのかもしれないと今更ながらに思ったりもしました。
非同期の中で描画が遅い時に出すでもいいのかとも思いました、、、

いや、そもそもiOSはメインスレッドでしかUIを更新できないので、データを非同期で取得するなら必須です！
試しに外してデバックすると、紫のアイコンで警告が出ますよ〜

確かに処理2回も書くのナンセンスですよね！
具体的に教えて頂いたのでとてもスッキリしました！
ありがとうございます！

from architecture_ios.

sachiko-kame avatar sachiko-kame commented on June 23, 2024 1

正直テストがあるだけで、「少なくともテストが書きやすい設計になってるんだな」とわかるので、それだけでも書くべきです！
逆にテストを書かずに良い設計で実装できる人すごいと思います…

そうですよね、お恥ずかしながらテスト自体をしっかり理解していないので勉強します！
すぐには出来ませんがより良いコードを書けるようになるために頑張っていきたいと思います！
なかなかこんなに丁寧に指摘して頂けることはなかったので本当に感謝です！
自分は凄い優しい方に恵まれたなと強く感じました！
本当にありがとうございました！
また修正確認後コミットしたいと思います！✨

from architecture_ios.

sachiko-kame avatar sachiko-kame commented on June 23, 2024 1

ありがとうございます！！✨

from architecture_ios.

sachiko-kame avatar sachiko-kame commented on June 23, 2024 1

超ウホーイの好みにリファクタリングしてみました笑https://github.com/uhooi/architecture_iOS/tree/feature/fix_mvp/sample/sample

diffが出過ぎると思うので、Xcodeを2つ起動してソースを見比べるといいかもしれませんｗ
あくまで参考で、間違っていることもあると思うので鵜呑みにしないでください〜

ありがとうございます！！🙇‍♀️
色々見比べたりして勉強させていただきたいともいます！！

from architecture_ios.

sachiko-kame avatar sachiko-kame commented on June 23, 2024 1

気になったらここでもTwitterでもどこでもいいので、何でも聞いてください〜✨

嬉しいです！
設計強い方が側にいるの心強いです！！
本当にありがとうございます！✨✨✨✨✨

from architecture_ios.

sachiko-kame avatar sachiko-kame commented on June 23, 2024 1

強いと思います！
理由がはっきりしているので通用すると思っています。
難しいとすぐ簡単な方に逃げてしまう私とは大違いで反省しています！
ウホーイさんを見習って勉強に励んでいきたいと思います！！✨

from architecture_ios.

sachiko-kame avatar sachiko-kame commented on June 23, 2024 1

あ、 setRead() は get○○() と同様の理由でよくないです！
read というプロパティにセットするセッターに見えるので、 setupForRead() のようにするといいです！

ありがとうございます！
修正します！✨

ありがとうございますｗ
簡単な方に逃げる考えは間違っていないと思います！
逃げ方ですよねｗ

ありがとうございます！
うまく出来るよう試行錯誤重ねていきたいと思います！✨

from architecture_ios.

sachiko-kame avatar sachiko-kame commented on June 23, 2024 1

あと if isRead == true {} は if isRead {} のように書くのが好みです。
前者は isRead が Bool? 型の場合に使うと、オプショナルかどうかがすぐにわかって可読性が上がります！
（ Bool? 型は if isRead {} と書くとビルドエラーになる）

確かにです！！
そう言った見方までできていなかったので非常にためになります！
ありがとうございます！✨

from architecture_ios.

sachiko-kame avatar sachiko-kame commented on June 23, 2024

『ウホーイが気になったところを書いていきます！』
がとてもチャーミングで素敵です！

修正します！

from architecture_ios.

uhooi avatar uhooi commented on June 23, 2024

チャーミング頂き光栄です✨

from architecture_ios.

uhooi avatar uhooi commented on June 23, 2024

変更しないプロパティは var でなく let にしましょう！
https://github.com/sachiko-kame/architecture_iOS/blob/feature/MVP/sample/sample/ViewController.swift#L13

from architecture_ios.

uhooi avatar uhooi commented on June 23, 2024

ついでにUI部品はできる限りInitialization Closureを使って初期化したい（これは好み）

    private let tableView: UITableView = {
        let tableView = UITableView()
        tableView.frame = UIScreen.main.bounds
        tableView.register(cellType: TableViewCell.self)
        return tableView
    }()

from architecture_ios.

sachiko-kame avatar sachiko-kame commented on June 23, 2024

変更しないプロパティは var でなく let にしましょう！
https://github.com/sachiko-kame/architecture_iOS/blob/feature/MVP/sample/sample/ViewController.swift#L13

はい！
すみません。
気をつけます！
修正します！

from architecture_ios.

uhooi avatar uhooi commented on June 23, 2024

setup() メソッドで「テーブルビューの初期化」と「アイテムの取得」の2つのことを行っているので、メソッドを分けるといいと思います！
https://github.com/sachiko-kame/architecture_iOS/blob/feature/MVP/sample/sample/ViewController.swift#L25-L32

自分ならこう書きます↓
あと self の有無は統一したい！笑

    override func viewDidLoad() {
        super.viewDidLoad()

        configureTableView()
        self.presenter.itemsGet()
    }
    
    private func configureTableView() {
        self.tableView.delegate = self
        self.tableView.dataSource = self
        self.view.addSubview(tableView)
    }

from architecture_ios.

uhooi avatar uhooi commented on June 23, 2024

@sachiko-kame
こんな感じの内容が続きますが、大丈夫でしょうか…？

一旦休憩で、続きは後ほど見ます！

from architecture_ios.

sachiko-kame avatar sachiko-kame commented on June 23, 2024

ついでにUI部品はできる限りInitialization Closureを使って初期化したい（これは好み）

    private let tableView: UITableView = {
        let tableView = UITableView()
        tableView.frame = UIScreen.main.bounds
        tableView.register(cellType: TableViewCell.self)
        return tableView
    }()

（これは好み)ってくれていますが結構こっちの方が好まれる印象です。
なかなかなれなくてこの書き方いつもできていないです。
修正します！

from architecture_ios.

sachiko-kame avatar sachiko-kame commented on June 23, 2024

setup() メソッドで「テーブルビューの初期化」と「アイテムの取得」の2つのことを行っているので、メソッドを分けるといいと思います！
https://github.com/sachiko-kame/architecture_iOS/blob/feature/MVP/sample/sample/ViewController.swift#L25-L32

自分ならこう書きます↓
あと self の有無は統一したい！笑

    override func viewDidLoad() {
        super.viewDidLoad()

        configureTableView()
        self.presenter.itemsGet()
    }
    
    private func configureTableView() {
        self.tableView.delegate = self
        self.tableView.dataSource = self
        self.view.addSubview(tableView)
    }

確かに！おっしゃる通りです！
沢山ありがとうございます！
修正します！

from architecture_ios.

uhooi avatar uhooi commented on June 23, 2024

Initialization Closureを使うと、例えばTableViewをCollectionViewに変えたくなったときに、そこだけ変えればいいのでわかりやすいです！
あとメソッド化されないので、初期化処理が一度しか呼ばれないことが保証できます。
（普通はやらないですが、 setup() メソッドを2回呼ぶことも理論上はできてしまうので）

from architecture_ios.

sachiko-kame avatar sachiko-kame commented on June 23, 2024

Initialization Closureを使うと、例えば�TableViewをCollectionViewに変えたくなったときに、そこだけ変えればいいのでわかりやすいです！
あとメソッド化されないので、一度しか呼ばれないことが保証できます。

確かに！利点の方が大きいですね！
ありがとうございます！

from architecture_ios.

uhooi avatar uhooi commented on June 23, 2024

です！
あとちょっとコメント編集しましたー

from architecture_ios.

uhooi avatar uhooi commented on June 23, 2024

すぐに対応していただけると、こちらもレビューしたかいがあって嬉しいです✨

from architecture_ios.

uhooi avatar uhooi commented on June 23, 2024

自分はViewに単体テストを書きたくなく、できる限りViewに分岐（if, switch）を入れたくないので、 presenter.itemGet() メソッドの戻り値はオプショナル型じゃない方がいいです！
https://github.com/sachiko-kame/architecture_iOS/blob/feature/MVP/sample/sample/ViewController.swift#L59

分岐はPresenter側のメソッドに入れて、あとTableViewのデータソースで取得するのではなく、 viewDidLoad() などで予め取得するといいと思います！

from architecture_ios.

uhooi avatar uhooi commented on June 23, 2024

MVPだったらView以外で import UIKit するのはよくないです。
import Foundation で済ませましょう！
https://github.com/sachiko-kame/architecture_iOS/blob/feature/MVP/sample/sample/Presenter.swift#L9

from architecture_ios.

uhooi avatar uhooi commented on June 23, 2024

変数名で、 numberOfItems より普通に itemCount でいいと思いました笑
https://github.com/sachiko-kame/architecture_iOS/blob/feature/MVP/sample/sample/Presenter.swift#L12

from architecture_ios.

uhooi avatar uhooi commented on June 23, 2024

個人的には itemGet() でなく itemGeted() だとアイテムをゲットした後の処理だとわかって好みです！
https://github.com/sachiko-kame/architecture_iOS/blob/feature/MVP/sample/sample/Presenter.swift#L43

from architecture_ios.

uhooi avatar uhooi commented on June 23, 2024

DispatchQueue.main.async はViewでやればいいと思います！
https://github.com/sachiko-kame/architecture_iOS/blob/feature/MVP/sample/sample/Presenter.swift#L46

from architecture_ios.

uhooi avatar uhooi commented on June 23, 2024

ModelもUIKitのインポート禁止〜！笑
https://github.com/sachiko-kame/architecture_iOS/blob/feature/MVP/sample/sample/Model.swift#L9

from architecture_ios.

sachiko-kame avatar sachiko-kame commented on June 23, 2024

個人的には itemGet() でなく itemGeted() だとアイテムをゲットした後の処理だとわかって好みです！
https://github.com/sachiko-kame/architecture_iOS/blob/feature/MVP/sample/sample/Presenter.swift#L43

確かに！私はゲットしにいくって感じでとらえてしましました！
『アイテムを取得した』の中でアイテム取得の処理を書くというイメージの方がしっくりくる感じですかね？

好み

の問題と言ってくれているので少し悩みたいと思います！

from architecture_ios.

uhooi avatar uhooi commented on June 23, 2024

これは私も実は『itemCount派』です。
どっちも良いと今英和辞書で調べてはっきりしたので『itemCount』に変更したいと思います！

そもそも items.count を返してるので、素直に同じ名前を使っていいと思いました笑

from architecture_ios.

uhooi avatar uhooi commented on June 23, 2024

『アイテムを取得した』の中でアイテム取得の処理を書くというイメージの方がしっくりくる感じですかね？

すみません勘違いしました、、
これはViewから呼ばれているメソッドですね。
そしたら基本的にメソッドは動詞始まりがいいと思うので、 getItem() がいいと思います！

from architecture_ios.

uhooi avatar uhooi commented on June 23, 2024

このあたりもclassにはすべて final を付けるクセを付けるといいと思います！
https://github.com/sachiko-kame/architecture_iOS/blob/feature/MVP/sample/sample/Parts/Cell/TableViewCell.swift#L15

継承したくなったら外せばいいので笑

from architecture_ios.

uhooi avatar uhooi commented on June 23, 2024

好みかもしれませんが、cellにqiitaを持たせる必要はないと思います！
https://github.com/sachiko-kame/architecture_iOS/blob/feature/MVP/sample/sample/Parts/Cell/TableViewCell.swift#L17

from architecture_ios.

uhooi avatar uhooi commented on June 23, 2024

@IBOutlet や @IBAction には基本 private を付けて、外部からのアクセスを防ぐと、UIが外から変更されないことが保証されます！
https://github.com/sachiko-kame/architecture_iOS/blob/feature/MVP/sample/sample/Parts/Cell/TableViewCell.swift#L20-L22

from architecture_ios.

uhooi avatar uhooi commented on June 23, 2024

ここでcellに分岐が入るのが気になります。
setRead() と setUnread() とセットのメソッドを2つ作って呼び分けると分岐をなくせます！
https://github.com/sachiko-kame/architecture_iOS/blob/feature/MVP/sample/sample/Parts/Cell/TableViewCell.swift#L38

from architecture_ios.

uhooi avatar uhooi commented on June 23, 2024

とりあえず以上です！

あとは単体テストを書いてみるのがいいと思います。
自分はアーキテクチャを「テストを書きやすくするため」にあると思っていて、「あ、ここテスト書きづらいな」と思ったら設計が悪いことが多く、設計の良し悪しに気づきやすくなります！
Viewは手動でテストすることが多いので、まずPresenterからテストを書くのがオススメです〜

from architecture_ios.

uhooi avatar uhooi commented on June 23, 2024

そしたら基本的にメソッドは動詞始まりがいいと思うので、 getItem() がいいと思います！

すみません、 get○○() はゲッターにしか付けたくないので、 loadItem() や fetchItem() などのほうがいいですね〜

from architecture_ios.

sachiko-kame avatar sachiko-kame commented on June 23, 2024

DispatchQueue.main.async はViewでやればいいと思います！
https://github.com/sachiko-kame/architecture_iOS/blob/feature/MVP/sample/sample/Presenter.swift#L46

viewの処理開始一番最初に書くか、実際に描画している所で書くかの違いなのですかね？

非同期の後に処理が遅くなるということでここに入れているのかな？と思いました。

正直今回の場合描画が遅いとかはなさそうなので『DispatchQueue.main.async』を書く必要がないのかもしれないと今更ながらに思ったりもしました。

非同期の中で描画が遅い時に出すでもいいのかとも思いました、、、

参考:
https://teratail.com/questions/52000

ちょっと悩みます汗

from architecture_ios.

sachiko-kame avatar sachiko-kame commented on June 23, 2024

https://github.com/sachiko-kame/architecture_iOS/blob/feature/MVP/sample/sample/Parts/Cell/TableViewCell.swift#L17

入れざるを得なかったという感じでした汗
cell内のボタンタップ時に値を送りたくて、、、
modelの方で変えるように実装した方がいいですかね？
すごく悩みます汗

from architecture_ios.

sachiko-kame avatar sachiko-kame commented on June 23, 2024

ここでcellに分岐が入るのが気になります。
setRead() と setUnread() とセットのメソッドを2つ作って呼び分けると分岐をなくせます！
https://github.com/sachiko-kame/architecture_iOS/blob/feature/MVP/sample/sample/Parts/Cell/TableViewCell.swift#L38

確かにそうですよね。viewの方で分岐する方が良いって感じですかね？
viewでの分岐ではアイテムが『あり』『なし』で行っていたのでcellのセットならコードもそんなに多くないしとつい入れてしまいました。

from architecture_ios.

uhooi avatar uhooi commented on June 23, 2024

DispatchQueue.main.async はViewでやればいいと思います！
https://github.com/sachiko-kame/architecture_iOS/blob/feature/MVP/sample/sample/Presenter.swift#L46

viewの処理開始一番最初に書くか、実際に描画している所で書くかの違いなのですかね？

はい！
描画の直前に書くと、そのメソッドを呼ぶたびに書かなくて済むので👍
あとは好みかもしれませんが、描画しないPresenterにこの処理があると違和感を感じます。

非同期の後に処理が遅くなるということでここに入れているのかな？と思いました。

正直今回の場合描画が遅いとかはなさそうなので『DispatchQueue.main.async』を書く必要がないのかもしれないと今更ながらに思ったりもしました。

非同期の中で描画が遅い時に出すでもいいのかとも思いました、、、

いや、そもそもiOSはメインスレッドでしかUIを更新できないので、データを非同期で取得するなら必須です！
試しに外してデバックすると、紫のアイコンで警告が出ますよ〜

from architecture_ios.

uhooi avatar uhooi commented on June 23, 2024

https://github.com/sachiko-kame/architecture_iOS/blob/feature/MVP/sample/sample/Parts/Cell/TableViewCell.swift#L17

入れざるを得なかったという感じでした汗
cell内のボタンタップ時に値を送りたくて、、、
modelの方で変えるように実装した方がいいですかね？
すごく悩みます汗

タップしたセルのインデックスをキーに、Qiitaのリストから取得するようにすれば持つ必要がなくなる気がします！
手を動かさないとわからないので、できなかったらすみません💦

from architecture_ios.

uhooi avatar uhooi commented on June 23, 2024

ここでcellに分岐が入るのが気になります。
setRead() と setUnread() とセットのメソッドを2つ作って呼び分けると分岐をなくせます！
https://github.com/sachiko-kame/architecture_iOS/blob/feature/MVP/sample/sample/Parts/Cell/TableViewCell.swift#L38

確かにそうですよね。viewの方で分岐する方が良いって感じですかね？
viewでの分岐ではアイテムが『あり』『なし』で行っていたのでcellのセットならコードもそんなに多くないしとつい入れてしまいました。

分岐はできる限り親側（うまく言えない…呼び出し元側、ですかね）で行う派です〜
今回は呼び出し元がViewなのでテストしにくいですが、テストしやすくなることが多いので！

from architecture_ios.

uhooi avatar uhooi commented on June 23, 2024

正直テストがあるだけで、「少なくともテストが書きやすい設計になってるんだな」とわかるので、それだけでも書くべきです！
逆にテストを書かずに良い設計で実装できる人すごいと思います…

from architecture_ios.

sachiko-kame avatar sachiko-kame commented on June 23, 2024

https://github.com/sachiko-kame/architecture_iOS/blob/feature/MVP/sample/sample/Parts/Cell/TableViewCell.swift#L17

入れざるを得なかったという感じでした汗
cell内のボタンタップ時に値を送りたくて、、、
modelの方で変えるように実装した方がいいですかね？
すごく悩みます汗

タップしたセルのインデックスをキーに、Qiitaのリストから取得するようにすれば持つ必要がなくなる気がします！
手を動かさないとわからないので、できなかったらすみません💦

cell内では今の所自分の力ではわからなかったのでmodel内で値変更を行うようにしました！
cellのボタンタップ　→　modelのisReadボタンを逆にして登録
という感じです。

from architecture_ios.

sachiko-kame avatar sachiko-kame commented on June 23, 2024

ここでcellに分岐が入るのが気になります。
setRead() と setUnread() とセットのメソッドを2つ作って呼び分けると分岐をなくせます！
https://github.com/sachiko-kame/architecture_iOS/blob/feature/MVP/sample/sample/Parts/Cell/TableViewCell.swift#L38

確かにそうですよね。viewの方で分岐する方が良いって感じですかね？
viewでの分岐ではアイテムが『あり』『なし』で行っていたのでcellのセットならコードもそんなに多くないしとつい入れてしまいました。

分岐はできる限り親側（うまく言えない…呼び出し元側、ですかね）で行う派です〜
今回は呼び出し元がViewなのでテストしにくいですが、テストしやすくなることが多いので！

ありがとうございます！
具体的に『〇〇だから〇〇が良い』と言ってもらえると納得します！
修正します！

指摘されて書いて見たら案外スッキリして、あ、今までの自分は簡単な方にと怠惰だっただけだったことがわかりました。

from architecture_ios.

uhooi avatar uhooi commented on June 23, 2024

なんか楽しくなってきたので、自分でも手元でリファクタリングしてますー笑
ただ完全に自分の好みで失礼なレベルでガンガン書き換えているので、PR出すか迷います…

from architecture_ios.

sachiko-kame avatar sachiko-kame commented on June 23, 2024

なんか楽しくなってきたので、自分でも手元でリファクタリングしてますー笑

そう言ってもらえると嬉しいです！時間を奪っちゃっているような気がして感謝と一緒に罪悪感もあったので、、

ただ完全に自分の好みで失礼なレベルでガンガン書き換えているので、PR出すか迷います…

意見を聞けるのなら聞きたい願望です。なのでもしよければお願いしたいです！！

from architecture_ios.

uhooi avatar uhooi commented on June 23, 2024

自分が勝手にやってるので罪悪感は持たないでくださいｗ
そしたら完成したら上げますね！

from architecture_ios.

uhooi avatar uhooi commented on June 23, 2024

超ウホーイの好みにリファクタリングしてみました笑https://github.com/uhooi/architecture_iOS/tree/feature/fix_mvp/sample/sample

diffが出過ぎると思うので、Xcodeを2つ起動してソースを見比べるといいかもしれませんｗ
あくまで参考で、間違っていることもあると思うので鵜呑みにしないでください〜

from architecture_ios.

uhooi avatar uhooi commented on June 23, 2024

気になったらここでもTwitterでもどこでもいいので、何でも聞いてください〜✨

from architecture_ios.

uhooi avatar uhooi commented on June 23, 2024

設計強いかはわかりません笑
実はそんなに実務経験がないので、他で通用するのかわかんないんですよね…

from architecture_ios.

uhooi avatar uhooi commented on June 23, 2024

ありがとうございますｗ
簡単な方に逃げる考えは間違っていないと思います！
逃げ方ですよねｗ

from architecture_ios.

uhooi avatar uhooi commented on June 23, 2024

あ、 setRead() は get○○() と同様の理由でよくないです！
read というプロパティにセットするセッターに見えるので、 setupForRead() のようにするといいです！

from architecture_ios.

uhooi avatar uhooi commented on June 23, 2024

あと if isRead == true {} は if isRead {} のように書くのが好みです。
前者は isRead が Bool? 型の場合に使うと、オプショナルかどうかがすぐにわかって可読性が上がります！
（ Bool? 型は if isRead {} と書くとビルドエラーになる）

from architecture_ios.

Related Issues (2)

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.