Có bất kỳ nhược điểm đáng kể nào phụ thuộc vào sự trừu tượng?

Tôi đã đọc wiki này về Nguyên tắc Trừu tượng Ổn định (SAP) .

SAP tuyên bố rằng gói càng ổn định thì càng trừu tượng. Điều này ngụ ý rằng nếu một gói kém ổn định hơn (có nhiều khả năng thay đổi) thì nó sẽ cụ thể hơn. Điều tôi không thực sự hiểu là tại sao điều này nên xảy ra. Chắc chắn trong mọi trường hợp bất kể sự ổn định, chúng ta nên phụ thuộc vào sự trừu tượng và che giấu việc thực hiện cụ thể?

Hãy suy nghĩ về các gói của bạn như là một API, lấy ví dụ từ giấy, hãy định nghĩa về Readervới string Reader.Read()và Writervới void Writer.Write(string)như API trừu tượng của bạn.

Sau đó, bạn có thể tạo một lớp Copyvới một phương thức Copier.Copy(Reader, Writer)và việc thực hiện Writer.Write(Reader.Read())và có thể một số kiểm tra độ tỉnh táo.

Bây giờ, bạn thực hiện triển khai cụ thể, ví dụ như FileReader, FileWriter, KeyboardReadervà DownloadThingsFromTheInternetReader.

Điều gì nếu bạn muốn thay đổi việc thực hiện của bạn FileReader? Không có vấn đề, chỉ cần thay đổi lớp và biên dịch lại.

Điều gì nếu bạn muốn thay đổi định nghĩa về sự trừu tượng của bạn Reader? Rất tiếc, bạn không thể chỉ thay đổi điều đó, nhưng bạn cũng sẽ phải thay đổi Copier, FileReader, KeyboardReadervà DownloadThingsFromTheInternetReader.

Đây là lý do đằng sau Nguyên tắc trừu tượng ổn định: Làm cho việc cụ thể hóa của bạn kém ổn định hơn so với trừu tượng.

Vì YAGNI .

Nếu bạn hiện chỉ có một cách thực hiện một điều , tại sao phải bận tâm với một lớp bổ sung và vô dụng? Nó sẽ chỉ dẫn đến sự phức tạp không cần thiết. Thậm chí tệ hơn, đôi khi bạn cung cấp một suy nghĩ trừu tượng cho đến ngày việc thực hiện thứ hai sẽ đến ... và ngày này không bao giờ xảy ra. Thật là một sự lãng phí công việc!

Tôi cũng nghĩ rằng câu hỏi thực sự cần đặt ra không phải là "Tôi có cần phải phụ thuộc vào sự trừu tượng không?" mà là "Tôi có cần mô đun hóa không?". Và mô-đun không phải lúc nào cũng cần thiết, xem bên dưới.

Trong công ty tôi đang làm việc, một số phần mềm tôi phát triển gắn chặt với một số thiết bị phần cứng mà nó phải giao tiếp. Các thiết bị này được phát triển để thực hiện các mục tiêu rất cụ thể và là tất cả mọi thứ trừ mô-đun. :-) Khi thiết bị được sản xuất đầu tiên đi ra khỏi nhà máy và được cài đặt ở đâu đó, cả firmware và phần cứng của nó có thể không bao giờ thay đổi, bao giờ hết .

Vì vậy, tôi có thể chắc chắn rằng một số phần của phần mềm sẽ không bao giờ phát triển. Các phần này không cần phụ thuộc vào trừu tượng vì nó chỉ tồn tại một lần thực hiện và phần này sẽ không bao giờ thay đổi. Khai báo trừu tượng trên các phần mã này sẽ chỉ gây nhầm lẫn cho mọi người và mất nhiều thời gian hơn (mà không tạo ra bất kỳ giá trị nào).

Tôi nghĩ có lẽ bạn đang bối rối bởi từ ổn định được chọn bởi Robert Martin. Đây là nơi tôi nghĩ rằng sự nhầm lẫn bắt đầu:

Điều này ngụ ý rằng nếu một gói kém ổn định hơn (có nhiều khả năng thay đổi) thì nó sẽ cụ thể hơn.

Nếu bạn đọc qua bài viết gốc , bạn sẽ thấy (nhấn mạnh của tôi):

Định nghĩa cổ điển về sự ổn định của từ là: Không dễ dàng di chuyển. Đây là định nghĩa mà chúng tôi sẽ sử dụng trong bài viết này. Đó là, sự ổn định không phải là thước đo khả năng mô-đun sẽ thay đổi; đúng hơn nó là thước đo cho sự khó khăn trong việc thay đổi một mô-đun .

Rõ ràng, các mô-đun khó thay đổi hơn, sẽ ít biến động hơn. Mô-đun càng khó thay đổi, tức là càng ổn định, nó sẽ càng ít biến động.

