Có quá nhiều lớp như vậy không?

Question

Khi bạn đang phát triển, khi nào bạn có thể xác định xem bạn có nhiều lớp không cần thiết trong ứng dụng của mình? Có giới hạn nhất định về số lượng lớp học bạn nên có không?

Answer 1

Có thực sự không phải là một điều như "quá nhiều lớp học". Điều có thể là một vấn đề là "quá nhiều lớp học làm cùng một điều."

Nếu bạn cảm thấy rằng bạn có quá nhiều lớp trong cơ sở mã, một cách hay để kiểm tra đó là thêm một số yêu cầu mới. Bất kỳ điều gì buộc bạn phải thực hiện một số thay đổi đối với mã. (Trong một nhánh riêng biệt của kiểm soát nguồn, tất nhiên.) Làm thế nào khó khăn để thực hiện những thay đổi đó? Thay đổi tương đối đơn giản có yêu cầu bạn sửa đổi tấn và tấn lớp học không? Nếu đó là trường hợp thì có một cơ hội rất tốt mà bạn có quá nhiều, nhưng vấn đề không phải là số chính nó.

Chủ yếu là vấn đề sở thích cá nhân trong nhiều trường hợp. Thường có một sự cân bằng giữa việc sử dụng lại mã và mã de-coupling. Bằng cách tách ra mọi mối quan tâm có thể và có rất nhiều lớp học nhỏ, bạn bỏ mọi thứ khỏi mọi thứ khác. Tuy nhiên, bạn thường thấy rằng bạn phải lặp lại mã trong các trường hợp như vậy bởi vì rất nhiều mã có thể đang làm "điều tương tự" nhưng vì một lý do hơi khác nhau. Mặt khác, nếu bạn khăng khăng không bao giờ lặp lại bất kỳ thứ gì trong mã, thì khi bạn nhận được ít lớp hơn, bạn cũng thường kết thúc với nhiều khớp nối hơn vì một lớp đơn sẽ có nhiều trách nhiệm đối với bất kỳ mã nào yêu cầu chức năng tương tự.

Điểm mấu chốt trong hầu hết các trường hợp là khả năng chống thay đổi. Khớp nối và tái sử dụng là một cái gì đó mọi người có thể tranh luận về chiều dài, nhưng độ cứng phần mềm là nơi mà các đối số biến thành nỗ lực thực tế (tiền). Kiểm tra độ khó của việc thay đổi mã. Sau đó, cố gắng sắp xếp lại các lớp/logic của bạn theo cách bạn nghĩ sẽ chấp nhận thay đổi và kiểm tra lại. Đã có một cải tiến đáng kể?

Answer 2

Tất cả đều phụ thuộc vào dự án của bạn. nó phụ thuộc vào yêu cầu của bạn.
các lớp học phải tối thiểu theo cách thức, không có lớp học không mong muốn
lớp học phải tối đa theo nghĩa là tất cả chúng đều có các thuộc tính riêng biệt.

Answer 3

Nói chung rất nhiều lớp học có nghĩa là bạn có thể đã giải quyết được vấn đề của mình một cách tổng quát. Điều này thường tốt vì nó có nghĩa là bạn hy vọng sẽ có một hành vi thay đổi thời gian dễ dàng hơn khi bạn cần.

Khi phát triển các dự án nhỏ hơn, có thể tốt hơn để cụ thể hơn (tức là ít chung hơn) để đạt được điều nhanh hơn có thể dẫn đến ít lớp hơn, nhưng có thể khó thay đổi hơn khi nhu cầu xuất hiện.

Miễn là các lớp học được sắp xếp tốt và có mục đích được xác định rõ thì không phải là vấn đề khi có nhiều lớp.

Điều gì có thể là vấn đề bao giờ nếu các lớp được kết hợp chặt chẽ hoặc nếu trách nhiệm của một số lớp không được xác định rõ ràng. Thông tin thêm về khớp nối có thể được tìm thấy .

