12/08/2018, 13:31

Processor Model Design Pattern

Bình thường, khi 1 dự án phát triển đến 1 mức độ nào đó, các model sẽ có xu hướng trở nên phức tạp. Lúc này chúng ta cần xem xét 1 vài "chiến lược" để kiểm soát tình hình và đặt mọi thứ trong tầm kiểm soát. Background Với rails, chúng ta có ActiveRecord, một class trộn lẫn tính logic và bền ...

Bình thường, khi 1 dự án phát triển đến 1 mức độ nào đó, các model sẽ có xu hướng trở nên phức tạp. Lúc này chúng ta cần xem xét 1 vài "chiến lược" để kiểm soát tình hình và đặt mọi thứ trong tầm kiểm soát.

Background

Với rails, chúng ta có ActiveRecord, một class trộn lẫn tính logic và bền vững. Điều này dặc biệt thuận lợi khi bắt đầu một ứng dụng, nhưng đáng tiếc nó lại vi phạm nghiêm trọng nguyên tắc đơn nhiệm "Single Responsibility Principle."

Việc biến 1 dự án lớn thành các phần riêng biệt với các vai trò rõ ràng là 1 ý tưởng tốt.

Creating a Processor Object

1 processor object là 1 đối tượng chỉ liên quan tới việc thao tác dữ liệu của các object khác.

Cách viết rất đơn giản:

class MyProcessor
  def initialize(thing, stuff)
    @thing = thing
    @stuff = stuff
  end
end

Where Does It Live?

Bạn có thể lưu trữ các processor object của mình vào app/models, nhưng nếu bạn muốn phân tách chúng rõ ràng hơn thì có thể tạo app/lib và đặt chúng ở đó. Bất kỳ thư mục nào bổ sung trong app/ sẽ được thêm vào đường dẫn tải tự động khi server bắt đầu chạy, do đó cứ tạo ra các thư mục bất cứ khi nào chúng có ý nghĩa cho việc tổ chức các project của chúng ta.

Practical Techniques

Một processor object chủ yếu sử dụng các hàm của ruby, tuy nhiên cũng có một số phương pháp khiến việc sử dụng chúng dễ dàng hơn

attr_reader

attr_reader, viết tắt của "Attribute Reader", sẽ tạo ra 1 instance variable và phương thức truy xuất cho bạn:

class MyClass
  attr_reader :my_attribute

  # That's the same as doing this...

  def my_attribute
    @my_attribute
  end
end

Như vậy, khi bạn tạo thuộc tính đó từ bên ngoài, nó chỉ có thể được đọc. Nếu muốn thay đổi nó, bạn cần dùng attr_accessor, mặc dù nó vi phạm tính đóng gói của object con.

Bạn cũng có thể kết hợp nhiều thuộc tính trong attr_reader như sau:

attr_reader :first_attribute, :second_attribute

delegate

Theo luật Demeter, chúng ta có thể nói chuyện với 1 object nhưng không nên nói chuyện trực tiếp với con của nó.

Hãy tưởng tượng, chúng ta có một instance của class Plane: @plane. Khi chúng ta muốn engines bắt đầu, có thể chúng ta sẽ viết thế này:

@plane.engines.each{|e| e.start}

Nhưng kiến thức về @plane có liên quan gì đến các engine của nó? Chúng ta đang phá vỡ tính đóng gói của class Plane

Thay vào đó, chúng ta sẽ nói cho máy bay biết phải làm gì:

@plane.start_engines

Việc này có nghĩa chúng ta nói cho @plane biết về việc khởi động engines.

Tại sao điều này liên quan processor objects? Khi bạn tạo ra 1 đối tượng, bạn thường muốn làm việc trên các attributes và method của các đối tượng con của nó. ĐỪNG làm điều này:

@my_object.child.the_method

Hãy thay thế bằng:

@my_object.the_method

Vậy làm thế nào để nó làm việc?

class MyObject
  attr_reader :child

  def the_method
    child.the_method
  end
end

Nếu có nhiều object con với nhiều method, hãy sử dụng delegate:

class MyObject
  attr_reader :child
  delegate :the_method, to: child
end

Bạn có thể delegate nhiều method 1 lúc:

class MyObject
  attr_reader :child
  delegate :the_method, :second_method, :third_method, to: child
end

Bài viết dịch từ http://tutorials.jumpstartlab.com/topics/models/processor_models.html

0