ひどいアーキテクチャのGitHubで1.2Kスターを獲得しました。 どうやって？

かなり普通の、しかし明らかになる物語を共有したい。 プロジェクトのアイデアは3か月前に登場し、1か月で実装され、今では2か月間、プロジェクトはGitHubのトップに定期的にハングアップし、あらゆる種類の専門ニュースリソースに入り、記事「4月のトップ5ライブラリ」のダイジェストに登りました。



あなたは私が自慢していると思うかもしれませんが、いいえ。 この背景は、より深い不協和音に必要です。 建築について話したいです。 はい、私は知っています、「 可能な限り 」と「 彼が自分自身に許可するもの 」。 しかし、パターンについてではなく、パターンの使用方法についてお話します。 これらは私が探していて愛した記事です。 Swiftの新しいバージョンがリリースされたときのエラーよりも、シングルトンとファクトリーの例が多くあります。また、 ライブラリーを例として使用した一般的なアプローチについて説明します。

ダイビングの前に指示を読んでください。

私は、途方もないレベルのiOの開発者だとは言いませんので、言われたことすべてに批判的になるようお願いします。 私よりも経験豊富な人がいると確信しています。 しかし、失われた魂にとって、昨日配列をソートするためには、客観的であることは良いことです。 やってみます。

ハッチをいじめ！ 没入！

このプロジェクトは、権限を使用して作業を簡素化します。 さらに、同じ通知を受信するために変換が増加します。 美しいダイアログボックスが嫌いな人は誰ですか？）



プロジェクトの基本要件：

• 簡単な実装
• 簡単な使用
• 便利なカスタマイズと拡張（突然新しいアクセス許可またはビジュアルを追加する場合）

残りはうまくやろうとしました（たとえば、ビジネスロジックを変更する機能は優先事項ではありませんでしたが、考慮されました）



それでは話しましょう。 これは一般的に便利なことです。 プロジェクトをシンプルにするためには、シンプルなインターフェースを持ち、プログラマーに内部の実装をロードしないようにする必要があります。 この点で、私はAppodealからのアプローチに触発されました。 一般に、エントリポイントは1つ必要です。 つまり オブジェクトに2つの権限を設定し、要求しました。 簡単に聞こえるはずです！



すぐに左の悪魔？ 肩にささやく：「シングルトン...」。 そして、最初の日は素晴らしいソリューションに思えたので、AppDelegateで構成し、コントローラーを必要な場所に表示しました。



しかし、さらに問題がありました：

• ダイアログボックスを念頭に置くことは非常にまれです
• すべての許可を取得した後、あなたは間違いなくそれをあなたの記憶に保持する必要はありません
• 異なる画面で同じ権限を要求する必要はほとんどありません

一般に、パターンにはプラスよりもマイナスが多くありました。 ここでは、プロジェクトを使用するためのオプションに基づいているという事実に注意を喚起したいと思います。 Singletonの使用は正当であると確信していますが、他の状況でもそうです。



ターニングポイントで、私の見解は、既知のAndroid開発者Aleksey Skutarenkoによって確認されました。彼はこのパターンを「疑わしい」と呼びました。 このパターンが嫌いなのか、それとも私のニーズに最適に適用できないのかは不明です。 しかし、20枚の古紙を捨てて新しいものを手に入れるという決断が下されました。 実際、マーカーも終了しました。



それから反対から行くことにした。 プロジェクトの使用方法を教えてください。 私はこれを明確に表しています：