Một vấn đề khác có thể xảy ra trong phần bình luận bên dưới. Nếu nhiều lớp của bạn có mã tương tự, bạn có vấn đề Sao chép. Điều này thường dẫn đến giảm khả năng bảo trì trong hệ thống do nếu cần thay đổi trong mã trùng lặp, bạn phải thực hiện thay đổi nhiều lần. Điều này thường được giải quyết bằng cách thừa kế.

Answer 4

Một ứng dụng tất cả có thể ở trong một tệp mã hoặc mỗi hàm nguyên tử có thể nằm trong tệp riêng của nó, điều duy nhất bị ảnh hưởng là maintainabiliy. Khả năng bảo trì có thể có nghĩa là khả năng điều hướng mã của riêng bạn, hoặc nó có thể có nghĩa là người khác có thể hiểu mã, hoặc nếu có thể xây dựng các bản phát hành mới.

Tôi không nghĩ có bất kỳ hướng dẫn chung nào về điều này luôn áp dụng, điều đó phụ thuộc vào rất nhiều thứ. Ví dụ: khi mã hóa trong JavaScript, bạn thường sử dụng ít tệp (và lớn hơn) chứa nhiều chức năng không liên quan hơn nếu bạn đang mã hóa trong C# hoặc C++.

Nếu bạn đang sử dụng Visual Studio 2012 thì http://msdn.microsoft.com/en-us/library/bb385910.aspx và http://msdn.microsoft.com/en-us/library/dd264939.aspx có thông tin về cách Số liệu mã và Phân tích mã hoạt động.

Đây là ví dụ về báo cáo từ Chỉ số mã trong Visual Studio 2012 dựa trên ứng dụng của riêng tôi, các giá trị được giải thích tại http://msdn.microsoft.com/en-us/library/bb385914.aspx.

Project: <<Projectname>> 
Configuration: Debug 
Scope: Project 
Assembly: <<Path>> 
Maintainability Index: 84 
Cyclomatic Complexity: 479 
Depth of Inheritance: 8 
Class Coupling: 189 
Lines of Code: 903 

Answer 5

Tôi nghĩ điều đó phụ thuộc vào khu vực nào có số lượng lớp học lớn. Nếu có nhiều lớp tĩnh chứa logic nghiệp vụ chung, điều này sẽ được coi là xấu vì các lớp tĩnh nên chỉ được sử dụng cho các phương thức trợ giúp chung. Các lớp tĩnh không bao giờ chứa logic nghiệp vụ chung.

Nếu có các lớp khác nhau cho các lớp khác nhau để lưu giữ cùng một dữ liệu giống nhau. Điều này sẽ được coi là xấu vì các lớp DTO không được nhân đôi trên các lớp.

Tuy nhiên, nếu các lớp học đã được tạo sau khi phân tách đúng các yêu cầu, thì tôi nghĩ thực sự tốt khi có số lượng lớp học lớn.

Answer 6

Như nhiều người khác đã gợi ý, "nó phụ thuộc ..."

Thông thường nó phụ thuộc vào sự kết hợp các phương pháp, mục tiêu của bạn và sở thích và khả năng của thành viên trong nhóm của bạn. Nếu bạn đang rất nghiêm ngặt về các bài kiểm tra đơn vị, bạn có thể kết thúc với rất nhiều lớp học nhỏ, chung và tiêm phụ thuộc. Điều này cũng có nghĩa là rất khó cho các thành viên trong nhóm xem toàn bộ bê tông mà bạn đang xây dựng từ tất cả các bộ phận rất, rất chung chung. Cá nhân tôi thích nghĩ về API được xây dựng trên hai cấp độ: Cấp độ thấp hơn được làm bằng các bộ phận chung, độc lập và mức độ cao, nơi tôi sử dụng một vài mặt tiền, đạo diễn, v.v ... để trình bày điều gì đó cụ thể và hữu ích cho các lập trình viên khác. Điều này giống như thiết kế của IMHO thư viện iOS.

