Làm thế nào tôi có thể nói phần mềm của tôi có quá nhiều sự trừu tượng và quá nhiều mẫu thiết kế, hoặc ngược lại, làm thế nào để tôi biết nếu nó nên có nhiều hơn nữa?

Các nhà phát triển tôi làm việc cùng đang lập trình khác nhau về các điểm này.

Một số làm trừu tượng mọi chức năng nhỏ, sử dụng các mẫu thiết kế bất cứ khi nào có thể và tránh dư thừa bằng bất cứ giá nào.

Những người khác, bao gồm cả tôi, cố gắng thực dụng hơn và viết mã không phù hợp hoàn hảo với mọi mẫu thiết kế, nhưng là cách nhanh hơn để hiểu vì ít áp dụng trừu tượng hơn.

Tôi biết đây là một sự đánh đổi. Làm thế nào tôi có thể biết khi nào có đủ sự trừu tượng hóa trong dự án và làm thế nào để tôi biết nó cần nhiều hơn?

Ví dụ, khi một lớp bộ đệm chung được viết bằng Memcache. Chúng ta có thực sự cần Memcache, MemcacheAdapter, MemcacheInterface, AbstractCache, CacheFactory, CacheConnector, ... hoặc là này dễ dàng hơn để duy trì và vẫn đang tốt khi sử dụng chỉ một nửa trong số những lớp học?

Tìm thấy điều này trong Twitter:

