「Swift 2の新機能」例付き。 パート2

最初の部分では、Swift 2の新機能の一部のみを検討しました。

• 列挙型 、スコープ（スコープ）、引数構文などの基本的な言語構造
• パターンマッチング
• エラー処理

2番目の部分では、残りについて検討します。

• プロトコル拡張
• 可用性チェック
• Objective-CおよびCとの相互作用

Swift 2の新機能について、 Githubにコードが記載されているサンプルとともに紹介します。

プロトコル拡張

Swift 2でプロトコル拡張が可能になり、プロトコルを実装するクラス、構造、および列挙に新しい関数（実装済み）を追加できるようになりました。



Swift 2より前は、Objective-CとSwift 1.xの両方で、プロトコルにはメソッド宣言のみが含まれていました。 Swift 2のプロトコル拡張により、プロトコルにメソッドの実装を宣言とともに含めることができます。 私たちは、Objective-Cのこの機能を何年も待っていたので、新しい言語で具体化されるのを見るのは素晴らしいことです。



特定のプロトコル（インターフェース）を確認するすべてのタイプにいくつかの機能を追加する必要があることがよくあります。 たとえば、すべてのコレクションは、要素の変換に基づいて新しいコレクションを作成するという概念をサポートします。 古いスタイルのプロトコルでは、2つの方法でこの可能性を実装できます。1）メソッドをプロトコルに配置し、このプロトコルを確認する各タイプがメソッドを実装することを要求するか、2）プロトコルを確認するタイプの値で機能するグローバル関数を作成します。



ほとんどの場合、Cocoa（Objective-C）は最初のソリューションを好みます。



Swift 1.xは2番目のソリューションを使用しました。 CollectionTypeで操作されるmapなどのグローバル関数。 これにより、実装中のコードの優れた分離が提供されましたが、ひどい構文と特定のタイプの実装をオーバーライドすることができませんでした。

let x = filter(map(numbers) { $0 * 3 }) { $0 >= 0 } //-- Swift 1
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

プロトコル拡張により、他の2つよりも大幅に優れた3番目の機会が生まれました。 mapは、 CollectionTypeプロトコルの拡張で実装できます。 CollectionTypeプロトコルをサポートするすべてのタイプは、 マップの実装を完全に無料で自動的に受け取ります 。

 let x = numbers.map { $0 * 3 }.filter { $0 >= 0 } //-- Swift 2
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

例として、Swift 2でCollectionTypeプロトコルの拡張として新しいmyMapメソッドの実装を検討します。







その結果、 配列<T>配列にすぐにmyMapを使用できます





辞書用辞書<キー：値>





セットセット<T>





String.characters文字列用





スライスArraySlice <T>の場合





StrideThrough <T> strikesの場合、直接ではなく、シーケンス（ SequenceTypeプロトコル）をコレクション（ CollectionTypeプロトコル）に変換するmapを介して





プロトコル拡張は、Appleがプロトコル指向プログラミング（POP）であると主張する新しいソフトウェア設計アプローチの中心にあり、従来のオブジェクト指向プログラミング（OOP）および機能プログラミング（FP）要素とともにSwiftに存在します。 「壊れやすい基本クラス」、継承の剛性と脆弱性、 「ダイヤモンドの問題」 、オブジェクトへの参照の暗黙的な分離、「キャスト」ダウンの頻繁な使用の必要性（ダウンキャスト）などのOOP問題を克服する必要があります。 ）オーバーライドされたメソッド内。 また、多くの開発者が言葉でポリモーフィズムを説明するのはどれほど難しいかですが、例で示す方が簡単です。プロトコル指向プログラミングの機能を例で示します。

例1. Fisher-Jensシャッフルアルゴリズム

これらの違いを詳しく見るために、Swift 1.2（OOP）およびSwift 2（POP）のシャッフル関数を使用してコレクション要素を「混合」 するFisher-Jens Shuffle アルゴリズムの実装を例として見てみましょう。 このアルゴリズムは、カードゲームでカードを扱うときによく使用されます。



Swift 1.2では、方法2に従ってコレクションを操作するグローバルシャッフル関数を追加します。つまり、 ジェネリックを持つグローバル関数を使用する場合です。