Answer 7

Trong một dự án tôi hiện đang làm việc trên tôi chắc chắn nghĩ rằng chúng tôi đang sử dụng quá nhiều lớp học - hoặc ít nhất, quá nhiều đối tượng/trường hợp.

Chúng tôi xây dựng một CMS dựa trên PHP/MySQL, nơi mọi bản ghi và trường trong cơ sở dữ liệu được thể hiện như một đối tượng trong PHP. Điều này có thể dẫn đến hàng chục nghìn trường hợp cùng một lúc và chúng tôi liên tục chạy vào các vấn đề hiệu suất/hết bộ nhớ, v.v.

Điều này có thể không phải là vấn đề trong các ngôn ngữ lập trình khác hoặc với các yêu cầu khác , nhưng hiệu suất là, theo ý kiến ​​của tôi, một cái gì đó để xem xét là tốt.

Answer 8

Kent Beck trả lời câu hỏi của bạn. Jeff Langr trong cuốn sách 'Clean Code A Handbook of Agile Software Craftsmanship' thảo luận về bốn quy tắc thiết kế theo quy định của Kent Beck.

(theo thứ tự quan trọng)

1. Chạy tất cả các bài kiểm tra
2. Không chứa trùng lặp
3. bày tỏ ý định của các lập trình viên
4. Giảm thiểu số lượng các lớp học và phương pháp

Kent gợi ý rằng cách tiếp cận thực dụng được áp dụng cho k eep lớp và phương thức đếm thấp. Ông đưa ra ví dụ về việc tuân theo các quy tắc có tính giáo điều như tất cả các lớp nên có giao diện. Thường thì có nhưng đôi khi có những tình huống mà điều này có thể không cần thiết. Tuy nhiên, quy tắc này là ưu tiên thấp nhất trong bốn quy tắc thiết kế đơn giản.

(lưu ý, đây là Kent Becks ý kiến, không quá nhiều tôi!)

Answer 9

triết học:

Có một điều như vậy là quá nhiều bất cứ điều gì. Bạn có thể có quá nhiều lớp và quá ít. Một số người muốn giả vờ rằng nhiều hơn là miễn phí bởi vì họ có thể sử dụng các công cụ như tìm kiếm như một cái cớ để tạo ra một quá lộn xộn, khó điều hướng và không gian tìm kiếm lớn. Về lâu dài bạn sẽ luôn luôn tìm thấy một thâm hụt đo lường được.

Tôi không thực sự chắc chắn có giới hạn trên về số lượng lớp học bạn có thể có. Bạn có thể tìm cách để kính thiên văn mọi thứ thêm lớp học vô thời hạn, kỹ thuật nói, vô hạn. Nếu bạn không thể có quá nhiều lớp nhưng bạn có thể thêm chúng vô hạn thì bạn sẽ không bao giờ hoàn thành chương trình của bạn về số lượng lớp bạn muốn có, do đó bạn có thể có quá nhiều lớp.

Một số IDE giúp dễ dàng tạo nhiều lớp và kết nối chúng với nhau bằng những thứ như tạo bản mẫu, tự động hoàn thành và luôn có copypasta. Nhiều công cụ làm giảm chi phí tạo ra những gì cơ bản thường là mã vô dụng nhưng không làm giảm chi phí của sưng lên nhiều. Ngay cả với những người giúp việc, mã không được yêu cầu sẽ luôn luôn làm việc ra rẻ hơn so với cồng kềnh (bạn chỉ có thể giảm thuế, không loại bỏ nó). Nếu bạn không quan tâm về nó, nó cuối cùng sẽ trở thành một vấn đề. Ngay cả khi bạn có những thứ như quét mã, phạt tiền và thay thế trong tập tin, vv sau đó mười lần nữa vẫn còn nhiều hơn mười lần. Nó có nghĩa là mười lần nhiều hơn để thay đổi, mười lần nhiều hơn để đi sai và một phần mười của số tiền của nỗ lực chi tiêu cho mỗi dòng.

