một nhà xây dựng nên phức tạp như thế nào

Tôi đang thảo luận với đồng nghiệp về việc một nhà xây dựng có thể làm được bao nhiêu công việc. Tôi có một lớp, B mà bên trong yêu cầu một đối tượng khác A. Đối tượng A là một trong số ít thành viên mà lớp B cần để thực hiện công việc của mình. Tất cả các phương thức công khai của nó phụ thuộc vào đối tượng bên trong A. Thông tin về đối tượng A được lưu trữ trong DB vì vậy tôi cố gắng xác thực và lấy nó bằng cách tìm kiếm nó trên DB trong hàm tạo. Đồng nghiệp của tôi đã chỉ ra rằng hàm tạo không nên thực hiện nhiều công việc khác ngoài việc nắm bắt các tham số của hàm tạo. Vì tất cả các phương thức công khai sẽ thất bại nếu không tìm thấy đối tượng A bằng cách sử dụng các đầu vào cho hàm tạo, tôi lập luận rằng thay vì cho phép một cá thể được tạo và sau đó thất bại, tốt hơn là nên ném sớm vào hàm tạo.

Người khác nghĩ gì? Tôi đang sử dụng C # nếu điều đó làm cho bất kỳ sự khác biệt.

Đọc Có bao giờ có lý do để thực hiện tất cả công việc của một đối tượng trong một hàm tạo không? Tôi tự hỏi tìm nạp đối tượng A bằng cách truy cập DB là một phần của "bất kỳ khởi tạo nào khác cần thiết để làm cho đối tượng sẵn sàng sử dụng" bởi vì nếu người dùng chuyển sai giá trị cho hàm tạo, tôi sẽ không thể sử dụng bất kỳ phương thức công khai nào của nó.

Các nhà xây dựng nên khởi tạo các trường của một đối tượng và thực hiện bất kỳ khởi tạo nào khác cần thiết để làm cho đối tượng sẵn sàng sử dụng. Điều này thường có nghĩa là các nhà xây dựng là nhỏ, nhưng có những kịch bản trong đó đây sẽ là một khối lượng công việc đáng kể.

Câu hỏi của bạn bao gồm hai phần hoàn toàn riêng biệt:

Tôi nên ném ngoại lệ từ constructor, hay tôi nên có phương thức thất bại?

Đây rõ ràng là áp dụng nguyên tắc Fail-fast . Làm cho hàm tạo không thành công dễ gỡ lỗi hơn nhiều so với việc phải tìm ra lý do tại sao phương thức bị lỗi. Ví dụ, bạn có thể lấy ví dụ đã được tạo từ một số phần khác của mã và bạn gặp lỗi khi gọi phương thức. Rõ ràng là đối tượng được tạo ra sai? Không.

Đối với vấn đề "bọc cuộc gọi trong thử / bắt". Các ngoại lệ có nghĩa là đặc biệt . Nếu bạn biết một số mã sẽ đưa ra một ngoại lệ, bạn không bọc mã trong thử / bắt, nhưng bạn xác thực các tham số của mã đó trước khi bạn thực thi mã có thể ném ngoại lệ. Các ngoại lệ chỉ có nghĩa là cách để đảm bảo hệ thống không rơi vào trạng thái không hợp lệ. Nếu bạn biết một số tham số đầu vào có thể dẫn đến trạng thái không hợp lệ, bạn chắc chắn rằng các tham số đó không bao giờ xảy ra. Theo cách này, bạn chỉ phải thực hiện thử / bắt ở những nơi mà bạn có thể xử lý ngoại lệ một cách hợp lý, thường nằm trên ranh giới của hệ thống.

Tôi có thể truy cập "các phần khác của hệ thống, như DB" từ hàm tạo không.

Tôi nghĩ rằng điều này đi ngược lại với nguyên tắc ít ngạc nhiên nhất . Không nhiều người mong đợi constructor truy cập DB. Vì vậy, không, bạn không nên làm điều đó.

Ừ

Một nhà xây dựng nên làm ít nhất có thể - vấn đề là hành vi ngoại lệ đó trong các nhà xây dựng là khó xử. Rất ít lập trình viên biết hành vi phù hợp là gì (bao gồm các tình huống kế thừa) và buộc người dùng của bạn phải thử / nắm bắt mọi hoạt động tức thời là ... đau đớn nhất.

Có hai phần này, trong hàm tạo và sử dụng hàm tạo. Thật khó xử trong hàm tạo vì bạn không thể làm gì nhiều khi có ngoại lệ xảy ra. Bạn không thể trả lại một loại khác. Bạn không thể trả về null. Về cơ bản, bạn có thể điều chỉnh lại ngoại lệ, trả về một đối tượng bị hỏng (bộ dẫn xấu) hoặc (trường hợp tốt nhất) thay thế một số phần bên trong bằng một mặc định lành mạnh. Sử dụng hàm tạo rất khó xử vì sau đó các phần khởi tạo của bạn (và phần khởi tạo của tất cả các loại dẫn xuất!) Có thể ném. Sau đó, bạn không thể sử dụng chúng trong khởi tạo thành viên. Cuối cùng, bạn sử dụng các ngoại lệ cho logic để xem "sáng tạo của tôi có thành công không?", Vượt quá khả năng đọc (và mong manh) do thử / bắt ở mọi nơi.

Nếu nhà xây dựng của bạn đang làm những việc không tầm thường hoặc những điều có thể dự kiến ​​hợp lý sẽ thất bại, hãy xem xét một Createphương thức tĩnh (với một nhà xây dựng không công khai) thay vào đó. Nó dễ sử dụng hơn, dễ gỡ lỗi hơn và vẫn giúp bạn có được một bản dựng hoàn chỉnh khi thành công.

Con Contor - cân bằng độ phức tạp của phương thức thực sự là một vấn đề thảo luận về stile tốt. Khá thường xây dựng rỗng Class() {}được sử dụng, với một phương pháp Init(..) {..}cho những thứ phức tạp hơn. Trong số các đối số sẽ được đưa vào tài khoản:

• Khả năng tuần tự hóa lớp
• Với phương thức init ban đầu từ hàm tạo, bạn thường cần lặp lại cùng một chuỗi Class x = new Class(); x.Init(..);nhiều lần, một phần trong Bài kiểm tra đơn vị. Không tốt, tuy nhiên, rõ ràng để đọc. Đôi khi, tôi chỉ cần đặt chúng vào một dòng mã.
• Khi mục đích Kiểm thử đơn vị chỉ là kiểm tra khởi tạo Lớp, tốt hơn là có Ban đầu, để thực hiện các hành động phức tạp hơn từng bước một, với các Xác nhận trung gian.