この機能をさらに詳しく見てみましょう。 var list：Cコレクション自体は、このグローバル関数の入力への引数として使用され、同じタイプCの新しいコレクションが元のリストコレクションの「混合」値とともに返されます。 このグローバル関数は、 MutableCollectionTypeプロトコルをサポートし、整数インデックスを持つすべてのタイプに使用できます。 そのようなコレクションが2つあります： Array <T> arrayおよびArraySlice <T> slice







しかし、このグローバル機能の魅力は何ですか？

 shuffle(strings1) shuffle(numbers1)
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

この関数では、括弧内にコレクション自体を指定する必要がある「ドット」付きの表記を使用できません。 多くのネストされた括弧につながる変換のチェーン全体がある場合、これが非常に不便であり、これらすべてが型メソッドと交互になっている場合、一般的には災害です。 上記で同様の構文をすでに見ました。

 let x = filter(map(numbers) { $0 * 3 }) { $0 >= 0 } //-- Swift 1
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

Swift 1.2で「ポイント」表記を使用する場合は、 配列クラスなどの個々のタイプの拡張にシャッフル関数を追加します（これはメソッド1です）。 そして、その場で変化する（変更する）shuffleInPlaceメソッドと、元の配列の「混合」要素を持つ新しい配列を返す（変更しない）shuffleメソッドの両方を追加できます。







最後の2つのメソッドは、 配列配列の拡張であり、配列でのみ使用できます。





SetもArraySliceも、その他のCollectionTypeもこれらを使用できません。



Swift 2では、 shuffleおよびshuffleInPlaceメソッドを追加して、 CollectionTypeおよびMutableCollectionTypeプロトコルを拡張します （メソッド3）。





プロトコルの拡張により、 shuffleおよびshuffleInPlaceメソッドをSet 、 Array 、 ArraySliceおよびその他のCollectionTypeに、追加の労力なしで、必要な「ポイント」表記で適用できるようになりました。







Swift 2でプロトコルを拡張する場合、型の制限を設定できます。 コードからわかるように、最初にインデックスとして整数を使用する可変コレクションMutableCollectionTypeに対してのみプロトコル拡張を実行し、次にそれをCollectionTypeに拡張します 。



最後に、コレクションの要素を「混合」するアルゴリズムに関して、少し発言する必要があります。 Swift 2には、既にGameplayKitで Fisher-Jensシャッフルアルゴリズムの効果的で正しい実装があります（名前にかかわらず、ゲームだけでなく適切です）。 確かに、このメソッドは配列でのみ機能します。

例2.さようならパイプ（パイプライン）演算子|>プロトコル拡張の出現

Swiftの到来と、関数型プログラミング演算子を含むカスタム演算子の作成の可能性により、関数型プログラミング手法を使用していくつかの問題を解決する試みが行われ、非常に成功しています。 特に、プラスチックカードのチェックディジットを計算するためのLunaアルゴリズムでは、パイプ（パイプライン）演算子を使用して、関数とメソッド間での迷惑なスローを回避することが提案されました。 しかし、Swift 2が登場し、プロトコル拡張技術によりこのタスクがさらに簡単になりました。



開発者が説明した元のアルゴリズム

• 1.チェックされるシーケンスの番号には、右から左に番号が付けられます。
• 2.奇数の場所にある番号は変更されません。
• 3.偶数の場所の数値に2を掛けます。
• 4.そのような乗算の結果として9より大きい数が表示される場合（たとえば、8×2 = 16）、結果の積の桁の合計に置き換えられます（たとえば、16：1 + 6 = 7、18：1 + 8 = 9）-1桁の数、つまり、数字。
• 5.変換の結果得られたすべての数値が合計されます。 合計が10の倍数である場合、初期データは正しいです。

アルゴリズムは一連のステップで構成されます。各ステップは、プロトコルまたはタイプの拡張機能を使用するか、既知の方法を使用して説明します。



まず、Swift 2ではStringはもはやシーケンスではなく、 String.charactersは文字のシーケンスであり、文字を整数に変換する必要があることを思い出してください。 Int型の拡張でこの変換を構築します。 つまり、 String.toIntegerの代わりに、 Int.init（String）を取得します。







クレジットカード番号にスペースが含まれている可能性があるため、この変換はOptionalを返し、受信した整数に対して引き続き算術演算を実行する必要があるため、Swift 2で登場したflatMapメソッドを使用して、カード番号のすべてのスペースを削除します