class ViewController: UIViewController { var permissionAssistant = SPRequestPermissionAssistant.modules.dialog.interactive.create(with: [.Camera, .PhotoLibrary, .Notification]) override func viewDidAppear(_ animated: Bool) { super.viewDidAppear(true) self.permissionAssistant.present(on: self) } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ソリューションは自然に生まれました。メインクラスが必要であり、PermissionAssistantと呼びます。 そして、ロジックをキーブロックに分割し、便宜上、それらをワードマネージャーと組み合わせます。 そして、それは論理的に、異なるタスク-したがって、異なるクラスがそれらを担当します。





それでは、機能部分を決定しましょう。 明らかに、それらの1つが許可の要求とそれらに関する情報の取得を担当します。 PermissionsManagerと呼びます。 視覚的な部分も含まれているため、PresenterManagerを追加します（Viperの命名規則を所有します。発見者で十分な場合があります）。





プレゼンターは、コントローラーのプレゼンテーション、その構成、一般的にUIの責任を負います（もちろん、そうする場合）。 ところで、将来の柔軟性を高めるために、すべての部分がプロトコルによって隠されているという事実に注目します。



柔軟性？！



はい たぶん最高の言葉ではありませんが、本質を反映しています。 潜水艦を修理していると想像してください。ネジマウントは29インチの16シートスレッド（発明されたばかり）です。 毎回新しい潜水艦を作成する必要はありません。既知の要件を持つネジを作成して固定すれば十分です。 作り、留めます。



私はall話の達人ではありません。たとえばコードを見てみましょう。 PermissionsManagerを調べて、プロトコルと実装によって隠されています。 最初に、マネージャーの機能を定義します。 2つの方法で十分です。

• 許可のリクエスト
• 許可が承認されています

機能を好みに合わせて拡張できますが、それで十分です。 そして、プロトコル：

 protocol PermissionManagerInterface { func requestPermission(_ type: PermissionType) func isAllowedPermission(_ type: PermissionType) }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

私たちの場合、これらはボートのプロペラの要件です。



次に、プロトコルを実装します。 実際のオブジェクト（ネジ）を取得します。 固定します。 しかし、メインクラスのアシスタント（潜水艦）は、どの特定の実装（どの金属から、何日注入され、どのくらいの作業コストがかかるか）を知りません。 メインクラスは、2つの関数しかないことを知っています。 実装を変更したい場合-ください）ビジュアルパーツとDataSourceのカスタマイズに特に役立ちます。 今から彼について話します。



明らかに、視覚的な部分は単なるプレゼンターよりもはるかに複雑です。 良いことには、モジュールに分割する必要があります。 実際には、コントローラーとデータソースの2つの部分に分けます。



プレゼンターはコントローラーを保持し、ジェスチャー、画面、およびコントローラーが行うその他のことを処理します。 もちろん、問題はコントローラーがアクションをどのように報告するかです。 特に好奇心ones盛な人は、「ARCは1時間ですべてを地獄に破壊することはないだろうか？」という疑問を抱くでしょう。



最初の質問-デリゲートですべてが明確な場合、2番目は1週間私の仕事を止めた問題です。 しかし、理解するために、オブジェクト間のリンクでスキームを補足しました（強いリンクと弱いリンクについて誰もが知っていることを望みます。質問はありません）。



問題は明らかです（願っています）-コントローラーはAssistantオブジェクト（もちろん、プレゼンターですが、アシスタントを保持しているので、リンクをドロップします）のみを保持します。 問題がまだ明確でない場合、私は説明します：



Assistantオブジェクトがスコープ外に出て、それに応じてARCの外側に投げられたと想像してください。 コントローラが提示されなかった場合、オブジェクト全体が死にます。 これは正しい動作です。 しかし、コントローラーが提示された場合...



その後、スタックの重量を測定します。したがって、オブジェクトの外部にリンクがあります。 しかし、アシスタントが視線を離れると、死んでしまいます。 簡単な例でデモンストレーションできます。

 if true { let permissionAssistant = SPRequestPermissionAssistant.modules.dialog.interactive.create(with: [.Camera, .PhotoLibrary, .Notification]) permissionAssistant.present(on: self) }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

コントローラーは生きているが、すべての環境クラスが死ぬ状況になります。 そして、司会者を務めたプレゼンターでさえ。

悲しい

-私は考えて、たくさんのパターンを深く掘り下げ、パターンについて読んで（おそらく私はいくつかを見逃した）、一般的にこの世界から落ちました。 水泳に没頭。



問題に関する会話が何回あったか、彼は船員を従業員の耳にさえ上げました。 すべてが満場一致で繰り返されました-「 なんてひどい建築でしょうか！ 」、「 著者へ-毒 」、「 コントローラーはすべてを保持する必要があります 」。 はい、コントローラーを中央に配置します。 しかし、問題は、コントローラーがアシスタントを保持しており、初期化中にすぐに表示されなかった場合、オブジェクト全体が死ぬことです。 一般に、接続を切り替えることができなかったため、...



コントローラーをメインオブジェクトとして作成してください！ コントローラー内でロジックを作成するには-まあ、いいえ。



決定はそれ自体でお茶を飲みながら行われ、少し洞察力がありました：

「どうして？」

アシスタントをコントローラーコントローラーとして初期化するだけです-以上です！ 親が生きている間、アシスタントも生きています。 また、すべての対話コントローラーはモーダルであるため、ソリューションは完全に機能しました。 この決定は私にとって最適であるように見えましたが、内部のペダントリーは悲しいものでした。 さあ、続けましょう。 精神が向上し、再びスピードが上がりました！



ここで、UIとPermissionManagerを分離するとよいでしょう。 ここではすべてが簡単です。次のようなPermissionInterfaceプロトコルを作成します。

