2013-08-13 37 views
5

Nếu ví dụ tôi đã mô hình này ActiveRecord:Đó có phải là cách thích hợp để cấu trúc lại các mô hình chất béo ActiveRecord không?

app/models/order.rb

class Order < ActiveRecord::Base 
    # model logic 
end 
require "lib/someclass.rb" 

lib/somelass.rb

class Order 
    before_save :something 
    # more logic here 
end 

Có phải đó là một cách tốt để Refactor/trích xuất logic từ mô hình? Hoặc có thể sử dụng lớp quan tâm, lớp dịch vụ hoặc điều gì đó khác?

+0

loại tách biệt đó hoàn toàn vô nghĩa. Nếu bạn phải giải mã một mô hình, hãy xem xét các mối quan tâm. – sevenseacat

+0

@sevenseacat, bạn có thể giải thích tại sao nó vô nghĩa? –

+0

bởi vì nó có nghĩa là bạn đang chia nhỏ một lớp thành nhiều tệp hoàn toàn không có lý do gì cả.Bạn không làm cho mô hình trở nên mỏng hơn bằng cách làm điều đó, bạn chỉ làm cho codebase phức tạp hơn để làm việc. – sevenseacat

Trả lời

14

Giống như ai đó nói với tôi một thời gian dài trước:

Mã refactoring không phải là một vấn đề của việc di chuyển một cách ngẫu nhiên mã xung quanh.

Trong ví dụ của bạn đó là chính xác những gì bạn đang làm: di chuyển mã vào một tập tin

Tại sao nó xấu?

Bằng cách di chuyển mã xung quanh như thế này, bạn đang làm cho lớp ban đầu của bạn phức tạp hơn vì logic được chia ngẫu nhiên thành nhiều lớp khác. Tất nhiên nó có vẻ tốt hơn, ít mã trong một tập tin là trực quan tốt hơn nhưng đó là tất cả.

Ưu tiên thành phần to thừa kế. Sử dụng mixins như thế này là yêu cầu "làm sạch" một căn phòng lộn xộn bằng cách bán lộn xộn vào sáu ngăn kéo rác riêng biệt và đóng sập chúng lại. Chắc chắn, nó trông sạch hơn trên bề mặt, nhưng ngăn kéo rác thực sự làm cho nó khó khăn hơn để xác định và thực hiện các phân hủy và trích xuất cần thiết để làm rõ mô hình miền.

Tôi nên làm gì sau đó?

Bạn nên tự hỏi mình:

  • Những mã đi lại với nhau và có thể là một phần của một lớp mới/mô-đun?
  • Ở đâu có ý nghĩa khi trích xuất mã đến một nơi khác?
  • Tôi có một số mã được chia sẻ trên ứng dụng của mình không?
  • Tôi có thể trích xuất các mẫu lặp lại trong cơ sở mã của mình không?

Extract Service Object

tôi tiếp cận với dịch vụ Objects khi một hành động đáp ứng một hoặc nhiều các tiêu chí:

  • Hành động rất phức tạp
  • Hành động đạt trên nhiều mô hình
  • Hành động tương tác với dịch vụ bên ngoài
  • Các hành động không phải là một mối quan tâm cốt lõi của mô hình cơ bản
  • Có nhiều cách để thực hiện hành động

Extract Mẫu Objects

Khi có nhiều mô hình có thể được cập nhật bởi aa nộp mẫu đơn, bạn có thể muốn tạo một đối tượng biểu mẫu.

Điều này cho phép đặt tất cả logic biểu mẫu (quy ước tên, xác thực, v.v.) vào một nơi.

Extract Objects Query

Bạn nên giải nén SQL phức tạp/truy vấn NoSQL vào lớp của mình. Mỗi đối tượng truy vấn chịu trách nhiệm trả về tập kết quả dựa trên các tiêu chí/quy tắc kinh doanh.

Extract Các diễn giả/trang trí

Extract xem logic vào thuyết trình. Mô hình của bạn không nên đối phó với logic lượt xem cụ thể. Hơn nữa, nó sẽ cho phép bạn sử dụng người trình bày của bạn trong nhiều khung nhìn.

More on decorators

Nhờ this bài đăng blog để giúp tôi đặt này lại với nhau.

1

Giữ mã trong cùng một lớp di chuyển logic, nó không trích xuất.

Việc từ chối khai báo gọi lại là gây hiểu lầm và có thể gây nguy hiểm. Callbacks bị lạm dụng đủ; buộc người đọc truy tìm các tệp có liên quan là tàn nhẫn.

Không có chung cách trả lời câu hỏi theo yêu cầu; các "tốt nhất" refactors phụ thuộc vào những gì thực sự đang refactoried. Thông tin về vòng đời phải rõ ràng và chính xác.

Mối quan tâm, dịch vụ, trang trí, mặt tiền, v.v ... là cơ chế tốt hỗ trợ tái cấu trúc. Mà không biết những gì đang được tái cấu trúc, nó không thể cung cấp lời khuyên có ý nghĩa về những gì "tốt nhất".