2009-07-27 28 views
10

Tôi đã chơi với các chương trình chức năng gần đây và có phương pháp điều trị khá tốt về chủ đề tác dụng phụ, tại sao chúng nên được chứa, vv Trong các dự án mà OOP được sử dụng, tôi đang tìm kiếm một số tài nguyên các chiến lược để giảm thiểu tác dụng phụ và/hoặc tiểu bang.Các nguồn lực tốt nhất để học cách tránh các tác dụng phụ và tình trạng trong OOP là gì?

Ví dụ điển hình về việc này là sách Dịch vụ web RESTful cung cấp cho bạn các chiến lược để giảm thiểu trạng thái trong ứng dụng web. Những gì người khác tồn tại?

Hãy nhớ rằng tôi không tìm kiếm một nhà phân tích OOP/mẫu thiết kế khác (mặc dù đóng gói tốt và khớp nối lỏng giúp tránh tác dụng phụ) mà là tài nguyên mà chủ đề chính là tác dụng phụ/trạng thái.

Một số câu trả lời biên soạn

  • lập trình OOP người chủ yếu quan tâm đến trạng thái làm như vậy vì đồng thời, vì vậy đọc Java Concurrency in Practice. [chính xác những gì tôi đang tìm kiếm]
  • Sử dụng TDD để làm cho các hiệu ứng phụ hiển thị rõ hơn [Tôi thích nó, ví dụ: setUps càng lớn, bạn cần có nhiều trạng thái hơn để chạy thử nghiệm = cảnh báo tốt]
  • Command-query separation[Tốt thứ, ngăn ngừa tác dụng phụ của việc thay đổi một đối số chức năng mà thường là khó hiểu]
  • Phương pháp làm chỉ có một điều, có lẽ sử dụng tên mô tả nếu họ thay đổi trạng thái của đối tượng của họ do đó, nó đơn giản và thông thoáng.
  • Make objects immutable[Tôi thực sự thích điều này]
  • Chuyển giá trị làm thông số thay vì lưu trữ chúng trong các biến thành viên. [Tôi không liên kết điều này; nó làm lộn xộn lên nguyên mẫu chức năng và được khuyến khích bởi Clean Code và các sách khác, mặc dù tôi thừa nhận nó sẽ giúp vấn đề nhà nước]
  • Giá trị tính toán thay vì lưu trữ và cập nhật chúng [Tôi cũng thực sự thích điều này; trong các ứng dụng tôi làm việc về hiệu suất là một mối quan tâm nhỏ]
  • Tương tự, đừng sao chép trạng thái xung quanh nếu bạn có thể tránh nó. Làm cho một đối tượng chịu trách nhiệm giữ nó và cho phép người khác truy cập nó ở đó. [nguyên tắc OOP cơ bản, lời khuyên tốt]
+0

Tôi không hiểu chính xác các loại tác dụng phụ mà bạn muốn nói và ý bạn là gì với trạng thái (trong trạng thái REST thuộc về giao thức chứ không phải là mô hình lập trình) trong ngữ cảnh đó. – Daff

+0

"Tránh" tác dụng phụ và nhà nước không thực sự là những gì bạn có nghĩa là, tôi nghĩ. – Benjol

+0

Bạn có ý nghĩa gì bởi "trạng thái", chính xác? Các giá trị của các thành viên instance của một đối tượng tại bất kỳ điểm nào, cộng với các giá trị của bất kỳ thành viên tĩnh nào của lớp của đối tượng? Bởi vì đó là một phần rất quan trọng của OOP, trừ khi bạn dự định lưu trữ tất cả dữ liệu của bạn trong các biến toàn cục. – JAB

Trả lời

7