Tôi luôn phải vật lộn với sự lựa chọn từ ổn định của tác giả , vì tôi (như bạn) có xu hướng nghĩ về khía cạnh "khả năng" của sự ổn định, nghĩa là không có khả năng thay đổi . Khó khăn ngụ ý rằng việc thay đổi mô-đun đó sẽ phá vỡ rất nhiều mô-đun khác và sẽ rất nhiều công việc để sửa mã.

Martin cũng sử dụng các từ độc lập và có trách nhiệm , mà theo tôi truyền đạt nhiều ý nghĩa hơn. Trong hội thảo đào tạo của mình, ông đã sử dụng một phép ẩn dụ về cha mẹ của những đứa trẻ lớn lên và cách chúng nên "có trách nhiệm", vì con cái của chúng phụ thuộc vào chúng. Ly hôn, thất nghiệp, giam giữ, v.v. là những ví dụ thực tế tuyệt vời về tác động tiêu cực mà sự thay đổi của cha mẹ sẽ gây ra cho con cái. Vì vậy, cha mẹ nên "ổn định" vì lợi ích của con cái họ. Nhân tiện, phép ẩn dụ này của trẻ em / cha mẹ không nhất thiết liên quan đến thừa kế trong OOP!

Vì vậy, theo tinh thần "có trách nhiệm", tôi đã đưa ra ý nghĩa thay thế cho việc khó thay đổi (hoặc không nên thay đổi ):

• Nghĩa vụ - có nghĩa là các lớp khác phụ thuộc vào lớp này vì vậy nó không nên thay đổi.
• Này - ibid.
• Ràng buộc - nghĩa vụ của lớp này giới hạn cơ sở của nó trong việc thay đổi.

Vì vậy, cắm các định nghĩa này vào tuyên bố

gói càng ổn định thì càng trừu tượng

• gói càng bắt buộc thì càng trừu tượng
• càng chịu ơn một gói các trừu tượng hơn nó phải được
• gói càng bị ràng buộc thì càng trừu tượng

Hãy trích dẫn Nguyên tắc trừu tượng ổn định (SAP), nhấn mạnh các từ khó hiểu ổn định / không ổn định:

Các gói ổn định tối đa nên trừu tượng tối đa. Gói không ổn định nên được bê tông. Tính trừu tượng của một gói nên tỷ lệ thuận với tính ổn định của nó .

Làm rõ nó mà không có những từ khó hiểu:

Các gói được tối đa hóa đến các phần khác của hệ thống nên được trừu tượng hóa tối đa. Các gói có thể thay đổi mà không gặp khó khăn nên được cụ thể. Tính trừu tượng của một gói nên tỷ lệ thuận với mức độ khó sửa đổi .

TL; DR

Tiêu đề của câu hỏi của bạn hỏi:

Có bất kỳ nhược điểm đáng kể nào phụ thuộc vào sự trừu tượng?

Tôi nghĩ rằng nếu bạn tạo ra sự trừu tượng đúng cách (ví dụ: chúng tồn tại bởi vì rất nhiều mã phụ thuộc vào chúng), thì sẽ không có bất kỳ nhược điểm đáng kể nào.

Điều này ngụ ý rằng nếu một gói kém ổn định hơn (có nhiều khả năng thay đổi) thì nó sẽ cụ thể hơn. Những gì tôi không thực sự hiểu là tại sao điều này nên là trường hợp.

Trừu tượng là những thứ khó thay đổi trong phần mềm vì mọi thứ đều phụ thuộc vào chúng. Nếu gói của bạn sẽ thay đổi thường xuyên và nó cung cấp sự trừu tượng, những người phụ thuộc vào nó sẽ bị buộc phải viết lại một bó lớn mã của họ khi bạn thay đổi thứ gì đó. Nhưng nếu gói không ổn định của bạn cung cấp một số triển khai cụ thể, mã ít hơn nhiều sẽ phải được viết lại sau khi thay đổi.

Vì vậy, nếu gói của bạn sẽ thay đổi thường xuyên, tốt hơn nên cung cấp bê tông hóa, không trừu tượng hóa. Nếu không ... ai sẽ sử dụng nó? ;)

Hãy ghi nhớ số liệu ổn định của Martin và ý nghĩa của "tính ổn định":

Instability = Ce / (Ca+Ce)

Hoặc là:

Instability = Outgoing / (Incoming+Outgoing)

Đó là, một gói được coi là hoàn toàn không ổn định nếu tất cả các phụ thuộc của nó là đi: nó sử dụng những thứ khác, nhưng không có gì sử dụng nó. Trong trường hợp đó, nó chỉ có ý nghĩa cho điều đó là cụ thể. Đây cũng sẽ là loại mã dễ thay đổi nhất vì không có gì khác sử dụng nó, và do đó không có gì khác có thể phá vỡ nếu mã đó được sửa đổi.

