![]() | ![]() | ![]() |
این آموزش به برنامهنویسی پروتکلمحور و مثالهای مختلف از نحوه استفاده از آنها با ژنریکها در مثالهای روزمره میپردازد.
پروتکل ها
وراثت یک راه قدرتمند برای سازماندهی کد در زبان های برنامه نویسی است که به شما امکان می دهد کد را بین چندین مؤلفه برنامه به اشتراک بگذارید.
در سوئیفت روش های مختلفی برای بیان وراثت وجود دارد. ممکن است قبلاً با یکی از آن راهها از زبانهای دیگر آشنا باشید: وراثت کلاس. با این حال، سوئیفت راه دیگری نیز دارد: پروتکل ها.
در این آموزش، پروتکلها را بررسی میکنیم - جایگزینی برای طبقهبندی فرعی که به شما امکان میدهد از طریق معاوضههای مختلف به اهداف مشابه برسید. در سوئیفت، پروتکل ها حاوی چندین عضو انتزاعی هستند. کلاسها، ساختارها و فهرستها میتوانند با چندین پروتکل مطابقت داشته باشند و رابطه انطباق را میتوان به صورت ماسبق برقرار کرد. همه اینها برخی از طرحها را قادر میسازد که به راحتی در سوئیفت با استفاده از طبقهبندی فرعی قابل بیان نیستند. ما از طریق اصطلاحاتی که از استفاده از پروتکل ها (افزونه ها و محدودیت های پروتکل) و همچنین محدودیت های پروتکل ها پشتیبانی می کنند، صحبت خواهیم کرد.
انواع ارزش Swift 💖!
سوئیفت علاوه بر کلاس هایی که معنایی مرجع دارند، از enum ها و ساختارهایی پشتیبانی می کند که با مقدار ارسال می شوند. Enum ها و ساختارها از بسیاری از ویژگی های ارائه شده توسط کلاس ها پشتیبانی می کنند. بیایید نگاهی بیندازیم!
ابتدا، بیایید ببینیم که چگونه enum ها به کلاس ها شبیه هستند:
enum Color: String {
case red = "red"
case green = "green"
case blue = "blue"
// A computed property. Note that enums cannot contain stored properties.
var hint: String {
switch self {
case .red:
return "Roses are this color."
case .green:
return "Grass is this color."
case .blue:
return "The ocean is this color."
}
}
// An initializer like for classes.
init?(color: String) {
switch color {
case "red":
self = .red
case "green":
self = .green
case "blue":
self = .blue
default:
return nil
}
}
}
// Can extend the enum as well!
extension Color {
// A function.
func hintFunc() -> String {
return self.hint
}
}
let c = Color.red
print("Give me a hint for c: \(c.hintFunc())")
let invalidColor = Color(color: "orange")
print("is invalidColor nil: \(invalidColor == nil)")
Give me a hint for c: Roses are this color. is invalidColor nil: true
حالا بیایید به ساختارها نگاه کنیم. توجه داشته باشید که ما نمی توانیم ساختارها را به ارث ببریم، اما در عوض می توانیم از پروتکل ها استفاده کنیم:
struct FastCar {
// Can have variables and constants as stored properties.
var color: Color
let horsePower: Int
// Can have computed properties.
var watts: Float {
return Float(horsePower) * 745.7
}
// Can have lazy variables like in classes!
lazy var titleCaseColorString: String = {
let colorString = color.rawValue
return colorString.prefix(1).uppercased() +
colorString.lowercased().dropFirst()
}()
// A function.
func description() -> String {
return "This is a \(color) car with \(horsePower) horse power!"
}
// Can create a variety of initializers.
init(color: Color, horsePower: Int) {
self.color = color
self.horsePower = horsePower
}
// Can define extra initializers other than the default one.
init?(color: String, horsePower: Int) {
guard let enumColor = Color(color: color) else {
return nil
}
self.color = enumColor
self.horsePower = horsePower
}
}
var car = FastCar(color: .red, horsePower: 250)
print(car.description())
print("Horse power in watts: \(car.watts)")
print(car.titleCaseColorString)
This is a red car with 250 horse power! Horse power in watts: 186425.0 Red
در نهایت، بیایید ببینیم که چگونه آنها بر خلاف کلاس ها توسط انواع مقادیر عبور می کنند:
// Notice we have no problem modifying a constant class with
// variable properties.
class A {
var a = "a"
}
func foo(_ a: A) {
a.a = "foo"
}
let a = A()
print(a.a)
foo(a)
print(a.a)
/*
Uncomment the following code to see how an error is thrown.
Structs are implicitly passed by value, so we cannot modify it.
> "error: cannot assign to property: 'car' is a 'let' constant"
*/
// func modify(car: FastCar, toColor color: Color) -> Void {
// car.color = color
// }
// car = FastCar(color: .red, horsePower: 250)
// print(car.description())
// modify(car: &car, toColor: .blue)
// print(car.description())
a foo
بیایید از پروتکل ها استفاده کنیم
بیایید با ایجاد پروتکل هایی برای خودروهای مختلف شروع کنیم:
protocol Car {
var color: Color { get set }
var price: Int { get }
func turnOn()
mutating func drive()
}
protocol Electric {
mutating func recharge()
// percentage of the battery level, 0-100%.
var batteryLevel: Int { get set }
}
protocol Gas {
mutating func refill()
// # of liters the car is holding, varies b/w models.
var gasLevelLiters: Int { get set }
}
در دنیای شی گرا (بدون وراثت چندگانه)، ممکن است کلاس های انتزاعی Electric
و Gas
ساخته باشید، سپس از وراثت کلاس استفاده کرده باشید تا هر دو را از Car
به ارث ببرند، و سپس یک مدل ماشین خاص را یک کلاس پایه داشته باشید. با این حال، در اینجا هر دو پروتکل کاملا مجزا با جفت صفر هستند! این باعث می شود کل سیستم در نحوه طراحی آن انعطاف پذیرتر شود.
بیایید تسلا را تعریف کنیم:
struct TeslaModelS: Car, Electric {
var color: Color // Needs to be a var since `Car` has a getter and setter.
let price: Int
var batteryLevel: Int
func turnOn() {
print("Starting all systems!")
}
mutating func drive() {
print("Self driving engaged!")
batteryLevel -= 8
}
mutating func recharge() {
print("Recharging the battery...")
batteryLevel = 100
}
}
var tesla = TeslaModelS(color: .red, price: 110000, batteryLevel: 100)
این یک ساختار جدید TeslaModelS
را مشخص می کند که با هر دو پروتکل Car
و Electric
مطابقت دارد.
حال بیایید خودروی گازسوز را تعریف کنیم:
struct Mustang: Car, Gas{
var color: Color
let price: Int
var gasLevelLiters: Int
func turnOn() {
print("Starting all systems!")
}
mutating func drive() {
print("Time to drive!")
gasLevelLiters -= 1
}
mutating func refill() {
print("Filling the tank...")
gasLevelLiters = 25
}
}
var mustang = Mustang(color: .red, price: 30000, gasLevelLiters: 25)
پروتکل ها را با رفتارهای پیش فرض گسترش دهید
چیزی که می توانید از نمونه ها متوجه شوید این است که ما مقداری افزونگی داریم. هر بار که ما یک ماشین الکتریکی را شارژ می کنیم، باید سطح درصد باتری را روی 100 تنظیم کنیم. از آنجایی که تمام ماشین های الکتریکی حداکثر ظرفیت 100٪ دارند، اما ماشین های گازسوز بین ظرفیت مخزن بنزین متفاوت است، می توانیم به طور پیش فرض سطح را برای ماشین های الکتریکی روی 100 قرار دهیم. .
اینجاست که برنامههای افزودنی در سوئیفت میتوانند مفید باشند:
extension Electric {
mutating func recharge() {
print("Recharging the battery...")
batteryLevel = 100
}
}
بنابراین در حال حاضر، هر ماشین الکتریکی جدیدی که بسازیم، وقتی آن را شارژ می کنیم، باتری را روی 100 تنظیم می کند. بنابراین، ما به تازگی توانسته ایم کلاس ها، ساختارها و فهرست ها را با رفتار منحصر به فرد و پیش فرض تزئین کنیم.
با تشکر از Ray Wenderlich برای کمیک!
با این حال، یکی از مواردی که باید مراقب آن بود، موارد زیر است. در اولین پیادهسازی خود، foo()
به عنوان یک پیادهسازی پیشفرض در A
تعریف میکنیم، اما آن را در پروتکل مورد نیاز نمیدانیم. بنابراین وقتی a.foo()
را فراخوانی می کنیم، " A default
" چاپ می شود.
protocol Default {}
extension Default {
func foo() { print("A default")}
}
struct DefaultStruct: Default {
func foo() {
print("Inst")
}
}
let a: Default = DefaultStruct()
a.foo()
A default
با این حال، اگر foo()
در A
مورد نیاز کنیم، " Inst
" را دریافت می کنیم:
protocol Default {
func foo()
}
extension Default {
func foo() {
print("A default")
}
}
struct DefaultStruct: Default {
func foo() {
print("Inst")
}
}
let a: Default = DefaultStruct()
a.foo()
Inst
این به دلیل تفاوت بین ارسال استاتیک در مثال اول و ارسال استاتیک در پروتکل های دوم در سوئیفت رخ می دهد. برای اطلاعات بیشتر به این پست مدیوم مراجعه کنید.
نادیده گرفتن رفتار پیش فرض
با این حال، اگر بخواهیم، همچنان میتوانیم رفتار پیشفرض را لغو کنیم. نکته مهمی که باید به آن توجه کنید این است که این از ارسال پویا پشتیبانی نمی کند .
فرض کنید ما یک نسخه قدیمی از یک ماشین الکتریکی داریم، بنابراین سلامت باتری به 90٪ کاهش یافته است:
struct OldElectric: Car, Electric {
var color: Color // Needs to be a var since `Car` has a getter and setter.
let price: Int
var batteryLevel: Int
func turnOn() {
print("Starting all systems!")
}
mutating func drive() {
print("Self driving engaged!")
batteryLevel -= 8
}
mutating func reCharge() {
print("Recharging the battery...")
batteryLevel = 90
}
}
استفاده های استاندارد کتابخانه ای از پروتکل ها
اکنون که ایده ای داریم که پروتکل ها در سوئیفت چگونه کار می کنند، اجازه دهید چند نمونه معمولی از استفاده از پروتکل های استاندارد کتابخانه را مرور کنیم.
گسترش کتابخانه استاندارد
بیایید ببینیم چگونه میتوانیم قابلیتهای اضافی را به انواعی که از قبل در سوئیفت وجود دارند اضافه کنیم. از آنجایی که انواع در سوئیفت داخلی نیستند، اما به عنوان ساختار بخشی از کتابخانه استاندارد هستند، انجام این کار آسان است.
بیایید سعی کنیم جستجوی باینری را روی آرایه ای از عناصر انجام دهیم، در حالی که مطمئن شویم که آرایه مرتب شده است:
extension Collection where Element: Comparable {
// Verify that a `Collection` is sorted.
func isSorted(_ order: (Element, Element) -> Bool) -> Bool {
var i = index(startIndex, offsetBy: 1)
while i < endIndex {
// The longer way of calling a binary function like `<(_:_:)`,
// `<=(_:_:)`, `==(_:_:)`, etc.
guard order(self[index(i, offsetBy: -1)], self[i]) else {
return false
}
i = index(after: i)
}
return true
}
// Perform binary search on a `Collection`, verifying it is sorted.
func binarySearch(_ element: Element) -> Index? {
guard self.isSorted(<=) else {
return nil
}
var low = startIndex
var high = endIndex
while low <= high {
let mid = index(low, offsetBy: distance(from: low, to: high)/2)
if self[mid] == element {
return mid
} else if self[mid] < element {
low = index(after: mid)
} else {
high = index(mid, offsetBy: -1)
}
}
return nil
}
}
print([2, 2, 5, 7, 11, 13, 17].binarySearch(5)!)
print(["a", "b", "c", "d"].binarySearch("b")!)
print([1.1, 2.2, 3.3, 4.4, 5.5].binarySearch(3.3)!)
2 1 2
ما این کار را با گسترش پروتکل Collection
انجام می دهیم که تعریف می کند "توالی که عناصر آن را می توان چندین بار، به صورت غیرمخرب، عبور داد و توسط یک زیرنویس نمایه شده به آن دسترسی داشت." از آنجایی که آرایهها را میتوان با استفاده از علامت کروشه مربع ایندکس کرد، این پروتکلی است که میخواهیم گسترش دهیم.
به طور مشابه، ما فقط می خواهیم این تابع کاربردی را به آرایه هایی اضافه کنیم که عناصر آنها قابل مقایسه هستند. به همین دلیل است که where Element: Comparable
داریم.
بند where
بخشی از سیستم نوع سوئیفت است که به زودی آن را پوشش خواهیم داد، اما به طور خلاصه به ما اجازه می دهد الزامات اضافی را به پسوندی که می نویسیم اضافه کنیم، مانند الزام نوع برای پیاده سازی یک پروتکل، نیاز به دو نوع برای اینکه یکسان، یا نیاز به یک کلاس برای داشتن یک سوپرکلاس خاص.
Element
نوع مرتبط عناصر در یک نوع مطابق با Collection
است. Element
در پروتکل Sequence
تعریف شده است، اما از آنجایی که Collection
از Sequence
ارث می برد، نوع Element
مرتبط را به ارث می برد.
Comparable
پروتکلی است که "نوعی را تعریف می کند که می توان با استفاده از عملگرهای رابطه ای <
, <=
, >=
و >
مقایسه کرد." . از آنجایی که ما در حال انجام جستجوی باینری در یک Collection
مرتب شده هستیم، این البته باید درست باشد یا در غیر این صورت نمی دانیم که آیا در جستجوی باینری به چپ یا راست تکرار کنیم.
به عنوان یک یادداشت جانبی در مورد پیاده سازی، برای اطلاعات بیشتر در مورد index(_:offsetBy:)
استفاده شده، به مستندات زیر مراجعه کنید.
ژنریک + پروتکل ها = 💥
ژنریک ها و پروتکل ها می توانند ابزار قدرتمندی باشند اگر به درستی برای جلوگیری از کد تکراری استفاده شوند.
ابتدا، به آموزش دیگری نگاه کنید، A Swift Tour ، که به طور خلاصه در انتهای کتاب Colab به کلیات میپردازد.
با فرض اینکه شما یک ایده کلی در مورد ژنریک ها دارید، بیایید به سرعت به برخی از کاربردهای پیشرفته نگاهی بیندازیم.
هنگامی که یک نوع دارای الزامات متعددی مانند یک نوع مطابق با چندین پروتکل است، چندین گزینه در اختیار دارید:
typealias ComparableReal = Comparable & FloatingPoint
func foo1<T: ComparableReal>(a: T, b: T) -> Bool {
return a > b
}
func foo2<T: Comparable & FloatingPoint>(a: T, b: T) -> Bool {
return a > b
}
func foo3<T>(a: T, b: T) -> Bool where T: ComparableReal {
return a > b
}
func foo4<T>(a: T, b: T) -> Bool where T: Comparable & FloatingPoint {
return a > b
}
func foo5<T: FloatingPoint>(a: T, b: T) -> Bool where T: Comparable {
return a > b
}
print(foo1(a: 1, b: 2))
print(foo2(a: 1, b: 2))
print(foo3(a: 1, b: 2))
print(foo4(a: 1, b: 2))
print(foo5(a: 1, b: 2))
false false false false false
به استفاده از typealias
در بالا توجه کنید. این یک نام مستعار از نوع موجود به برنامه شما اضافه می کند. پس از اعلام یک نوع مستعار، نام مستعار را می توان به جای نوع موجود در همه جای برنامه شما استفاده کرد. نام مستعار نوع، انواع جدیدی ایجاد نمی کند. آنها به سادگی اجازه می دهند یک نام به یک نوع موجود اشاره کند.
حال، بیایید ببینیم چگونه می توانیم از پروتکل ها و ژنریک ها با هم استفاده کنیم.
بیایید تصور کنیم که ما یک فروشگاه رایانه هستیم که برای تعیین نحوه سازماندهی آنها در پشت فروشگاه، روی هر لپ تاپی که می فروشیم، شرایط زیر را دارد:
enum Box {
case small
case medium
case large
}
enum Mass {
case light
case medium
case heavy
}
// Note: `CustomStringConvertible` protocol lets us pretty-print a `Laptop`.
struct Laptop: CustomStringConvertible {
var name: String
var box: Box
var mass: Mass
var description: String {
return "(\(self.name) \(self.box) \(self.mass))"
}
}
با این حال، ما یک نیاز جدید برای گروه بندی Laptop
خود بر اساس جرم داریم زیرا قفسه ها دارای محدودیت وزنی هستند.
func filtering(_ laptops: [Laptop], by mass: Mass) -> [Laptop] {
return laptops.filter { $0.mass == mass }
}
let laptops: [Laptop] = [
Laptop(name: "a", box: .small, mass: .light),
Laptop(name: "b", box: .large, mass: .medium),
Laptop(name: "c", box: .medium, mass: .heavy),
Laptop(name: "d", box: .large, mass: .light)
]
let filteredLaptops = filtering(laptops, by: .light)
print(filteredLaptops)
[(a small light), (d large light)]
با این حال، اگر بخواهیم با چیزی غیر از Mass
فیلتر کنیم، چه؟
یکی از گزینه ها این است که موارد زیر را انجام دهید:
// Define a protocol which will act as our comparator.
protocol DeviceFilterPredicate {
associatedtype Device
func shouldKeep(_ item: Device) -> Bool
}
// Define the structs we will use for passing into our filtering function.
struct BoxFilter: DeviceFilterPredicate {
typealias Device = Laptop
var box: Box
func shouldKeep(_ item: Laptop) -> Bool {
return item.box == box
}
}
struct MassFilter: DeviceFilterPredicate {
typealias Device = Laptop
var mass: Mass
func shouldKeep(_ item: Laptop) -> Bool {
return item.mass == mass
}
}
// Make sure our filter conforms to `DeviceFilterPredicate` and that we are
// filtering `Laptop`s.
func filtering<F: DeviceFilterPredicate>(
_ laptops: [Laptop],
by filter: F
) -> [Laptop] where Laptop == F.Device {
return laptops.filter { filter.shouldKeep($0) }
}
// Let's test the function out!
print(filtering(laptops, by: BoxFilter(box: .large)))
print(filtering(laptops, by: MassFilter(mass: .heavy)))
[(b large medium), (d large light)] [(c medium heavy)]
عالی! اکنون می توانیم بر اساس هر محدودیت لپ تاپ فیلتر کنیم. با این حال، ما فقط می توانیم Laptop
ها را فیلتر کنیم.
در مورد توانایی فیلتر کردن هر چیزی که در یک جعبه است و جرم دارد چطور؟ شاید این انبار لپ تاپ برای سرورهایی که پایگاه مشتری متفاوتی دارند نیز استفاده شود:
// Define 2 new protocols so we can filter anything in a box and which has mass.
protocol Weighable {
var mass: Mass { get }
}
protocol Boxed {
var box: Box { get }
}
// Define the new Laptop and Server struct which have mass and a box.
struct Laptop: CustomStringConvertible, Boxed, Weighable {
var name: String
var box: Box
var mass: Mass
var description: String {
return "(\(self.name) \(self.box) \(self.mass))"
}
}
struct Server: CustomStringConvertible, Boxed, Weighable {
var isWorking: Bool
var name: String
let box: Box
let mass: Mass
var description: String {
if isWorking {
return "(working \(self.name) \(self.box) \(self.mass))"
} else {
return "(notWorking \(self.name) \(self.box) \(self.mass))"
}
}
}
// Define the structs we will use for passing into our filtering function.
struct BoxFilter<T: Boxed>: DeviceFilterPredicate {
var box: Box
func shouldKeep(_ item: T) -> Bool {
return item.box == box
}
}
struct MassFilter<T: Weighable>: DeviceFilterPredicate {
var mass: Mass
func shouldKeep(_ item: T) -> Bool {
return item.mass == mass
}
}
// Define the new filter function.
func filtering<F: DeviceFilterPredicate, T>(
_ elements: [T],
by filter: F
) -> [T] where T == F.Device {
return elements.filter { filter.shouldKeep($0) }
}
// Let's test the function out!
let servers = [
Server(isWorking: true, name: "serverA", box: .small, mass: .heavy),
Server(isWorking: false, name: "serverB", box: .medium, mass: .medium),
Server(isWorking: true, name: "serverC", box: .large, mass: .light),
Server(isWorking: false, name: "serverD", box: .medium, mass: .light),
Server(isWorking: true, name: "serverE", box: .small, mass: .heavy)
]
let products = [
Laptop(name: "a", box: .small, mass: .light),
Laptop(name: "b", box: .large, mass: .medium),
Laptop(name: "c", box: .medium, mass: .heavy),
Laptop(name: "d", box: .large, mass: .light)
]
print(filtering(servers, by: BoxFilter(box: .small)))
print(filtering(servers, by: MassFilter(mass: .medium)))
print(filtering(products, by: BoxFilter(box: .small)))
print(filtering(products, by: MassFilter(mass: .medium)))
[(working serverA small heavy), (working serverE small heavy)] [(notWorking serverB medium medium)] [(a small light)] [(b large medium)]
ما اکنون میتوانیم یک آرایه را نه تنها با هر خاصیت یک struct
خاص فیلتر کنیم، بلکه میتوانیم هر ساختاری را که آن ویژگی را دارد فیلتر کنیم!
نکاتی برای طراحی خوب API
این بخش از بحث WWDC 2019: Modern Swift API Design گرفته شده است.
اکنون که فهمیدید پروتکل ها چگونه رفتار می کنند، بهتر است به این موضوع بپردازید که چه زمانی باید از پروتکل ها استفاده کنید. همانطور که پروتکل ها می توانند قدرتمند باشند، همیشه بهترین ایده نیست که وارد آن شوید و بلافاصله با پروتکل ها شروع کنید.
- با موارد استفاده بتن شروع کنید:
- ابتدا مورد استفاده را با انواع بتن کاوش کنید و درک کنید که چه کدی را می خواهید به اشتراک بگذارید و پیدا کنید که در حال تکرار است. سپس، کد مشترک را با ژنریک فاکتور کنید. ممکن است به معنای ایجاد پروتکل های جدید باشد. نیاز به کد عمومی را کشف کنید.
- ایجاد پروتکل های جدید از پروتکل های موجود تعریف شده در کتابخانه استاندارد را در نظر بگیرید. برای مثال خوبی در این زمینه به مستندات اپل زیر مراجعه کنید.
- به جای یک پروتکل عمومی، به جای آن یک نوع عمومی را تعریف کنید.
مثال: تعریف یک نوع برداری سفارشی
فرض کنید میخواهیم یک پروتکل GeometricVector
بر روی اعداد ممیز شناور تعریف کنیم تا در برخی از برنامههای هندسه که در حال ساخت آن هستیم استفاده کنیم که 3 عملیات برداری مهم را تعریف میکند:
protocol GeometricVector {
associatedtype Scalar: FloatingPoint
static func dot(_ a: Self, _ b: Self) -> Scalar
var length: Scalar { get }
func distance(to other: Self) -> Scalar
}
فرض کنید میخواهیم ابعاد وکتور را ذخیره کنیم، که پروتکل SIMD
میتواند به ما کمک کند، بنابراین نوع جدید خود را اصلاح میکنیم که پروتکل SIMD
را اصلاح کنیم. بردارهای SIMD
را می توان به عنوان بردارهایی با اندازه ثابت در نظر گرفت که وقتی از آنها برای انجام عملیات برداری استفاده می کنید بسیار سریع هستند:
protocol GeometricVector: SIMD {
associatedtype Scalar: FloatingPoint
static func dot(_ a: Self, _ b: Self) -> Scalar
var length: Scalar { get }
func distance(to other: Self) -> Scalar
}
حال، اجازه دهید پیاده سازی های پیش فرض عملیات بالا را تعریف کنیم:
extension GeometricVector {
static func dot(_ a: Self, _ b: Self) -> Scalar {
(a * b).sum()
}
var length: Scalar {
Self.dot(self, self).squareRoot()
}
func distance(to other: Self) -> Scalar {
(self - other).length
}
}
و سپس باید به هر یک از انواعی که می خواهیم این توانایی ها را اضافه کنیم، یک انطباق اضافه کنیم:
extension SIMD2: GeometricVector where Scalar: FloatingPoint { }
extension SIMD3: GeometricVector where Scalar: FloatingPoint { }
extension SIMD4: GeometricVector where Scalar: FloatingPoint { }
extension SIMD8: GeometricVector where Scalar: FloatingPoint { }
extension SIMD16: GeometricVector where Scalar: FloatingPoint { }
extension SIMD32: GeometricVector where Scalar: FloatingPoint { }
extension SIMD64: GeometricVector where Scalar: FloatingPoint { }
این فرآیند سه مرحلهای برای تعریف پروتکل، اجرای پیشفرض آن، و سپس افزودن یک انطباق به انواع مختلف، نسبتاً تکراری است.
آیا پروتکل لازم بود؟
این واقعیت که هیچ یک از انواع SIMD
پیاده سازی منحصر به فرد ندارند یک علامت هشدار است. بنابراین در این مورد، پروتکل واقعا چیزی به ما نمی دهد.
تعریف آن در پسوند SIMD
اگر 3 عملگر را در یک پسوند پروتکل SIMD
بنویسیم، این می تواند مشکل را به طور خلاصه تر حل کند:
extension SIMD where Scalar: FloatingPoint {
static func dot(_ a: Self, _ b: Self) -> Scalar {
(a * b).sum()
}
var length: Scalar {
Self.dot(self, self).squareRoot()
}
func distance(to other: Self) -> Scalar {
(self - other).length
}
}
با استفاده از خطوط کمتر کد، همه پیاده سازی های پیش فرض را به همه انواع SIMD
اضافه کردیم.
گاهی اوقات ممکن است وسوسه شوید که این سلسله مراتب از انواع را ایجاد کنید، اما به یاد داشته باشید که همیشه لازم نیست. این همچنین به این معنی است که اندازه باینری برنامه کامپایل شده شما کوچکتر خواهد بود و کد شما برای کامپایل سریعتر خواهد بود.
با این حال، این رویکرد افزونه برای زمانی که تعدادی روش دارید که می خواهید اضافه کنید عالی است. با این حال، هنگامی که یک API بزرگتر طراحی می کنید، با مشکل مقیاس پذیری مواجه می شود.
است؟ دارد؟
قبلاً گفتیم که GeometricVector
SIMD
اصلاح خواهد کرد. اما آیا این یک رابطه است؟ مشکل این است که SIMD
عملیاتی را تعریف می کند که به ما امکان می دهد یک اسکالر 1 را به بردار اضافه کنیم، اما تعریف چنین عملیاتی در زمینه هندسه منطقی نیست.
بنابراین، شاید با قرار دادن SIMD
در یک نوع عمومی جدید که بتواند هر عدد ممیز شناور را کنترل کند، یک رابطه دارای-a بهتر باشد:
// NOTE: `Storage` is the underlying type that is storing the values,
// just like in a `SIMD` vector.
struct GeometricVector<Storage: SIMD> where Storage.Scalar: FloatingPoint {
typealias Scalar = Storage.Scalar
var value: Storage
init(_ value: Storage) { self.value = value }
}
سپس میتوانیم مراقب باشیم و فقط عملیاتهایی را تعریف کنیم که فقط در زمینه هندسه معنا دارند:
extension GeometricVector {
static func + (a: Self, b: Self) -> Self {
Self(a.value + b.value)
}
static func - (a: Self, b: Self) -> Self {
Self(a.value - b.value)
}
static func * (a: Self, b: Scalar) -> Self {
Self(a.value * b)
}
}
و ما هنوز هم میتوانیم از پسوندهای عمومی برای به دست آوردن 3 عملگر قبلی که میخواستیم پیادهسازی کنیم، استفاده کنیم که تقریباً مانند قبل هستند:
extension GeometricVector {
static func dot(_ a: Self, _ b: Self) -> Scalar {
(a.value * b.value).sum()
}
var length: Scalar {
Self.dot(self, self).squareRoot()
}
func distance(to other: Self) -> Scalar {
(self - other).length
}
}
به طور کلی، ما توانستهایم رفتار سه عملیات خود را به یک نوع ساده با استفاده از یک ساختار اصلاح کنیم. با پروتکلها، ما با مشکل نوشتن انطباقهای تکراری برای همه بردارهای SIMD
مواجه شدیم و همچنین نتوانستیم از در دسترس بودن عملگرهای خاصی مانند Scalar + Vector
جلوگیری کنیم (که در این مورد نمیخواستیم). به این ترتیب، به یاد داشته باشید که پروتکل ها یک راه حل همه جانبه و نهایی نیستند. اما گاهی اوقات راه حل های سنتی تر می توانند قوی تر باشند.
منابع برنامه نویسی پروتکل گرا بیشتر
در اینجا منابع اضافی در مورد موضوعات مورد بحث وجود دارد:
- WWDC 2015: برنامه نویسی پروتکل گرا در سوئیفت : این برنامه با استفاده از سوئیفت 2 ارائه شد، بنابراین از آن زمان تا کنون چیزهای زیادی تغییر کرده است (مثلاً نام پروتکل هایی که در ارائه استفاده کردند) اما این هنوز منبع خوبی برای تئوری و استفاده های پشت سر آن است. .
- معرفی برنامه نویسی پروتکل گرا در سوئیفت 3 : این در سوئیفت 3 نوشته شده است، بنابراین ممکن است برخی از کدها برای کامپایل شدن با موفقیت نیاز به اصلاح داشته باشند، اما منبع عالی دیگری است.
- WWDC 2019: طراحی مدرن Swift API : تفاوتهای بین انواع مقدار و مرجع را مورد بررسی قرار میدهد، یک مورد استفاده از زمانی که پروتکلها میتوانند بدترین انتخاب در طراحی API باشند (همانطور که در بخش «نکاتی برای طراحی خوب API» در بالا، کلید جستجوی اعضای مسیر و بستهبندیهای ویژگی.
- Generics : مستندات خود سوئیفت برای Swift 5 همه چیز در مورد ژنریک.