Tôi không nghĩ rằng bạn sẽ tìm thấy nhiều tài liệu hiện tại trong thế giới OO về chủ đề này, chỉ đơn giản là vì OOP (và lập trình bắt buộc nhất, cho rằng vấn đề) dựa về trạng thái và tác dụng phụ. Ví dụ: xem xét ghi nhật ký. Đó là tác dụng phụ thuần túy, nhưng trong bất kỳ ứng dụng J2EE tự tôn trọng nào, nó ở khắp mọi nơi. QuickSort ban đầu của Hoare dựa trên trạng thái có thể thay đổi được, vì bạn phải trao đổi các giá trị xung quanh một trục, nhưng nó cũng ở khắp mọi nơi.

Đây là lý do tại sao nhiều lập trình viên OO gặp khó khăn khi gói đầu của họ xung quanh các mô hình lập trình chức năng.Họ cố gắng gán lại giá trị của "x", phát hiện ra rằng nó không thể được thực hiện (ít nhất là không theo cách nó có thể trong mọi ngôn ngữ khác mà họ đã làm việc), và họ giơ tay lên và hét lên "Đây là Không thể nào!" Cuối cùng, nếu họ kiên nhẫn, họ học đệ quy và currying và làm thế nào chức năng bản đồ thay thế nhu cầu cho các vòng, và họ bình tĩnh lại. Nhưng đường cong học tập có thể rất dốc đối với một số người.

Các lập trình viên OO những ngày này quan tâm nhất về việc tránh trạng thái là những người làm việc trên đồng thời. Lý do cho điều này là rõ ràng - trạng thái có thể thay đổi và tác dụng phụ gây đau đầu rất lớn khi bạn đang cố gắng quản lý sự tương tranh giữa các chủ đề. Kết quả là, các cuộc thảo luận tốt nhất mà tôi đã thấy trong thế giới OO về tránh trạng thái là Java Concurrency in Practice.

5

Tôi nghĩ rằng các quy tắc khá đơn giản: phương pháp chỉ nên làm một việc, và mục đích cần được thông báo rõ ràng trong tên phương pháp.

Phương thức nên truy vấn hoặc thay đổi dữ liệu, nhưng không bao giờ cả hai.

+0

Tôi nhớ chương đó trong Bộ luật sạch sẽ ..cuốn sách hay – rcampbell

+0

Heh, tôi đã không đọc cuốn sách đó nhưng tôi đã đọc nó ở nơi khác. Thật khó chịu khi bạn thấy mọi người không tuân thủ quy tắc vì mọi thứ trở nên khó hiểu và sau đó họ tự hỏi tại sao mã của họ không hoạt động như mong muốn. – jkp

3

Một cách để cô lập các tác dụng phụ trong OO là cho phép các hoạt động chỉ trả về một đối tượng mô tả của các tác dụng phụ gây ra.

Command-query separation là mẫu phù hợp với ý tưởng này. Bằng cách thực hành TDD (hoặc ít nhất là viết bài kiểm tra đơn vị) thường sẽ nhận thức được nhiều hơn về tác dụng phụ và sử dụng chúng một cách tiết kiệm hơn, và cũng tách biệt chúng khỏi các biểu thức miễn phí khác có thể dễ dàng ghi dữ liệu (dự kiến, thực tế) đơn vị kiểm tra cho.

4

Một số điều nhỏ tôi làm:

  • thích trạng thái bất biến, nó là tương đối lành tính. Ví dụ. trong Java, tôi tạo các biến thành viên cuối cùng và đặt chúng trong hàm tạo bất cứ khi nào có thể.

  • Chuyển các giá trị dưới dạng tham số thay vì lưu trữ chúng trong các biến thành viên.

  • Giá trị tính toán thay vì lưu trữ và cập nhật chúng, nếu điều đó có thể được thực hiện đủ rẻ. Điều này giúp tránh dữ liệu không nhất quán bằng cách quên cập nhật nó.

  • Tương tự, không sao chép trạng thái xung quanh nếu bạn có thể tránh. Làm cho một đối tượng chịu trách nhiệm giữ nó và cho phép người khác truy cập nó ở đó.

+0

Tôi thích đề xuất làm cho các đối tượng bất biến. Tôi đã tìm thấy tham chiếu này: http://www.javapractices.com/topic/TopicAction.do?Id=29 – rcampbell

Các vấn đề liên quan