この記事では、原則を非常に鮮明に説明しています。SRP自己非難の単一原則です。SRPは、5つのSOLID設計原則の中で最も誤解されています。多くのプログラマーは、この原則は、各モジュールがSRPという名前に基づいて1つのことだけを実行する必要があることを意味していることを当然のことと考えています。大きな関数を小さな関数に再構築するときにこの原則をよく使用しますが、これはSRP全体ではなく、基礎となる実装の詳細の設計原則にすぎません。
本文：すでにCALayerが存在することを明確に説明していますが、なぜUIViewが必要なのですか？
UIViewはUIResponderを継承しており、その主な機能はタッチイベントに応答できることです。そしてCALayerは実際にはレイヤーコンテンツ管理です。みんな違うことをしている2つのことみんなの存在はお互いに影響を与えないので当然です
しかし、それについて慎重に考えてください、それは本当にBBK読書機ですか、とても簡単ですか？その背後にある意図を注意深く理解すると、OMGが見つかります！！！
UILayer
UIKitがAppleからではなく、私たちからのものである場合、どうなるでしょうか？はい、多分UIViewとCALayerは「UILayer」と呼ばれるものに結合されます。このUILayerはオールラウンドなレイヤーで、表示コンテンツを管理でき、タッチイベントを処理することもできます。
OK！UILayerはずっと前にとても疲れていたと仮定すると、iOS2に存在します。それは本当にスマートで、最初からとても疲れています。
今、あなたの製品マネージャーは笑顔でやって来ます。iOS3.2バージョンでは、ジェスチャ認識を追加する必要があります。これは扱いが簡単で、UILayerを変更してジェスチャ認識を追加するだけです。
あなたのプロダクトマネージャーが再びここに来て、あなたの肩を軽くたたきました。あなたはどれほど信頼していますか？iOS4でブロック構文が導入されたので、前のアニメーションにブロックバージョンを追加します。あなたはそれについて考えます、それは簡単です、UILayerのソースコードを変更するだけです。
あなたのプロダクトマネージャーがまたここにいます、ああ、彼も2人のプロダクトガールを連れてきて、彼らはあなたを囲みました。彼らはすべて会社の有名人です。彼らは一般の人々から信頼されています。彼らは少し恥ずかしがり屋です。
今回は、AutoLayoutという大きな機能をiOS6に追加していただきたいと思います。これは本当に大きな機能です。多くの場所で変更する必要があり、テストにも多くの困難が伴います。UILayerクラスはどんどん大きくなり、関数は3000と同じくらい強力になりました。リリースはできませんこれもまた、このような重要なカテゴリーですが、女の子の愛情深い期待に値するものであるためには、慎重に変更する必要があります。結局、あなたは終わりです。ハハ、あなたは年末で最高の従業員です。
あなたのプロダクトマネージャーが再びここに来ました、よ、首を抱きしめて、冗談を言って、あなたを夕食に招待してください、ああ、製品の女の子はまだ後ろであなたを賞賛しています。はい、もう一度歴史的な瞬間に、iOSは変身の7番目のメジャーバージョンを先導しました。
iOS7は小さくて新鮮になり、物理的な効果が追加され、視差も追加されました。プロダクトマネージャーは、製品のデザインコンセプトを覆し、世界を再び変えようとしています。これは素晴らしいことです。次に、巨大なUILayerクラスをクリックすると、最初から最後まで変更されているように見えますが、多くの変更が必要で、時間が限られており、テストを終了する時間が十分ではないようです。リファクタリングはさらに重要です。それは不可能です。年次リリースを延期することはできません。さもなければ、会社はどのようにして世界の前に顔を向けることができるでしょうか。しかし、時間は誰も待っていません。プログラマーが毎日あなたを励ましても、あなたを救うことはできません。あなたが制御できないコードはもうありません。iOS7の歴史的な節目で、あなたの神話は崩壊しました。
分析
したがって、この自然なSDKの背後には、ダニエルの何十年にもわたる設計の知恵があります。そこにはたくさんの出入り口があるはずです。今回はUIViewとCALayerを分析し、何かを得ることができます。
-
メカニズムと戦略の分離
-
より不変
-
彼らの義務を遂行する
-
漏れが少ない
1.メカニズムと戦略の分離
Unixカーネル設計の主なアイデアの1つは、ポリシー（Policy）ではなく（Mechanism）メカニズムを提供することです。プログラミングの問題は、メカニズムと戦略の部分から抽出できます。メカニズムが実装されると、それが変更されることはめったにありませんが、戦略はしばしば最適化されます。たとえば、原子はメカニズムと見なすことができ、さまざまな原子の構成は戦略です。CALayerは、レイヤーの描画を提供するメカニズムと見なすこともできます。CALayerのヘッダーファイルを開いて表示できます。基本的にはあまり変更されていませんが、UIViewは多くの変更が加えられた戦略と見なすことができます。最下層が多いほど、メカニズムが多くなり、メカニズムが安定します。メカニズムと戦略を分離することで、変更が必要なコード、特に基盤となるコードを少なくすることができ、システムの安定性を向上させることができます。
2.より不変
安定性はどのようにあなたに与えますか？頑丈？変形できませんか？実際、安定性とは不変性を意味します。システムが不変であるほど、システムはより安定します。したがって、メカニズムはこの不変の要素を満たします。システム構築の指針となるイデオロギーは、不変のものを抽出し、可変のものを分離しようとすることです。水は高層ビルを作ることはできず、固いコンクリートだけが作ることができます。変更が少ないということは、バグの可能性が少ないことを意味します。
3.職務を遂行する
どんなに強くても何もできないし、ある日うまくいかないと突然何もできなくなる。したがって、リスク分散の原則に基づいているだけで、万能な人はいないはずです。それぞれがその役割を果たし、互いに協力して制御可能な粒度を最小限に抑え、システムをより安定させ、変更しやすくします。
4.漏れが少ない
インターフェースは一般の人々を対象にする必要があります。82の原則によれば、インターフェースの20％は実際にニーズの80％を満たすことができ、残りの80％は舞台裏に隠す必要があります。漏れが少ないことは常に安全なので、そうではありませんか？エキスパートインターフェイスの残りの80％は、深く隠すことができます。たとえば、UIViewはほとんどのCALayerインターフェイスを覆い隠し、使いやすいフレームとアニメーションの実装を抽出して構築します。これにより、開始が容易になります。
総括する
私は以前、自己非難の単一の原則を多かれ少なかれ理解または聞いたことがあります。具体的に記事を読んで情報を聞いて理解しても、実際の開発過程ではこの原則が使えないかもしれません。または、Pythonなどの開発言語に変更しましょう。いくつかのPythonライブラリからこの設計原理を体験できますか？多分それも難しいです。その理由は、私たちには1つのことが欠けているからです。それは考えることです。ツールを使用することはできますが、必ずしもツールを設計する必要はありません。根底にあるメカニズムはコアです！
[The Way of Infinite Testing]パブリックアカウントへようこそ、返信[Receive Resources]
Pythonプログラミング学習リソース乾物、
Python + AppiumフレームワークAPPUI自動化、
Python + Seleniumフレームワーク
WebUI自動化、Python + UnittestフレームワークAPI自動化、
リソースとコードは無料で送信されます〜
記事の下部に公式アカウントのQRコードがあります。WeChatでスキャンしてフォローするだけです。
備考：私の個人公開アカウントが正式に開設され、ビッグデータテスト、機能テスト、テスト開発、APIインターフェイスの自動化、テストの運用と保守、UI自動化テストなどのテストテクノロジーの共有に専念しています。WeChat検索パブリックアカウント：「WuliangThe Way of Testing」、または以下のQRコードをスキャンしてください。
注意を向けて、一緒に成長しましょう！