Trong khi đó, khi bạn có kịch bản ngược lại về sự "ổn định" hoàn toàn với một gói được sử dụng bởi một hoặc nhiều thứ nhưng nó không sử dụng bất cứ thứ gì, như gói trung tâm được sử dụng bởi phần mềm, đó là khi Martin nói điều này nên trừu tượng. Điều đó cũng được củng cố bởi phần DIP của SOLI (D), Nguyên tắc đảo ngược phụ thuộc, về cơ bản nói rằng các phụ thuộc phải thống nhất chảy theo hướng trừu tượng cho cả mã cấp thấp và cấp cao.

Đó là, các phụ thuộc phải thống nhất theo hướng "ổn định", và chính xác hơn, các phụ thuộc sẽ chảy vào các gói có nhiều phụ thuộc đến hơn phụ thuộc đi và hơn nữa, các phụ thuộc sẽ chảy theo trừu tượng. Điểm chính của lý do đằng sau đó là sự trừu tượng cung cấp phòng thở để thay thế một kiểu con cho một kiểu con khác, mang lại mức độ linh hoạt cho các bộ phận cụ thể thực hiện giao diện để thay đổi mà không phá vỡ các phụ thuộc đến giao diện trừu tượng đó.

Có bất kỳ nhược điểm đáng kể nào phụ thuộc vào sự trừu tượng?

Chà, tôi thực sự không đồng ý với Martin ở đây cho tên miền của tôi ít nhất, và ở đây tôi cần đưa ra một định nghĩa mới về "sự ổn định" như trong "thiếu lý do để thay đổi". Trong trường hợp đó tôi sẽ nói rằng các phụ thuộc sẽ chuyển sang ổn định, nhưng các giao diện trừu tượng không giúp ích gì nếu các giao diện trừu tượng không ổn định (theo định nghĩa của tôi về "không ổn định", như dễ bị thay đổi nhiều lần, không phải của Martin). Nếu các nhà phát triển không thể sửa lỗi trừu tượng và khách hàng liên tục thay đổi ý định theo cách khiến các nỗ lực trừu tượng mô hình hóa phần mềm không hoàn chỉnh hoặc không hiệu quả, thì chúng tôi không còn được hưởng lợi từ tính linh hoạt nâng cao của giao diện trừu tượng để bảo vệ hệ thống chống lại các thay đổi phá vỡ phụ thuộc theo tầng. . Trong trường hợp cá nhân của tôi, tôi đã tìm thấy các công cụ ECS, chẳng hạn như các công cụ được tìm thấy trong các trò chơi AAA,cụ thể nhất : hướng tới dữ liệu thô, nhưng dữ liệu đó rất ổn định (như trong "không bao giờ cần phải thay đổi"). Tôi thường thấy xác suất của một cái gì đó đòi hỏi những thay đổi trong tương lai là một số liệu hữu ích hơn so với tỷ lệ của hiệu ứng trên tổng số khớp nối trong các quyết định SE hướng dẫn.

Vì vậy, tôi sẽ thay đổi DIP một chút và chỉ nói, "các phụ thuộc sẽ chảy vào các thành phần có xác suất yêu cầu thay đổi thấp nhất", bất kể các thành phần đó là giao diện trừu tượng hay dữ liệu thô. Tất cả những gì quan trọng với tôi là xác suất mà họ có thể yêu cầu thay đổi thiết kế trực tiếp. Trừu tượng chỉ hữu ích trong bối cảnh ổn định này nếu một cái gì đó, bằng cách trừu tượng, làm giảm xác suất đó.

Đối với nhiều bối cảnh có thể là trường hợp với các kỹ sư và khách hàng tử tế, những người dự đoán được nhu cầu của phần mềm trả trước và thiết kế trừu tượng (như không thay đổi), trong khi những tóm tắt đó cung cấp cho họ tất cả các phòng thở mà họ cần để trao đổi các triển khai cụ thể. Nhưng trong một số lĩnh vực, các tóm tắt có thể không ổn định và dễ bị thiếu, trong khi dữ liệu cần thiết của động cơ có thể dễ dàng hơn nhiều để dự đoán và ổn định trước. Vì vậy, trong những trường hợp đó, nó thực sự có thể có lợi hơn từ quan điểm duy trì (dễ dàng thay đổi và mở rộng hệ thống) cho các phụ thuộc để chuyển sang dữ liệu thay vì trừu tượng hóa. Trong ECS, các bộ phận không ổn định nhất (như trong các bộ phận thường xuyên thay đổi nhất) thường là chức năng cư trú trong các hệ thống (PhysicsSystem, ví dụ), trong khi các phần ổn định nhất (ít có khả năng thay đổi nhất) là các thành phần chỉ bao gồm dữ liệu thô ( MotionComponentví dụ) mà tất cả các hệ thống sử dụng.