私たちのアルゴリズムによれば、数字を右から左に考慮し、それらは左から右に進むので、 reverseメソッドとtrivial mapメソッドを使用して数字のシーケンスを反対方向に並べます







ただし、単純なマップではなく、シーケンスの各N番目のメンバーに対してのみ変換を実行するマップが必要です。 再度、拡張を実行しますが、タイプではなくSequenceTypeを実行します







次の結果が得られます







次に、整数を含むシーケンスの合計を計算できるメソッドが必要です。







および別の数を法とする数を計算する方法







その結果、 luhnchecksum（）メソッドを取得します。このメソッドは、 String型に追加し、1行でチェックサムを計算します







結果を取得するのは非常に簡単です：

プロトコル拡張のいくつかの機能

プロトコル拡張は、オプションのプロトコル方式に関する質問に対するAppleの一種の答えかもしれないと思います。 純粋なSwiftプロトコルには、オプションのメソッドを含めることはできません。 しかし、Objective-Cプロトコルのオプションのメソッドには、たとえばデリゲートのようなものに慣れています。

 @protocol MyClassDelegate @optional - (BOOL)shouldDoThingOne; - (BOOL)shouldDoThingTwo @end
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

Pure Swiftには同等のものはありません：





これまで、このプロトコルを検証した人は全員、これらの方法をすべて実装していたはずです。 これは、オプションですべてのデリゲートメソッドを設定し、デフォルトのメソッド実装を優先する可能性があるというCocoaの委任の考え方と矛盾します。 Swift 2でのプロトコル拡張の出現により、合理的なデフォルトの動作をプロトコル自体で実現できます。







最終的に、これはObjective-Cの@optionalと同じ機能を提供しますが、実行時の必須チェックはありません。

API可用性チェック

iOS開発者を落ち込ませる専門的な問題の1つは、新しいAPIを使用する際に非常に注意する必要があることです。 たとえば、iOS 8でUIStackViewを使用しようとすると、アプリケーションがクラッシュします。 Objective-Cの昔、開発者は次のようなコードを記述していました。

 NSClassFromString(@"UIAlertController") != nil
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

これは「 UIAlertControllerlクラスが存在する場合」を意味し、iOS 8以降で実行されるかどうかを確認する方法です。 しかし、Xcodeはこのコードの真の目的を知らなかったという事実により、その実行の正確性を保証しませんでした。 次のようなコードを明示的に記述できるため、Swift 2ではすべてが変更されました。

 if #available(iOS 9, *) { let stackView = UIStackView() //  ... }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

マジックは#available文で発生します。iOS9以降で実行しているかどうかを自動的にチェックし、実行している場合は、 UIStackViewのコードが起動します。 「iOS 9」の後に記号「*」が存在するということは、この提案がAppleが導入する将来のプラットフォームに対して実行されることを意味します。



#available文はまた 、 elseブロックにコードを書く機会を与えるという点でも注目に値します。これは、デバイスがiOSバージョン8以前である場合にこのブロックが実行され、新しいAPIを使用すると警告できるようになるためです。 。 たとえば、次のようなものを書いた場合：

 if #available(iOS 9, *) { // do cool iOS 9 stuff } else { let stackView = UIStackView() }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

...その後、エラーが発生します：







Xcodeは、利用できないUIStackViewを使用しようとしていることを認識し 、これが発生しないようにします。 したがって、「このクラスが利用可能」からXcodeに真の意図を伝えるために切り替えると、セキュリティに対する多大なサポートが得られました。

互換性

Swift、つまり、メソッド、プロパティなどをObjective-Cなどに公開するかどうか、どのように公開するかをコンパイラに伝える一連の事前定義されたルールを記述するとき さらに、このプロセスを制御できる少数の属性を自由に使用できます。 これらの属性は次のとおりです。

• @IBOutletと@IBActionを使用すると、SwiftのプロパティとメソッドをInterface Builderのアウトレットとアクションとして解釈できます。
• dynamic 、特定のプロパティに対してKVOを使用できます。
• @objcは 、Objective-Cからクラスまたはプロパティを呼び出し可能にするために使用されます。

