HomeOur Team
Why Protocol-Oriented Programming?
Articles
Why Protocol-Oriented Programming?
huy.nguyen
huy.nguyen
March 31, 2021
2 min

Phần 1: Tại sao lại không phải là hướng đối tượng?

Protocol-Oriented Programming (POP) là phương pháp lập trình thiết kế và làm việc ưu tiên với các Protocol, thay vì Class như OOP. Các bạn đang nghĩ, Protocol thì có gì hay, mình vẫn có thể làm mọi việc hoàn hảo với Class. Vậy thì mình sẽ so sánh 1 chút để các bạn hiểu rõ hơn về việc bắt đầu với Protocol hay với Class.

1-0: Classes are Awesome

  • Đóng gói (Encapsulation)
  • Giới hạn truy cập (Access Control)
  • Trừu tượng (Abstraction)
  • Khả năng mở rộng (Extensibility)

Những khả năng này giúp chúng ta xử lý được những dự án phức tạp, mà đó là một trong những thách thức lớn nhất trong nghề lập trình.

1-1: Types are Awesome

Nhưng chúng ta cũng có thể làm tất cả những điều trên với structsenums (trong Swift)

2-1: Classes are Awesome

Tái sử dụng và tuỳ biến

  • Kế thừa (Một trong những thứ chỉ có thể áp dụng với Classes )

    Đây là một siêu năng lực rất hữu ích. Khi một superclass cha định nghĩa một function thì các subclasses mặc có thể nhiên sử dụng function đã được định nghĩa.

  • Tuỳ biến (Override)

    Kế thừa thật sự rất tuyệt vời. Nhưng còn tuyệt vời hơn khi có thể tuỳ biến những functions đã được định nghĩa bởi superclass

Tất cả quỳ xuống =)). Mình nghĩ là các bạn đã hiểu Classes mạnh như nào.

(2-1)-1: Classes rất mạnh, nhưng cái giá là gì?

  1. Chia sẻ ẩn (Implicit Sharing)

    Khi AB cùng chia sẻ Data mọi thay đổi áp dụng vào Data của A hoặc B sẽ có ảnh hưởng đến đối phương ⇒ dẫn đến bugs là điều khó tránh khỏi

  2. Kế thừa tất cả =))

    Khi bắt đầu bằng một Class. Bạn phải chọn rất cẩn thận, vì bạn chỉ có 1 SuperClass

    • Nếu SuperClass có biến lưu trữ (stored property):

      • Subclass phải nhận dù có dùng hay không
      • Phải khởi tạo
    • Phải biết các methosSuperClass chạy như nào. Biết khi nào cách override các methos như thế nào (hoặc là có nên override hay không, hoặc bắt đầu từ đầu hay cuối method)

  3. Lost Type Relationship (Mình cũng không biết gọi là gì “mất quan hệ chăng?“)

    Giả sử, mình sẽ viết 1 abstract class để sắp xếp.

    class Ordered {
      func precedes(other: Ordered) -> Bool { fatalError("implement me!") }
    }
    
    class Label : Ordered { var text: String = "" ... }
    
    class Number : Ordered {
      var value: Double = 0
      override func precedes(other: Ordered) -> Bool {
        return value < (other as! Number).value
      }
    }
    

Nhìn vào đống code cồng kềnh và chắc chắn sẽ gây ra crash này. Các bạn nghĩ mình có thể làm tốt hơn không?

as! ASubClass đây là dấu hiệu của Lost Type Relationship khi bạn sử dụng AbstactClasses . Nhìn vào ví dụ mình vừa đưa thì bạn cũng có thể hiểu, chúng ta cần một cơ chế Abstraction tốt hơn.

Vâng, mình chắc là các bạn đã đoán ra cơ chế Abstraction cực mạnh trong Swift và cũng là trái tim của Swift: Protocol. Protocols có thể giải quyết tất cả hạn chế mình vừa trình bày bên trên. Mình sẽ tiếp tục giới thiệu với các bạn trong phần 2.


Tags

202103swiftpop
huy.nguyen

huy.nguyen

Senior iOS Developer

Expertise

ios

Related Posts

DIP in Android, Dagger and Koin (P1)
DIP in Android, Dagger and Koin (P1)
March 28, 2021
5 min
© 2021, All Rights Reserved.

Quick Links

HomeOur Team

Social Media