Làm thế nào cần thiết để tuân theo các thực tiễn lập trình phòng thủ cho mã sẽ không bao giờ được công khai?

Tôi đang viết một triển khai Java của một trò chơi bài, vì vậy tôi đã tạo ra một loại Bộ sưu tập đặc biệt mà tôi đang gọi là Khu vực. Tất cả các phương thức sửa đổi của Bộ sưu tập của Java đều không được hỗ trợ, nhưng có một phương thức trong API khu vực move(Zone, Card), giúp di chuyển Thẻ từ Vùng đã cho sang chính nó (được thực hiện bằng các kỹ thuật riêng tư gói). Bằng cách này, tôi có thể đảm bảo rằng không có thẻ nào được đưa ra khỏi một khu vực và chỉ đơn giản là biến mất; họ chỉ có thể được chuyển đến khu vực khác.

Câu hỏi của tôi là, loại mã hóa phòng thủ này cần thiết như thế nào? Đó là "chính xác", và nó cảm thấy như một cách thực hành đúng, nhưng nó không giống như API khu vực sẽ trở thành một phần của một số thư viện công cộng. Nó chỉ dành cho tôi, vì vậy nó giống như tôi đang bảo vệ mã của mình khỏi chính mình khi tôi có thể hiệu quả hơn bằng cách chỉ sử dụng Bộ sưu tập tiêu chuẩn.

Tôi nên lấy ý tưởng Khu vực này bao xa? Bất cứ ai cũng có thể cho tôi một lời khuyên về việc tôi nên suy nghĩ bao nhiêu về việc giữ các hợp đồng trong các lớp tôi viết, đặc biệt là cho những người không thực sự được công khai?

Tôi sẽ không giải quyết vấn đề thiết kế - chỉ là câu hỏi liệu có nên làm mọi thứ "chính xác" trong API không công khai hay không.

nó chỉ dành cho tôi, vì vậy nó giống như tôi đang bảo vệ mã của chính mình khỏi chính tôi

Đó chính xác là vấn đề. Có lẽ có những lập trình viên ngoài kia, những người nhớ các sắc thái của mọi lớp và phương pháp họ từng viết và không bao giờ gọi nhầm họ với hợp đồng sai. Tôi không phải là một trong số họ. Tôi thường quên cách mã mà tôi đã viết được cho là hoạt động trong vài giờ sau khi viết nó. Sau khi bạn nghĩ rằng bạn đã hiểu đúng một lần, tâm trí của bạn sẽ có xu hướng chuyển đổi sang vấn đề bạn đang làm việc hiện tại .

Bạn có công cụ để chống lại điều đó. Những công cụ này bao gồm các quy ước (không theo thứ tự cụ thể), kiểm tra đơn vị và kiểm tra tự động khác, kiểm tra tiền điều kiện và tài liệu. Bản thân tôi đã tìm thấy các bài kiểm tra đơn vị là vô giá vì cả hai đều buộc bạn phải suy nghĩ về cách sử dụng hợp đồng của bạn và cung cấp tài liệu sau này về cách giao diện được thiết kế.

Tôi thường tuân theo một số quy tắc đơn giản:

• Cố gắng luôn luôn lập trình bằng hợp đồng .
• Nếu một phương thức có sẵn công khai hoặc nhận đầu vào từ thế giới bên ngoài , hãy thực thi một số biện pháp phòng thủ (ví dụ IllegalArgumentException).
• Đối với mọi thứ khác chỉ có thể truy cập được trong nội bộ, hãy sử dụng các xác nhận (ví dụ assert input != null).

Nếu một khách hàng thực sự thích nó, họ sẽ luôn tìm cách làm cho mã của bạn hoạt động sai. Họ luôn có thể làm điều đó thông qua sự phản ánh, ít nhất. Nhưng đó là vẻ đẹp của thiết kế theo hợp đồng . Bạn không chấp nhận việc sử dụng mã như vậy và vì vậy bạn không thể đảm bảo rằng nó sẽ hoạt động trong các tình huống như vậy.

Đối với trường hợp cụ thể của bạn, nếu người ngoài Zonekhông nên sử dụng và / hoặc truy cập, hãy đặt gói lớp ở chế độ riêng tư (và có thể final), hoặc tốt nhất là sử dụng các bộ sưu tập mà Java đã cung cấp cho bạn. Họ đã được thử nghiệm và bạn không phải phát minh lại bánh xe. Lưu ý rằng điều này không ngăn bạn sử dụng các xác nhận trong toàn bộ mã của mình để đảm bảo mọi thứ hoạt động như mong đợi.

Lập trình phòng thủ là một điều rất tốt.
Cho đến khi nó bắt đầu nhận được trong cách viết mã. Sau đó, nó không phải là một điều tốt.

Nói một cách thực tế hơn một chút ...

Có vẻ như bạn đang ở rìa của việc đưa mọi thứ đi quá xa. Thách thức (và câu trả lời cho câu hỏi của bạn) nằm ở việc hiểu các quy tắc hoặc yêu cầu kinh doanh của chương trình là gì.

Sử dụng API trò chơi thẻ của bạn làm ví dụ, có một số môi trường nơi mọi thứ có thể được thực hiện để ngăn chặn gian lận là rất quan trọng. Một lượng lớn tiền thật có thể được tham gia, do đó, thật hợp lý khi đặt một số lượng lớn séc để đảm bảo rằng gian lận không thể xảy ra.

Mặt khác, bạn cần lưu tâm đến các nguyên tắc RẮN, đặc biệt là trách nhiệm đơn lẻ. Yêu cầu lớp container kiểm toán hiệu quả nơi thẻ sẽ đến có thể hơi nhiều. Có thể tốt hơn khi có một lớp kiểm toán / bộ điều khiển giữa hộp chứa thẻ và chức năng nhận các yêu cầu di chuyển.