Swift 2は、Objective-Cでのプロパティまたはメソッドの使用を明示的に防止する@nonobjcなどの新しい属性を導入しました。 この属性は、たとえば次の場合に非常に役立ちます。 Cocoa UIViewControllerクラスを継承するViewControllerクラスのCalculatorアプリケーション（以下を参照）で、 performOperationという同じ名前で異なる引数を持つ3つのメソッドを定義しました。 これは正常であり、Swiftはこれらのメソッドを区別することができ、異なる種類の引数に基づいています。 しかし、Objective-Cはそのようには機能しません。 Objective-Cでは、メソッドは名前ではなくタイプによって異なります。 これらのメソッドがObjective-Cで使用するために公開されている場合、この形式のObjecrive-Cでは使用できないというエラーが表示されます。 問題は、計算機インターフェイス用に作成したViewControllerクラスがUIViewCiontrollerクラスのCocoaクラスを継承し、コンパイラがすべてのプロパティとメソッドを@objc属性で暗黙的に自動的にマークすることです。 Objective-Cでメソッドを使用するつもりがない場合は、それらに@noobjc属性を指定する必要があり、エラーが消えます。





.........................



Swift 2が互換性を改善しようとしているもう1つの分野は、C関数ポインターとの互換性です。 この改善の目的は、厄介なSwiftの制限を修正することです。これにより、コールバック関数を集中的に使用するCore Audioなどの重要なCフレームワークを完全に使用できなくなります。 Swift 1.xでは、C関数へのポインターをSwift関数に直接置き換えることはできませんでした。 CまたはObjective-Cでコールバック関数をカプセル化する小さな「ラッパー」を作成する必要がありました。 Swift 2では、Swift 2でこれを完全に自然な方法で行うことが可能になりました。 C関数へのポインターはクロージャーとしてSwiftにインポートされます。 Swift 2の任意のクロージャーまたは関数を、適切なパラメーターを使用して、C関数へのポインターを予期するコードに渡すことができます。1つの重要な制限があります。クロージャーとは対照的に、C関数へのポインターには、「キャプチャされた」状態の概念がありません（単なるポインターです）。 その結果、C関数へのポインターとの互換性のために、コンパイラは外部コンテキストを「キャプチャ」しないSwift 2クロージャーのみを許可します。 Swift 2は新しい@規約©表記を使用して、呼び出しでこの規約を示します。







たとえば、標準のC qsortソート関数の場合、次のようになります。





非常に良い例がSwiftのC Callbacksにあります。これは、 CGPathApply関数を呼び出して、コールバック関数にポインターを渡すことでCGPathまたはUIBezierPath要素にアクセスする方法を示しています。 次に 、 CGPathApplyは各パス要素に対してこのコールバックを呼び出します。











次に、 パス全体を調べて、その要素の説明を出力します。







または、このパスにある closepathコマンドの数を計算できます 。







結論として、Swift 2は、C関数とクロージャーへのポインターの互換性（ブリッジ）を自動的に保証すると言うことができます。 これにより、コールバックとして関数ポインターを使用する多数のC APIで作業することが可能になります（非常に便利です）。 C関数の呼び出しに関する規則では、これらのクロージャーが外部状態を「キャプチャ」することは許可されないため、多くのC APIがコールバッククロージャーがアクセスする必要がある外部ポインターを外部ポインターに渡す必要があります。

新しいObjective-Cの機能

Appleは、よりスムーズなSwift互換性のためにそれらを使用することを目的として、Xcode 7のObjective-Cに3つの新機能を導入しました。

• ヌル可能性
• 軽量ジェネリック
• __kindof型。

ヌル可能性

この機能はすでにXcode 6.3で導入されましたが、Objective-Cを使用すると、メソッドやプロパティの動作を正確に特性化して、 nilであるかどうかを確認できるようになりました。 これは、 オプションまたは非オプションのタイプに対するSwiftの要件に直接対応し、Objective-Cインターフェイスをより表現力豊かにします。 nullabilityには3つの修飾子があります。

• nullable （Cポインターの__nullable ）。これは、ポインターをnilにして、 オプションの型としてSwiftに変換できることを意味します- ？ ;
• nonnull （Cポインターの場合は__nonnull ）。これは、 nilが許可されておらず、 オプション型ではないSwiftに変換されることを意味します。
• null_unspecified （Cポインターの場合__null_unspecified ）、サポートされている動作に関する情報はありません。 この場合、このようなポインターは自動的に「拡張された」オプションとしてSwiftに変換されます- ！ 。