 protocol PermissionInterface { func isAuthorized() -> Bool func request(withComlectionHandler complectionHandler: @escaping ()->()?) }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

そして、新しいpermishin（ロケーション、通知、カメラなど）ごとに実装します。 そして、PermissionManagerで必要なPermissionクラスを作成し、必要な機能を引き出します。



スキームを更新します。



今、全体像を見ることができます。 ご覧のとおり、レンガを交換できます。 個人的には大丈夫だと思う。 ブロックが低いほど、書き換える必要が少なくなります。 新しいコントローラーを実装するには、そのインターフェースを実装し、現在のシステムに実装する必要があります（ビジネスはどのように）。 テキストと色を変更したいですか？ DataSourceプロトコルを実装します。 特に、PresenterManagerを複数持つというアイデアが気に入っています。 ここで、ダイアログボックスと別の画面に-上部にポップアップバナーが必要です（開発中）

ポップタイム

星の数はコードの品質と弱い相関関係があることを完全に理解しています。明らかにテキストがそれについてではないことを願っています。



プロジェクトの進行中に、多くのヒントを得て、特定のパターン/アイデアが機能しない理由を（自分自身で）議論するのに多くの時間を費やしました。 そしてそれは良いことです 、私は多くの仕事をしました。



私は自分自身に助言を与える余裕のある開発者とは考えていません。 しかし、少し話をしましょう。プロジェクトについて考え始めたとき、私の親友であるGennady（名前を変更します）は、シングルスクリーンアプリケーションに取り組んでいました。 彼はVIPERでそれをしましたが、なぜそれを使用したのか、そしてなぜそれを使用したのかを本当に理解していませんでした。 私の議論に：



-「 問題を手放しなさい、なぜあなたは超単純なアプリケーションで重いパターンが必要なのか 」



彼は頑固でした。 数ヶ月が経ち、私は小さなプロジェクトを実現し、アパートを掃除し、大きなものを買い、顧客に仕事を引き渡し、春が来ている様子を見ました。 Gennadyはアプリケーションの作成を続けています...



パターンはすべての病気の丸薬ではありません。 プロ意識の指標として、または「 教祖もそうする 」 ために使用しないでください。 MVCから「非エプロフスクMVC」を作成しても、手は乾きません。 これが必要であることに気付いたら、パターンを使用してください。 それらを使用して作業を容易にします。 「 このパターンはクールなプロジェクトで使用されます」という議論は 、目標とはまったく無関係であり、このアプローチがあなたの人生を単純化する可能性は低いでしょう。



私は、パターンを放棄し、コントローラーにすべてを書き、一般的にはVIPERから磁気銃で撃つことを勧めません。 使用しますが、意図的です！ アーキテクチャと実験に特定の要件を設定します-タスクをより良く解決するものを見つけます。 VIPERは完璧であるが、 プレゼンターがあなたにとって不必要に思えるなら、捨ててください。 非古典的ではありますが、最良の結果をもたらすのは、アーキテクチャに関する経験的な作業です。



私のパターンが何と呼ばれているのかわかりません（コンポート？）-しかし、私は彼が彼に割り当てられたタスクをどのように解決するかに満足しました。 そのような結果は、パターンの使用をもたらすはずです。



「 専門家でさえ絵コンテを使用します 」未知の著者。



すべての成功したビルドと正統のCTR！



1年のUPD：

現在、このプロジェクトは 2K個以上の星を収集しており、更新することが決定されました。







新しいデザインを見つけることに関するビデオと、プロジェクトでライブラリを使用する方法に関する小さなチュートリアルを見ることをお勧めします。