Liên quan đến những lo ngại đó, bạn cần hiểu những thành phần nào trong API của bạn được phơi bày công khai (và do đó dễ bị tổn thương) so với những gì riêng tư và ít bị lộ. Tôi không phải là người ủng hộ hoàn toàn cho "lớp phủ bên ngoài cứng với lớp bên trong mềm", nhưng sự trở lại tốt nhất của nỗ lực của bạn là làm cứng lớp ngoài của API.

Tôi không nghĩ rằng người dùng cuối dự định của một thư viện là rất quan trọng đối với quyết tâm về việc bạn đặt bao nhiêu chương trình phòng thủ. Ngay cả với các mô-đun mà tôi viết cho mục đích sử dụng của riêng mình, tôi vẫn đưa ra một biện pháp kiểm tra để đảm bảo rằng tương lai tôi không mắc phải một số lỗi vô ý khi gọi thư viện.

Mã hóa phòng thủ không chỉ là một ý tưởng tốt cho mã công khai. Đó là một ý tưởng tuyệt vời cho bất kỳ mã nào không bị vứt bỏ ngay lập tức. Chắc chắn, bạn biết làm thế nào nó được gọi là bây giờ , nhưng bạn không biết bạn sẽ nhớ sáu tháng này như thế nào khi bạn quay lại dự án.

Cú pháp cơ bản của Java cung cấp cho bạn rất nhiều khả năng phòng thủ so với ngôn ngữ cấp thấp hơn hoặc được giải thích như C hoặc Javascript tương ứng. Giả sử rằng bạn đặt tên cho các phương thức của mình một cách rõ ràng và không có "trình tự phương thức" bên ngoài, bạn có thể thoát khỏi việc chỉ định các đối số là một kiểu dữ liệu chính xác và bao gồm cả hành vi hợp lý nếu dữ liệu được nhập đúng cách vẫn có thể không hợp lệ.

. mỗi thẻ. Nhưng vì tôi không biết Khu vực của bạn làm gì ngoài việc giữ thẻ, thật khó để biết liệu điều đó có phù hợp hay không.)

Trước tiên, hãy tạo một lớp giữ danh sách các Vùng để bạn không bị mất Vùng hoặc thẻ trong đó. Sau đó, bạn có thể kiểm tra xem chuyển khoản có trong ZoneList của bạn không. Lớp này có thể sẽ là một loại đơn, vì bạn sẽ chỉ cần một thể hiện, nhưng bạn có thể muốn có các Vùng sau, vì vậy hãy mở các tùy chọn của bạn.

Thứ hai, không có Bộ sưu tập Khu vực hoặc Khu vực thực hiện Bộ sưu tập hoặc bất cứ điều gì khác trừ khi bạn muốn có nó. Đó là, nếu một Vùng hoặc Danh sách Vùng sẽ được chuyển đến một thứ gì đó mong đợi Bộ sưu tập, thì hãy triển khai nó. Bạn có thể vô hiệu hóa một loạt các phương thức bằng cách yêu cầu chúng ném một ngoại lệ (Unim HiệnedException, hoặc một cái gì đó tương tự) hoặc bằng cách đơn giản là chúng không làm gì cả. (Hãy suy nghĩ thật kỹ trước khi sử dụng tùy chọn thứ hai. Nếu bạn làm điều đó bởi vì thật dễ dàng, bạn sẽ thấy mình thiếu các lỗi mà bạn có thể đã mắc phải sớm.)

Có những câu hỏi thực sự về những gì là "chính xác". Nhưng một khi bạn tìm ra những gì bạn sẽ muốn làm những điều đó theo cách đó. Trong hai năm, bạn sẽ quên tất cả những điều này và nếu bạn cố gắng sử dụng mã thì bạn sẽ thực sự khó chịu với anh chàng đã viết nó theo cách phản trực giác như vậy và không giải thích được gì.

Mã hóa phòng thủ trong thiết kế API nói chung là về việc xác thực đầu vào và cẩn thận chọn một cơ chế xử lý lỗi thích hợp. Những điều khác câu trả lời đề cập cũng đáng chú ý.

Đây thực sự không phải là những gì ví dụ của bạn là về. Bạn đang ở đó giới hạn bề mặt API của bạn, vì một lý do rất cụ thể. Như GlenH7 đã đề cập, khi bộ thẻ được sử dụng trong một trò chơi thực tế, với một cỗ bài ('đã sử dụng' và 'không sử dụng'), ví dụ như một bàn và bàn tay, bạn chắc chắn muốn đặt séc vào để đảm bảo mỗi thẻ Thẻ từ bộ có mặt một lần và chỉ một lần.

Rằng bạn thiết kế cái này với "vùng", là một lựa chọn tùy ý. Tùy thuộc vào việc thực hiện (một khu vực chỉ có thể là một bàn tay, một sàn hoặc một bảng trong ví dụ trên) nó rất có thể là một thiết kế kỹ lưỡng.

Tuy nhiên, việc triển khai đó có vẻ giống như một loại dẫn xuất của một Collection<Card>bộ thẻ giống hơn , với API ít hạn chế hơn. Ví dụ: khi bạn muốn xây dựng một máy tính giá trị tay hoặc AI, bạn chắc chắn muốn được tự do lựa chọn và số lượng mỗi thẻ bạn lặp đi lặp lại.

Vì vậy, thật tốt khi trưng ra một API hạn chế như vậy, nếu mục tiêu duy nhất của API đó là đảm bảo mỗi thẻ luôn nằm trong một vùng.