上記の修飾子は、次の例のように、Objective-Cクラスに注釈を付けるために使用できます。







この例では、角かっこNS_ASSUME_NONNULL_BEGINおよびNS_ASSUME_NONNULL_ENDでマークされた領域全体が選択されているため、 null以外はデフォルト値になります。 これにより、開発者はデフォルト値と一致しない要素のみに注釈を付けることができます。

軽量ジェネリック

Objective-Cの軽量ジェネリックは、特にAppleエンジニアにとっては、過去10年間でObjective-Cで間違いなく最も望ましいものです。 NSArrayやNSDictionaryなどのコレクションで使用するために必要です。Objective -Cのコレクションの欠点の1つは、Swiftに移植するときにほとんどすべての型情報が失われることです。SwiftではデフォルトでAnyObjectコレクションを取得し、ダウンキャストを使用する必要があります「ほとんどの場合。 ただし、Xcode 7でこの方法で配列要素の型を宣言できます。







この場合、可変文字列の配列を宣言します。 数値を書き込もうとすると、コンパイラは型の不一致に関する警告を出します。

NSArrayやNSDictionaryなどのクラスを表現するという点で、Objective-CとSwiftの相互運用性に軽量のジェネリックが非常に役立つことが判明しました。これは、Swiftコードで多くの「キャスト」を行う必要がないためです。すべてのAppleフレームワークはObjective-Cで作成されています。







ほら サブビューは配列[AnyObject]ではなく、 [UIView]としてSwiftに渡されます。

これで、Objective-Cでは、独自のジェネリッククラスを宣言できます。







そしてそれを使用する





タイプが一致しない場合、警告が発行されます。 残念ながら、独自のジェネリック型を使用することは、Objective-Cコード内でのみ利点があり、Swiftでは無視されます。 これらはコンパイラレベルでのみ動作し、ランタイムでは動作しません。

__kindof型

__kindof型はジェネリック型であり、その外観は次の場合に動機付けられています。 ご存じのように、 UIViewクラスには、 サブビュープロパティがあります。これは、 UIViewオブジェクトの配列です。

 @interface UIView @property(nonatomic,readonly,copy) NSArray< UIView *> *subviews; @end
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

バックグラウンドで最もリモートのサブビューとしてUIButtonを親UIViewに追加し、 UIButtonにのみ関係するメッセージを送信しようとすると、コンパイラーは警告を出します。 これは良いことですが、バックグラウンドのサブビューがUIButtonであることを確実に知っており、メッセージを送信する必要があります。

 [view insertSubview:button atIndex:0]; //-- warning: UIView may not respond to setTitle:forState: [view.subviews[0] setTitle:@"Cancel" forState:UIControlStateNormal];
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

__kindof型を使用すると、Objective-Cのタイピングシステムにある程度の柔軟性を提供できるため、スーパークラスとサブクラスの両方の暗黙的な「キャスト」が機能します。

 @interface UIView @property(nonatomic,readonly,copy) NSArray< _kindof UIView *> *subviews; @end //-- no warnings here: [view.subviews[0] setTitle:@"Cancel" forState:UIControlStateNormal]; UIButton *button = view.subviews[0];
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

軽量ジェネリックおよび__kindof型を使用すると、開発者はほとんどのAPIのほぼどこからでもid / AnyObjectを削除できます。 どのタイプを扱っているかについての情報が本当にない場合には、 IDがまだ必要かもしれません：

 @property (nullable, copy) NSDictionary<NSString *, id> *userInfo;
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

使用済み記事へのリンク



Swift 2の新機能

Swift 2の好きなもの

Swift 2の初心者向けガイド

Swift 2.0でのエラー処理

Swift 2.0：やってみましょうか？

ビデオチュートリアル：Swift 2の新機能パート4：パターンマッチング

投げないものを投げる

Swiftの新機能のベスト

Swift 2の新機能

Swift 2.0：可用性チェックAPI

Swiftで配列をシャッフルするにはどうすればよいですか？

Swift 2.0シャッフル/ shuffleInPlace

C Callbacks in Swift,

Protocol extensions and the death of the pipe-forward operator

Swift protocol extension method dispatch

API Availability Checking in Swift 2

Interacting with C APIs

What's new in iOS 9: Swift and Objective-C

Xcode 7 Release Notes