( https://twitter.com/rawkode/status/875318003306565633 )

Có bao nhiêu thành phần cần thiết cho một bữa ăn? Bạn cần bao nhiêu bộ phận để chế tạo một chiếc xe?

Bạn biết rằng bạn có quá ít sự trừu tượng khi một chút thay đổi triển khai dẫn đến một loạt các thay đổi trên toàn bộ mã của bạn. Các tóm tắt thích hợp sẽ giúp cách ly phần mã cần thay đổi.

Bạn biết rằng bạn có quá nhiều sự trừu tượng khi một chút thay đổi giao diện dẫn đến một loạt các thay đổi trên toàn bộ mã của bạn, ở các cấp độ khác nhau. Thay vì thay đổi giao diện giữa hai lớp, bạn thấy mình sửa đổi hàng tá lớp và giao diện chỉ để thêm một thuộc tính hoặc thay đổi một loại đối số phương thức.

Bên cạnh đó, thực sự không có cách nào để trả lời câu hỏi bằng cách đưa ra một con số. Số lượng trừu tượng sẽ không giống nhau từ dự án này sang dự án khác, từ ngôn ngữ này sang ngôn ngữ khác và thậm chí từ nhà phát triển này sang nhà phát triển khác.

Vấn đề với các mẫu thiết kế có thể được tóm tắt bằng câu tục ngữ "khi bạn cầm búa, mọi thứ trông giống như một cái đinh". Hành động áp dụng một mẫu thiết kế không cải thiện chương trình của bạn. Trên thực tế, tôi sẽ lập luận rằng bạn đang thực hiện một chương trình phức tạp hơn nếu bạn thêm một mẫu thiết kế. Câu hỏi vẫn là liệu bạn có sử dụng tốt mẫu thiết kế hay không và đây là trọng tâm của câu hỏi, "Khi nào chúng ta có quá nhiều sự trừu tượng?"

Nếu bạn đang tạo một giao diện và một siêu lớp trừu tượng cho một lần triển khai, bạn đã thêm hai thành phần bổ sung vào dự án của mình là không cần thiết và không cần thiết. Điểm của việc cung cấp một giao diện là có thể xử lý nó như nhau trong suốt chương trình của bạn mà không cần biết nó hoạt động như thế nào. Quan điểm của một siêu lớp trừu tượng là cung cấp hành vi cơ bản cho việc triển khai. Nếu bạn chỉ có một triển khai, bạn sẽ nhận được tất cả các giao diện phức tạp và các lớp kiêng cung cấp và không có lợi thế nào.

Tương tự, nếu bạn đang sử dụng mẫu Factory và bạn thấy mình đang tạo một lớp để sử dụng chức năng chỉ có trong siêu hạng, mẫu Factory không thêm bất kỳ lợi thế nào vào mã của bạn. Bạn chỉ thêm một lớp bổ sung cho dự án của bạn có thể tránh được.

TL; DR Quan điểm của tôi là mục tiêu trừu tượng không phải là trừu tượng trong chính nó. Nó phục vụ một mục đích rất thiết thực trong chương trình của bạn và trước khi bạn quyết định sử dụng mẫu thiết kế hoặc tạo giao diện, bạn nên tự hỏi nếu làm như vậy, chương trình sẽ dễ hiểu hơn mặc dù độ phức tạp bổ sung hoặc chương trình mạnh mẽ hơn mặc dù sự phức tạp bổ sung (tốt nhất là cả hai). Nếu câu trả lời là không hoặc có thể, thì hãy dành vài phút để xem xét lý do tại sao bạn muốn làm điều đó và nếu có thể nó có thể được thực hiện theo cách tốt hơn thay vào đó mà không nhất thiết phải thêm sự trừu tượng vào mã của bạn.

TL: DR;

Tôi không nghĩ rằng có một số mức độ trừu tượng "cần thiết" bên dưới mà có quá ít hoặc trên mức có quá nhiều. Như trong thiết kế đồ họa, thiết kế OOP tốt nên vô hình và nên được coi là điều hiển nhiên. Thiết kế xấu luôn dính ra như ngón tay cái đau.

Câu trả lời dài

Hầu hết có lẽ bạn sẽ không bao giờ biết bạn đang xây dựng bao nhiêu mức độ trừu tượng.

Hầu hết các mức độ trừu tượng là vô hình đối với chúng tôi và chúng tôi coi chúng là điều hiển nhiên.

Lý do đó dẫn tôi đến kết luận này:

Một trong những mục đích chính của sự trừu tượng là tiết kiệm cho lập trình viên sự cần thiết phải có tất cả các hoạt động của hệ thống trong tâm trí mọi lúc. Nếu thiết kế buộc bạn phải biết quá nhiều về hệ thống để thêm một cái gì đó thì có lẽ có quá ít sự trừu tượng. Tôi nghĩ rằng sự trừu tượng xấu (thiết kế kém, thiết kế thiếu máu hoặc kỹ thuật quá mức) cũng có thể buộc bạn phải biết quá nhiều để thêm một cái gì đó. Trong một thái cực, chúng ta có một thiết kế dựa trên một lớp thần hoặc một nhóm DTO, ở một thái cực khác, chúng ta có một số khung OR / kiên trì khiến bạn phải nhảy qua những vòng đua không thể đếm được để đạt được một thế giới xin chào. Cả hai trường hợp buộc bạn quá biết quá nhiều.

Sự trừu tượng xấu tuân theo tiếng chuông Gauss trong thực tế là một khi bạn đi qua một điểm ngọt ngào bắt đầu cản trở. Sự trừu tượng tốt, mặt khác, là vô hình và không thể có quá nhiều bởi vì bạn không nhận thấy nó ở đó. Hãy nghĩ xem có bao nhiêu lớp trên các lớp API, giao thức mạng, thư viện, thư viện hệ điều hành, hệ thống tệp, lớp harware, v.v. ứng dụng của bạn được xây dựng dựa trên và được cấp.

Mục đích chính khác của sự trừu tượng là sự ngăn cách, do đó, các lỗi không thấm qua một khu vực nhất định, không giống như thân tàu đôi và các bể riêng biệt ngăn không cho tàu bị ngập hoàn toàn khi một phần của thân tàu có lỗ. Nếu sửa đổi mã cuối cùng tạo ra lỗi trong các khu vực dường như không liên quan thì có thể có quá ít sự trừu tượng.

Các mẫu thiết kế đơn giản là giải pháp phổ biến cho các vấn đề. Điều quan trọng là phải biết các mẫu thiết kế, nhưng chúng chỉ là triệu chứng của mã được thiết kế tốt (mã tốt vẫn có thể bị vô hiệu hóa trong nhóm các mẫu thiết kế của bốn nhóm ), không phải là nguyên nhân.

Trừu tượng giống như hàng rào. Chúng giúp tách các vùng trong chương trình của bạn thành các phần có thể kiểm tra và có thể hoán đổi cho nhau (yêu cầu để tạo mã không cứng không dễ vỡ). Và rất giống hàng rào:

• Bạn muốn trừu tượng tại các điểm giao diện tự nhiên để giảm thiểu kích thước của chúng.

• Bạn không muốn thay đổi chúng.

• Bạn muốn họ tách những thứ có thể độc lập.

• Có một cái ở sai vị trí còn tệ hơn là không có nó.

• Họ không nên có rò rỉ lớn .

Tái cấu trúc

Tôi đã không thấy từ "tái cấu trúc" được đề cập ngay cả cho đến nay. Vì vậy, ở đây chúng tôi đi:

Hãy thoải mái thực hiện một tính năng mới trực tiếp nhất có thể. Nếu bạn chỉ có một lớp đơn giản, đơn giản, bạn có thể không cần giao diện, siêu lớp, nhà máy, v.v.

Nếu và khi bạn nhận thấy rằng bạn mở rộng lớp theo cách nó phát triển quá béo, thì đó là lúc để tách nó ra. Vào thời điểm đó, thật tuyệt vời khi nghĩ về cách bạn thực sự nên làm điều đó.

Mô hình là một công cụ tâm trí

Các mẫu, hay cụ thể hơn là cuốn sách "Các mẫu thiết kế" của nhóm bốn người, rất hay, trong số những lý do khác, vì họ xây dựng một ngôn ngữ để các nhà phát triển suy nghĩ và nói chuyện. Thật dễ dàng để nói "người quan sát", "nhà máy" hoặc "Mặt tiền" và mọi người đều biết chính xác ý nghĩa của nó, ngay lập tức.

Vì vậy, ý kiến ​​của tôi là mọi nhà phát triển nên có kiến ​​thức vượt qua về ít nhất các mẫu trong cuốn sách gốc, chỉ đơn giản là có thể nói về các khái niệm OO mà không phải luôn giải thích những điều cơ bản. Bạn có nên thực sự sử dụng các mẫu mỗi khi một khả năng để làm như vậy xuất hiện? Hầu như không.

Thư viện

Các thư viện có khả năng là một lĩnh vực mà nó có thể nằm ở phía có quá nhiều lựa chọn dựa trên mẫu thay vì quá ít. Thay đổi một cái gì đó từ một lớp "béo" thành một cái gì đó có nguồn gốc từ nhiều mẫu hơn (thường có nghĩa là các lớp nhỏ hơn và nhỏ hơn) sẽ thay đổi hoàn toàn giao diện; và đó là điều bạn thường không muốn thay đổi trong thư viện, bởi vì đó là điều duy nhất được người dùng trong thư viện của bạn quan tâm. Họ sẽ không quan tâm đến cách bạn đối phó với chức năng của bạn trong nội bộ, nhưng họ rất quan tâm nếu họ liên tục phải thay đổi chương trình của họ khi bạn thực hiện một bản phát hành mới với API mới.

Quan điểm của sự trừu tượng trước hết phải là giá trị được mang đến cho người tiêu dùng của sự trừu tượng hóa, tức là khách hàng của sự trừu tượng hóa, các lập trình viên khác và thường là chính bạn.

Nếu, với tư cách là một khách hàng đang sử dụng (các) trừu tượng, bạn thấy bạn cần trộn và kết hợp nhiều trừu tượng khác nhau để hoàn thành công việc lập trình của mình, thì có khả năng có quá nhiều trừu tượng.

Lý tưởng nhất, việc phân lớp nên tập hợp một số trừu tượng thấp hơn và thay thế bằng một sự trừu tượng đơn giản và ở cấp độ cao hơn mà người tiêu dùng có thể sử dụng mà không phải xử lý bất kỳ sự trừu tượng cơ bản nào. Nếu chúng phải xử lý các trừu tượng cơ bản, thì lớp bị rò rỉ (bằng cách không đầy đủ). Nếu người tiêu dùng phải đối phó với quá nhiều trừu tượng khác nhau, thì có lẽ thiếu lớp.

Sau khi xem xét giá trị của các khái niệm trừu tượng cho các lập trình viên tiêu thụ, sau đó chúng ta có thể chuyển sang đánh giá và xem xét việc thực hiện, chẳng hạn như của DRY-ness.

Vâng, đó là tất cả về việc giảm bớt bảo trì, nhưng chúng ta nên xem xét hoàn cảnh bảo trì của người tiêu dùng trước, bằng cách cung cấp các tóm tắt chất lượng và các lớp, sau đó xem xét giảm bớt bảo trì của chúng ta về các khía cạnh thực hiện như tránh dư thừa.

Ví dụ, khi một lớp bộ đệm chung được viết bằng Memcache. Chúng ta có thực sự cần Memcache, MemcacheAd CHƯƠNG, MemcacheInterface, AbstractCache, CacheFactory, CacheConnector, ... hay điều này dễ duy trì hơn và vẫn giữ được mã tốt khi chỉ sử dụng một nửa số lớp đó?

Chúng tôi phải xem xét quan điểm của khách hàng, và nếu cuộc sống của họ được thực hiện dễ dàng hơn thì tốt. Nếu cuộc sống của họ phức tạp hơn thì thật tồi tệ. Tuy nhiên, có thể có một lớp bị thiếu kết hợp những thứ này lại với nhau thành một thứ đơn giản để sử dụng. Trong nội bộ, những điều này rất có thể làm cho việc bảo trì thực hiện tốt hơn. Tuy nhiên, như bạn nghi ngờ, cũng có thể nó chỉ đơn thuần là quá kỹ thuật.

Trừu tượng được thiết kế để làm cho mã dễ hiểu hơn. Nếu một lớp trừu tượng sẽ khiến mọi thứ trở nên khó hiểu hơn - đừng làm điều đó.

Mục đích là để sử dụng đúng số lượng trừu tượng và giao diện để:

• giảm thiểu thời gian phát triển
• tối đa hóa khả năng duy trì mã

Chỉ trừu tượng khi có yêu cầu

1. Khi bạn phát hiện ra bạn đang viết một siêu hạng
2. Khi nào nó sẽ cho phép sử dụng lại mã đáng kể
3. Nếu trừu tượng hóa sẽ làm cho đoạn code sẽ trở nên đáng kể rõ ràng hơn và dễ dàng hơn để đọc

Đừng trừu tượng khi

1. Làm như vậy sẽ không có lợi thế trong việc sử dụng lại mã hoặc rõ ràng
2. Làm như vậy sẽ làm cho mã dài hơn / phức tạp hơn đáng kể mà không có lợi ích

Vài ví dụ

• Nếu bạn chỉ có một bộ đệm trong toàn bộ chương trình, đừng trừu tượng trừ khi bạn nghĩ rằng bạn có khả năng kết thúc với một siêu lớp
• Nếu bạn có ba loại bộ đệm khác nhau, hãy sử dụng một bản tóm tắt giao diện chung cho tất cả chúng.

Tôi nghĩ rằng đây có thể là một câu trả lời meta gây tranh cãi và tôi đến bữa tiệc hơi muộn, nhưng tôi nghĩ việc đề cập đến vấn đề này ở đây là rất quan trọng, bởi vì tôi nghĩ tôi biết bạn đến từ đâu.

Vấn đề với cách sử dụng các mẫu thiết kế, là khi chúng được dạy, chúng trình bày một trường hợp như thế này:

Bạn có kịch bản cụ thể này. Tổ chức mã của bạn theo cách này. Đây là một ví dụ thông minh, nhưng hơi giả tạo.

Vấn đề là khi bạn bắt đầu làm kỹ thuật thực sự, mọi thứ không hoàn toàn như vậy. Mẫu thiết kế bạn đọc về sẽ không hoàn toàn phù hợp với vấn đề bạn đang cố gắng giải quyết. Chưa kể rằng các thư viện bạn đang sử dụng hoàn toàn vi phạm tất cả mọi thứ được nêu trong văn bản giải thích các mẫu đó, mỗi mẫu theo cách đặc biệt của riêng nó. Và kết quả là, mã bạn viết "cảm thấy sai" và bạn đặt câu hỏi như thế này.

Ngoài ra, tôi muốn trích dẫn Andrei Alexandrescu, khi nói về công nghệ phần mềm, người nói:

Kỹ thuật phần mềm, có thể hơn bất kỳ ngành kỹ thuật nào khác, thể hiện tính đa dạng phong phú: Bạn có thể làm điều tương tự theo nhiều cách chính xác và có nhiều sắc thái vô hạn giữa đúng và sai.

Có lẽ đây là một chút cường điệu, nhưng tôi nghĩ rằng điều này giải thích hoàn hảo một lý do bổ sung tại sao bạn có thể cảm thấy không tin tưởng vào mã của mình.

Chính trong những lúc như thế này, giọng nói tiên tri của Mike Acton, người dẫn dắt công cụ trò chơi tại Insomniac, hét lên trong đầu tôi:

BIẾT DỮ LIỆU CỦA BẠN

Anh ấy đang nói về đầu vào cho chương trình của bạn và đầu ra mong muốn. Và sau đó là viên ngọc Fred Brooks từ Tháng huyền thoại:

Chỉ cho tôi sơ đồ của bạn và che giấu các bảng của bạn, và tôi sẽ tiếp tục được bí ẩn. Cho tôi xem bảng của bạn và tôi thường sẽ không cần sơ đồ của bạn; chúng sẽ rõ ràng

Vì vậy, nếu tôi là bạn, tôi sẽ suy luận về vấn đề của mình dựa trên trường hợp đầu vào điển hình của mình và liệu nó có đạt được đầu ra chính xác mong muốn hay không. Và đặt câu hỏi như thế này:

• Là dữ liệu đầu ra từ chương trình của tôi chính xác?
• Được sản xuất hiệu quả / nhanh chóng cho trường hợp đầu vào phổ biến nhất của tôi?
• Mã của tôi có đủ dễ để lý do cục bộ về, cho cả tôi và đồng đội không? Nếu không, sau đó tôi có thể làm cho nó đơn giản hơn?

Khi bạn làm điều đó, câu hỏi "cần bao nhiêu lớp trừu tượng hoặc các mẫu thiết kế" trở nên dễ trả lời hơn nhiều. Bạn cần bao nhiêu lớp trừu tượng? Nhiều như cần thiết để đạt được những mục tiêu này, và không nhiều hơn nữa. "Những gì về mẫu thiết kế? Tôi chưa sử dụng bất kỳ!" Chà, nếu các mục tiêu trên đã đạt được mà không áp dụng trực tiếp một mô hình, thì tốt thôi. Làm cho nó hoạt động, và chuyển sang vấn đề tiếp theo. Bắt đầu từ dữ liệu của bạn, không phải từ mã.

Kiến trúc phần mềm là ngôn ngữ phát minh

Với mỗi lớp phần mềm, bạn tạo ngôn ngữ mà bạn (hoặc đồng nghiệp của bạn) muốn thể hiện giải pháp lớp cao hơn tiếp theo của họ (vì vậy, tôi sẽ đưa vào một số tương tự ngôn ngữ tự nhiên trong bài đăng của tôi). Người dùng của bạn không muốn mất nhiều năm để học cách đọc hoặc viết ngôn ngữ đó.

Quan điểm này giúp tôi khi quyết định các vấn đề kiến ​​trúc.

Dễ đọc

Ngôn ngữ đó nên được hiểu một cách dễ dàng (làm cho mã lớp tiếp theo có thể đọc được). Mã được đọc thường xuyên hơn nhiều so với văn bản.

Một khái niệm nên được thể hiện bằng một từ - một lớp hoặc giao diện sẽ phơi bày khái niệm đó. (Các ngôn ngữ Slavonic thường có hai từ khác nhau cho một động từ tiếng Anh, vì vậy bạn phải học gấp đôi từ vựng. Tất cả các ngôn ngữ tự nhiên sử dụng các từ đơn cho nhiều khái niệm).

Các khái niệm mà bạn phơi bày không nên chứa đựng những điều bất ngờ. Đó chủ yếu là các quy ước đặt tên như phương thức get và set, v.v. Và các mẫu thiết kế có thể giúp ích vì chúng cung cấp một mẫu giải pháp chuẩn và người đọc thấy "OK, tôi lấy các đối tượng từ một Nhà máy" và biết điều đó có nghĩa là gì. Nhưng nếu chỉ đơn giản là bắt đầu một lớp cụ thể thực hiện công việc, tôi thích điều đó.

Khả năng sử dụng

Ngôn ngữ phải dễ sử dụng (giúp dễ dàng tạo thành "câu đúng").

Nếu tất cả các lớp / giao diện MemCache này hiển thị cho lớp tiếp theo, điều đó sẽ tạo ra một đường cong học tập dốc cho người dùng cho đến khi anh ta hiểu được khi nào và ở đâu sử dụng những từ này cho khái niệm duy nhất về bộ đệm.

Chỉ hiển thị các lớp / phương thức cần thiết giúp người dùng của bạn dễ dàng tìm thấy những gì anh ta cần (xem trích dẫn của DocBrowns về Antoine de Saint-Exupery). Phơi bày một giao diện thay vì lớp triển khai có thể làm cho điều đó dễ dàng hơn.

Nếu bạn trưng ra một chức năng nơi có thể áp dụng một mẫu thiết kế đã được thiết lập, thì tốt hơn là nên theo mẫu thiết kế đó hơn là phát minh ra thứ gì đó khác biệt. Người dùng của bạn sẽ hiểu API theo mẫu thiết kế dễ dàng hơn một số khái niệm hoàn toàn khác (nếu bạn biết tiếng Ý, tiếng Tây Ban Nha sẽ dễ dàng hơn so với tiếng Trung Quốc).

Tóm lược

Giới thiệu trừu tượng nếu điều đó làm cho việc sử dụng dễ dàng hơn (và đáng để chi phí cho việc duy trì cả sự trừu tượng hóa và việc thực hiện).

Nếu mã của bạn có một tác vụ phụ (không tầm thường), hãy giải quyết "cách dự kiến" tức là theo mẫu thiết kế phù hợp thay vì phát minh lại một loại bánh xe khác.

Điều quan trọng cần xem xét là mã tiêu thụ thực sự xử lý logic nghiệp vụ của bạn cần biết bao nhiêu về các lớp liên quan đến bộ đệm này. Lý tưởng nhất là mã của bạn chỉ nên quan tâm đến đối tượng bộ đệm mà nó muốn tạo và có thể là một nhà máy để tạo đối tượng đó nếu một phương thức xây dựng không đủ.

Số lượng mẫu được sử dụng hoặc mức độ kế thừa không quá quan trọng miễn là mỗi cấp có thể được chứng minh cho các nhà phát triển khác. Điều này tạo ra một giới hạn không chính thức vì mỗi cấp độ bổ sung khó chứng minh hơn. Phần quan trọng hơn là có bao nhiêu mức độ trừu tượng bị ảnh hưởng bởi những thay đổi đối với các yêu cầu chức năng hoặc kinh doanh. Nếu bạn có thể thay đổi chỉ một cấp cho một yêu cầu thì có khả năng bạn không bị trừu tượng hóa hoặc trừu tượng hóa kém, nếu bạn thay đổi cùng cấp cho nhiều thay đổi không liên quan, bạn có thể bị trừu tượng hóa và cần phải tách biệt thêm.

Đầu tiên, trích dẫn Twitter là không có thật. Các nhà phát triển mới cần tạo ra một mô hình, sự trừu tượng thường sẽ giúp họ "lấy hình ảnh". Cung cấp các khái niệm trừu tượng có ý nghĩa của khóa học.

Thứ hai, vấn đề của bạn không quá nhiều hoặc quá ít trừu tượng, rõ ràng là không ai có thể quyết định về những điều này. Không ai sở hữu mã, không có kế hoạch / thiết kế / triết lý duy nhất nào được thực hiện, bất kỳ chàng trai tiếp theo nào cũng có thể làm bất cứ điều gì mà anh ta có vẻ phù hợp với thời điểm đó. Bất cứ phong cách nào bạn đi, nó nên là một.