Nhiều người rơi vào cái bẫy nghĩ rằng họ đang giảm độ phức tạp bằng cách thêm nhiều lớp học hơn. Trong thực tế, họ có xu hướng chỉ đơn giản là phá vỡ sự phức tạp lên, di chuyển mọi thứ ra khỏi những điều họ có liên quan đến và thêm các lớp phức tạp trong các hình thức của indirection. Mã tuyến tính trở thành,

phi tuyến tính không cần thiết (đó là ví dụ về quá nhiều đoạn văn, mặc dù công bằng là một ví dụ tốt hơn có thể là một đoạn cho mỗi câu hoặc từ là quá nhiều, khi đoạn văn của bạn trở thành câu thì bạn don ' t thực sự có hai điều riêng biệt nữa, đó có thể là bằng chứng của hai đoạn văn, khi các câu dừng lại là một điều khác với đoạn văn).

Detection:

Cách đơn giản để xem xét điều này là nếu bạn có con đường A (nút duy nhất/một hàm/lớp/etc) nhưng chia nó ra thành A-> B bạn không thực sự đạt được bất cứ điều gì. Bạn chỉ cần lấy một tờ giấy, xé nó thành hai, đặt nó vào hai phong bì và sau đó đưa nó đến đích của nó. Nếu nó chỉ ra rằng bạn thực sự thực sự cần một nút với nhiều hơn một cạnh sau đó bạn đạt được một cái gì đó. Đó sẽ là A-> B, A-> C chẳng hạn.Bạn có thể sử dụng phân tích biểu đồ để tìm ra quá nhiều đối tượng. Nếu bạn có danh sách liên kết dài hoặc nhiều danh sách được liên kết nhỏ (hoặc thậm chí là một số ít) thì bạn có thể nói rằng bạn có quá nhiều lớp. Không phải tất cả các dạng dư thừa đối tượng đều dễ phát hiện. Với quá nhiều lớp bảo trì trở nên quá phức tạp khi bạn kết thúc hỗ trợ một mức độ linh hoạt và một mô hình mà chỉ một phần nhỏ bạn chỉ sử dụng. Nó có nghĩa là rất nhiều mã của bạn không thực sự tương ứng với những gì cần phải được thực hiện. Điều này một mình làm cho nó khó khăn để duy trì như là mục tiêu của mã đó là chủ quan hơn là khách quan, nó cũng có thể được tùy ý.

Bạn có thể lấy mã số và giảm số lượng lớp học cho đến khi bạn chỉ có những lớp thực sự cần thiết. Điều này có nghĩa là chỉ những thứ cần thiết cho tính di động (chuyển dữ liệu xung quanh), chênh lệch về cách thức hoạt động (chuyển các phương thức xung quanh) và khi cần thiết để tách biệt hợp lý (xử lý các khái niệm chính độc lập như kiên trì, thuyết trình, vv) và khi cần. Khi không thể làm việc với một thiết kế tốt, nhiều lập trình viên sẽ làm ngược lại, viết mã và chỉ tách nó ra khi cần thiết để phục vụ một mục đích cụ thể theo yêu cầu.

Mặc dù có thể đo lường, không có thước đo chính xác quá nhiều lớp cũng không phải là dấu hiệu hoàn hảo. Chỉ có gợi ý. Một tỷ lệ lớn giữa số lượng tối thiểu của các lớp cần thiết và tối đa ví dụ là một gợi ý. Điều gì là lớn? Tôi sẽ nói 100 lần chắc chắn là nghi ngờ, 10 lần khá nghi ngờ, 5 lần một chút nghi ngờ. Điều này có thể thay đổi mặc dù dựa trên một số tham số.

Một biện pháp kỳ lạ là gzip mã của bạn. Tỷ lệ nén càng tốt thì cơ hội sưng lên càng lớn. Đây không phải là một biện pháp hoàn hảo mặc dù vì nó cần điểm tham chiếu. Một số cách để giảm tỷ lệ nén cũng có thể không hiệu quả, mã hóa cho một số cụ thể một cách ngây thơ sẽ không bao giờ hoạt động.

Bạn có thể biết nếu bạn có nhiều lớp học (hoặc giao diện) nếu họ làm cho bạn làm việc không thực sự giúp bạn đạt được mục tiêu cuối cùng của bạn hoặc nếu họ làm chậm bạn nhiều hơn họ đang đẩy nhanh mọi thứ lên. Đây có thể là chủ quan mặc dù. Nếu ai đó đã tạo quá nhiều lớp học, điều đó có nghĩa là họ sẽ phải thay đổi thói quen của họ, điều đó có nghĩa là thường có một khoản phí nhập cảnh cho các phương pháp tiếp cận mã hóa tốt hơn. Vào lúc bắt đầu của một dự án, rất khó để phát hiện khi thêm mã thường rất rẻ. Không có gì phụ thuộc vào nó rất nhiều, các lớp là nông cạn, vv Nó không phải ít nhất cho đến nhiều tháng hoặc thậm chí một năm vào một dự án mà sưng lên, tổ chức nghèo, vv mà chi phí trở nên rõ ràng. Nó không phải cho đến khi một dự án trở nên thực tế bế tắc mà mọi người chú ý. Nhiều người sẽ không biết nếu một cái gì đó mất một năm nên đã thực sự mất một năm hoặc sáu tháng. Có rất ít điểm so sánh.

Nếu bạn xem các lớp học, bạn có thể chọn một số thứ. Bao nhiêu mã là OO và có bao nhiêu là FO (định hướng đối tượng so với Định hướng chức năng)?

Chức năng Định hướng có nghĩa là mã thực sự làm điều gì đó và đóng góp trực tiếp vào kết quả cuối cùng. Điều này bao gồm mã cần thiết của bạn. Nó sẽ có khả năng bao gồm các toán tử vượt quá nhiệm vụ và đúc. Thông thường có điều kiện báo cáo, chi nhánh, đọc dữ liệu, lựa chọn một quá trình hành động và tham gia các khóa học hành động thích hợp như tạo dữ liệu, đột biến hoặc lấy/lưu trữ chống lại IO.

Hướng đối tượng có nghĩa đơn giản là đại diện cho các khái niệm sử dụng các lớp. Mã này gần như biến mã thủ tục của bạn thành ngôn ngữ khai báo. Nếu hầu hết các lớp học của bạn chỉ đơn giản là hỗ trợ kiểm tra loại nặng, đại diện, vv thì bạn có thể có quá nhiều. Các dấu hiệu của đó là các lớp và các phương thức với các phần tên của chúng có thể là các biến cho phép bạn thu nhỏ các lớp đó. Một dấu hiệu rất mạnh mẽ của điều này là nếu hầu hết những gì các lớp học đang làm là đấm bốc. Đơn giản chỉ cần gán các biến nhưng không làm được gì nhiều. Điều này thực sự là một trường hợp có quá nhiều cấu trúc và thường thiếu sự trùng lặp, mã hóa động hoặc trừu tượng.

Trong trường hợp hiển nhiên, nếu một lớp không bao giờ được sử dụng thì đó là một lớp quá nhiều (nếu mã chết của nó). Những thứ như lớp học giống hệt nhau nhưng với những cái tên khác nhau cũng là một dấu hiệu tốt.

Nguyên nhân:

Điều này có thể được thúc đẩy bởi một số điều khoản dành riêng từ cơ chế mà làm cho nó rất dễ dàng để tạo và kết nối mọi thứ lại với nhau (mà có xu hướng phá vỡ khi bạn trừu tượng và làm những việc động khuyến khích tránh những thói quen tốt thay thế nhưng phá vỡ IDE). Tôi thường bị mắc kẹt bởi điều này bằng cách cố gắng đại diện cho mọi thứ hoàn toàn hoàn hảo, tuy nhiên OO thực sự không đủ linh hoạt để làm điều này và nó thường trở thành YAGNI. Một vấn đề phổ biến đơn giản là thiếu trừu tượng, nơi bạn thường có sự biến đổi biến thành các cấu trúc ngôn ngữ cấp cao nhất như đã đề cập trước đó (cũng liên kết thành một thiết kế để đưa mọi thứ vào IDE trực tiếp). Điều này có thể không chỉ phản bội việc thiếu mã hóa động mà còn cách sử dụng một bộ tiền xử lý hoặc tương tự. Điều này trông giống như là về cơ bản một cây với tất cả các lá được xác định. Càng nhiều càng tốt với các lớp bạn muốn tránh phải định nghĩa một lớp cho mỗi lá có thể. Một dấu hiệu của việc mở rộng cây được đưa đến cực đoan có thể là nơi bạn có một lớp học cho mọi cách sử dụng có thể của một nguyên thủy. Đây cũng có thể là dấu hiệu của một điều gì đó cực đoan hơn. Sản phẩm Cartesian chưa được kiểm định của tất cả các lớp. Trong trường hợp này bạn không đơn giản có được một lớp học cho một chân nhưng một lớp học cho một CatLeg, DogLeg, vv khi thường không có phương sai thực tế giữa hai. Một số người có thể làm điều này ngoài chủ nghĩa cực đoan của loại kiểm tra để ngăn chặn một người nào đó đặt một DogLeg trên một CatLeg. Đó là một mô hình chống khó chịu và phổ biến.

Một trong những trình điều khiển lớn nhất của quá nhiều lớp học là nỗ lực tuân thủ các tiêu chuẩn từ ngoài đó trong đám mây không thực sự áp dụng cho trường hợp của bạn. Trong trường hợp này, bạn không lập trình để đáp ứng với vấn đề của bạn. Bạn đang lập trình để đáp ứng các vấn đề của người khác.

Điều này rất phổ biến với những thứ như SOLID. Điều rất quan trọng là phải biết và hiểu các nguyên tắc như SOLID, có thể áp dụng chúng nhưng cũng rất quan trọng để biết khi nào không áp dụng chúng.

Nguyên tắc này được sử dụng nhiều khi các ngôn ngữ OOP với các thư viện lớn được giảng dạy. Nếu bạn đang tạo một thư viện OOP mà bạn muốn phân phối cho thế giới, có khả năng hàng triệu người với mọi trường hợp sử dụng có thể tưởng tượng được thì bạn muốn tuân theo các nguyên tắc OOP dẫn đến nhiều thứ phá vỡ thành các giao diện và các lớp để chúng có thể được sử dụng theo nhiều cách khác nhau và do đó một phần chức năng không có cơ hội cao để kéo vào một chức năng khác có thể không cần thiết. Bạn phải xem xét rằng trong thế giới này, bạn không muốn tạo ra các thư viện mà mọi người có thể phải ngã ba. Mọi người không muốn làm điều đó khi họ trở thành người bảo trì mã họ đang sử dụng lại nếu không sẽ mất tổng chi phí sở hữu.

Những nguyên tắc này cũng thêm nhiều địa ngục và nếu codebase của bạn có phạm vi người dùng bị giới hạn, hoàn toàn nằm dưới sự kiểm soát của bạn, v.v. có thể bạn có quá nhiều mã nếu bạn làm như vậy nên "cho mã được phân phối. Ngay cả khi bạn có mã được phân phối, đôi khi nó có thể quá khắc nghiệt để phục vụ cho tất cả các trường hợp sử dụng trước, đôi khi bạn phải tìm ra những gì có thể cần thiết nhất và sau đó mọi thứ khác sẽ thay đổi theo yêu cầu. Đối với một thư viện nhỏ bạn có thể đủ khả năng để đưa vào một địa ngục của rất nhiều công việc phụ. Đối với một cơ sở mã lớn, bạn phải tập luyện nơi mà trên cao sẽ rất có thể trả tiền cho chính nó.

Ví dụ về số lượt truy cập:

Trong một thế giới lý tưởng, bạn mã tối giản và chỉ theo nhu cầu trước mắt của mình. Có một sự thiên vị khi phương pháp này vượt trội hơn trên tài khoản của dư thừa không tự tiết lộ. Thiếu sót. Nếu bạn có quá ít nó sẽ trực tiếp trình bày chính nó. Điều này rất phổ biến khi thấy trong DRY. Sau khi thêm một hàm bạn thêm một hàm khác.Bạn sao chép và dán đầu tiên sau đó thay đổi nửa dưới. Nửa đầu phổ biến của hai chức năng là mã trùng lặp, nó ngay lập tức tự tiết lộ rằng chúng cần được loại bỏ trùng lặp. Bạn làm như vậy bằng cách tạo một hàm thứ ba. Bạn biết đó không phải là một chức năng quá nhiều vì bạn có một lý do có thể chứng minh khách quan để tạo ra nó. Cách tiếp cận này trở nên khó khăn hơn khi viết mã để người khác sử dụng. Bởi những người khác tôi không nhất thiết có nghĩa là bất cứ ai. Tôi có nghĩa là những người không có quyền truy cập trực tiếp vào codebase, thường là người lạ. Về cơ bản những người không thể dễ dàng/nhanh chóng/phá vỡ giá rẻ mã của bạn khi cần thiết. Nếu bạn không phục vụ cho khán giả như vậy, thì bạn không cần phải lo lắng về việc phá vỡ mã của bạn sớm.

Gần đây tôi đã sử dụng thư viện trực tuyến với quá ít lớp học. Nó chứa một lớp duy nhất với nhiều trách nhiệm. Nó sẽ mất một tập tin xử lý (như là một loại nguyên thủy) để viết để sau đó cũng tự động xuất HTTP tiêu đề thích hợp với dòng nó được tạo ra dựa trên các phương pháp được gọi là (chẳng hạn như addImage, addText, vv).

Trong một thế giới lý tưởng, lớp học này không nên đưa ra các giả định về đầu ra. Sử dụng có thể muốn xuất ra hệ thống tệp, bộ nhớ, luồng TCP, v.v. Nó chỉ cần cung cấp một giao diện với một phương thức viết đơn giản hoặc sử dụng một phương thức từ thư viện chuẩn. Trong trường hợp của tôi, tôi chỉ cần có đầu ra thông qua nối chuỗi nhưng để đạt được điều này, tôi phải mở một bản đồ giả dạng tập tin vào bộ nhớ (thông thường không thể nhưng ngôn ngữ cho phép nó như là một hack).

Tôi đã gặp sự cố này một số lần sử dụng thư viện ngẫu nhiên từ tất cả các nguồn. Trong một số trường hợp nó sẽ được rõ ràng, nơi tách nên được áp dụng và đôi khi nó không. Nếu nghi ngờ, quá ít vẫn còn đánh bại quá nhiều vì bạn được đảm bảo để tìm hiểu về nó cuối cùng. Tôi có xu hướng quan sát rằng nếu bạn thêm bất cứ điều gì bạn không thực sự chắc chắn về bạn sẽ kết thúc trong lãnh thổ sưng lên đáng kể. Nếu bạn làm điều đó một lần bạn có thể sẽ làm điều đó hai lần và sau đó trở thành một thói quen.