Có phải các lớp chỉ có một phương thức (công khai) là một vấn đề?

Tôi hiện đang làm việc trong một dự án phần mềm thực hiện nén và lập chỉ mục trên các đoạn phim giám sát video. Quá trình nén hoạt động bằng cách tách các đối tượng nền và tiền cảnh, sau đó lưu nền dưới dạng hình ảnh tĩnh và tiền cảnh dưới dạng sprite.

Gần đây, tôi đã bắt tay vào việc xem xét một số lớp mà tôi đã thiết kế cho dự án.

Tôi nhận thấy rằng có nhiều lớp chỉ có một phương thức công khai duy nhất. Một số trong các lớp này là:

• VideoCompressor (với compressphương thức lấy một video đầu vào loại RawVideovà trả về một video đầu ra loại CompressedVideo).
• VideoSplitter (với splitphương thức lấy một video đầu vào loại RawVideovà trả về một vectơ gồm 2 video đầu ra, mỗi loại RawVideo).
• Video Indexer (với một indexphương thức lấy một video đầu vào loại RawVideovà trả về một chỉ mục video loại VideoIndex).

Tôi thấy mình instantiating mỗi lớp chỉ để thực hiện cuộc gọi như VideoCompressor.compress(...), VideoSplitter.split(...), VideoIndexer.index(...).

Nhìn bề ngoài, tôi nghĩ rằng các tên lớp đủ để mô tả chức năng dự định của chúng và chúng thực sự là danh từ. Tương ứng, phương pháp của họ cũng là động từ.

Đây thực sự là một vấn đề?

Không, đây không phải là một vấn đề, hoàn toàn ngược lại. Đó là một dấu hiệu của mô-đun và trách nhiệm rõ ràng của lớp. Giao diện nạc dễ nắm bắt từ quan điểm của người dùng của lớp đó và nó sẽ khuyến khích khớp nối lỏng lẻo. Điều này có nhiều lợi thế nhưng hầu như không có nhược điểm. Tôi muốn nhiều thành phần sẽ được thiết kế theo cách đó!

Nó không còn là đối tượng hướng. Bởi vì các lớp đó không đại diện cho bất cứ điều gì, chúng chỉ là các tàu cho các chức năng.

Điều đó không có nghĩa là nó sai. Nếu chức năng đủ phức tạp hoặc khi nó chung chung (nghĩa là các đối số là giao diện, không phải là loại cuối cùng cụ thể), thì nên đặt chức năng đó trong mô-đun riêng biệt .

Từ đó nó phụ thuộc vào ngôn ngữ của bạn. Nếu ngôn ngữ có chức năng miễn phí, chúng phải là mô-đun xuất các chức năng. Tại sao nó giả vờ là một lớp học khi nó không. Nếu ngôn ngữ không có các hàm miễn phí như Java, thì bạn tạo các lớp với phương thức chung duy nhất. Vâng, điều đó chỉ cho thấy các giới hạn của thiết kế hướng đối tượng. Đôi khi chức năng chỉ đơn giản là phù hợp hơn.

Có một trường hợp khi bạn có thể cần một lớp với phương thức chung duy nhất bởi vì nó phải thực hiện giao diện với phương thức chung duy nhất. Có thể là cho mẫu quan sát hoặc tiêm phụ thuộc hoặc bất cứ điều gì. Ở đây nó một lần nữa phụ thuộc vào ngôn ngữ. Trong các ngôn ngữ có hàm functor hạng nhất (C ++ ( std::functionhoặc tham số mẫu), C # (ủy nhiệm), Python, Perl, Ruby ( proc), Lisp, Haskell, ...) các mẫu này sử dụng các loại hàm và không cần các lớp. Java không (chưa, trong phiên bản 8) có các kiểu hàm, vì vậy bạn sử dụng các giao diện phương thức đơn và các lớp phương thức đơn tương ứng.

Tất nhiên tôi không ủng hộ việc viết một chức năng lớn. Nó nên có các chương trình con riêng tư, nhưng chúng có thể là riêng tư đối với tệp thực hiện (không gian tên tĩnh hoặc ẩn danh ở cấp độ tệp trong C ++) hoặc trong lớp trình trợ giúp riêng chỉ được khởi tạo bên trong hàm công khai ( Để lưu trữ dữ liệu hay không? ).

Có thể có lý do để trích xuất một phương thức nhất định vào một lớp chuyên dụng. Một trong những lý do đó là cho phép tiêm Dependency.

Hãy tưởng tượng bạn có một lớp được gọi là VideoExporter, cuối cùng, sẽ có thể nén video. Một cách sạch sẽ là có một giao diện:

interface IVideoCompressor
{
    Stream compress(Video video);
}

sẽ được thực hiện như thế này:

class MpegVideoCompressor : IVideoCompressor
{
    // ...
}

class FlashVideoCompressor : IVideoCompressor
{
    // ...
}

và được sử dụng như thế này:

class VideoExporter
{
    // ...
    void export(Destination destination, IVideoCompressor compressor)
    {
        // ...
        destination = compressor(this.source);
        // ...
    }
    // ...
}

Một thay thế xấu sẽ là có một VideoExporterphương pháp công khai và thực hiện tất cả các công việc, bao gồm cả nén. Nó sẽ nhanh chóng trở thành một cơn ác mộng bảo trì, khiến việc thêm hỗ trợ cho các định dạng video khác trở nên khó khăn.

Đây là một dấu hiệu cho thấy bạn muốn truyền các hàm làm đối số cho các hàm khác. Tôi đoán ngôn ngữ của bạn (Java?) Không hỗ trợ ngôn ngữ đó; nếu đó là trường hợp, nó không phải là một thất bại trong thiết kế của bạn vì nó là một thiếu sót trong ngôn ngữ của bạn lựa chọn. Đây là một trong những vấn đề lớn nhất với các ngôn ngữ khẳng định rằng mọi thứ phải là một lớp.

Nếu bạn không thực sự chuyển các hàm giả này xung quanh thì bạn chỉ muốn một hàm tự do / tĩnh.

Tôi biết tôi đến bữa tiệc muộn nhưng dường như mọi người đã bỏ lỡ để chỉ ra điều này:

Đây là một mẫu thiết kế nổi tiếng được gọi là: Mẫu chiến lược .

Mẫu chiến lược được sử dụng khi có một số chiến lược khả thi để giải quyết vấn đề phụ. Thông thường, bạn xác định một giao diện thực thi hợp đồng trên tất cả các triển khai và sau đó sử dụng một số hình thức của Dependency Injection để cung cấp chiến lược cụ thể cho bạn.

Ví dụ trong trường hợp này bạn có thể có interface VideoCompressorvà sau đó có một số triển khai thay thế chẳng hạn class H264Compressor implements VideoCompressorvà class XVidCompressor implements VideoCompressor. OP không rõ ràng rằng có một giao diện liên quan, ngay cả khi không có, có thể chỉ đơn giản là tác giả ban đầu đã mở cửa để thực hiện mô hình chiến lược nếu cần. Mà trong và của chính nó là thiết kế tốt quá.

Vấn đề mà OP liên tục thấy mình bắt đầu các lớp để gọi một phương thức là một vấn đề với việc cô ấy không sử dụng phép tiêm phụ thuộc và mô hình chiến lược một cách chính xác. Thay vì khởi tạo nó ở nơi bạn cần, lớp chứa nên có một thành viên với đối tượng chiến lược. Và thành viên này nên được tiêm, ví dụ như trong hàm tạo.

Trong nhiều trường hợp, mẫu chiến lược dẫn đến các lớp giao diện (như bạn đang hiển thị) chỉ bằng một doStuff(...)phương thức duy nhất .

public interface IVideoProcessor
{
   void Split();

   void Compress();

   void Index();
}

Những gì bạn đã có là mô-đun và điều đó tốt, nhưng nếu bạn nhóm các trách nhiệm này vào IVideoProcessor, điều đó có thể có ý nghĩa hơn từ quan điểm của DDD.

Mặt khác, nếu chia tách, nén và lập chỉ mục không liên quan theo bất kỳ cách nào, thì tôi sẽ giữ chúng như các thành phần riêng biệt.

Đó là một vấn đề - bạn đang làm việc từ khía cạnh chức năng của thiết kế, chứ không phải là dữ liệu. Những gì bạn thực sự có là 3 chức năng độc lập đã được OO-ified.

Ví dụ: bạn có lớp VideoCompressor. Tại sao bạn làm việc với một lớp được thiết kế để nén video - tại sao bạn không có lớp Video với các phương thức trên đó để nén dữ liệu (video) mà mỗi đối tượng thuộc loại này chứa?

Khi thiết kế các hệ thống OO, tốt nhất là tạo các lớp đại diện cho các đối tượng, thay vì các lớp đại diện cho các hoạt động mà bạn có thể áp dụng. Vào thời xưa, các lớp được gọi là các loại - OO là một cách để mở rộng ngôn ngữ với sự hỗ trợ cho các loại dữ liệu mới. Nếu bạn nghĩ về OO như thế này, bạn sẽ có một cách tốt hơn để thiết kế các lớp học của mình.

BIÊN TẬP:

hãy để tôi cố gắng giải thích bản thân tốt hơn một chút, hãy tưởng tượng một lớp chuỗi có phương thức concat. Bạn có thể triển khai một thứ như vậy trong đó mỗi đối tượng được khởi tạo từ lớp chứa dữ liệu chuỗi, vì vậy bạn có thể nói

string mystring("Hello"); 
mystring.concat("World");

nhưng OP muốn nó hoạt động như thế này:

string mystring();
string result = mystring.concat("Hello", "World");

bây giờ có những nơi mà một lớp có thể được sử dụng để chứa một tập hợp các hàm liên quan, nhưng đó không phải là OO, đó là cách sử dụng các tính năng OO của ngôn ngữ để giúp quản lý cơ sở mã của bạn tốt hơn, nhưng không có cách nào khác của "Thiết kế OO". Đối tượng trong các trường hợp như vậy là hoàn toàn nhân tạo, chỉ đơn giản được sử dụng như thế này vì ngôn ngữ không cung cấp bất cứ điều gì tốt hơn để quản lý loại vấn đề này. ví dụ. Trong các ngôn ngữ như C #, bạn sẽ sử dụng một lớp tĩnh để cung cấp chức năng này - nó sử dụng lại cơ chế lớp, nhưng bạn không còn cần phải khởi tạo một đối tượng chỉ để gọi các phương thức trên nó. Bạn kết thúc với các phương pháp string.IsNullOrEmpty(mystring)mà tôi nghĩ là kém so với mystring.isNullOrEmpty().

Vì vậy, nếu bất cứ ai hỏi "làm thế nào để tôi thiết kế các lớp của mình", tôi khuyên bạn nên nghĩ về dữ liệu mà lớp sẽ chứa thay vì các hàm mà nó chứa. Nếu bạn chọn "một lớp là một loạt các phương thức", thì cuối cùng bạn sẽ viết mã kiểu "C tốt hơn". (điều này không nhất thiết là điều xấu nếu bạn đang cải thiện mã C) nhưng nó sẽ không cung cấp cho bạn chương trình được thiết kế OO tốt nhất.

Các ISP (nguyên tắc phân giao diện) nói rằng không có khách hàng nên buộc phải phụ thuộc vào phương pháp nó không sử dụng. Những lợi ích là nhiều và rõ ràng. Cách tiếp cận của bạn hoàn toàn tôn trọng ISP, và điều đó tốt.

Một cách tiếp cận khác cũng tôn trọng ISP, ví dụ, tạo một giao diện cho mỗi phương thức (hoặc tập hợp các phương thức có độ gắn kết cao) và sau đó có một lớp duy nhất thực hiện tất cả các giao diện đó. Cho dù đây là hay không một giải pháp tốt hơn phụ thuộc vào kịch bản. Lợi ích của việc này là, khi sử dụng phép nội xạ phụ thuộc, bạn có thể có một ứng dụng khách với các cộng tác viên khác nhau (mỗi người trên một giao diện) nhưng cuối cùng tất cả các cộng tác viên sẽ trỏ đến cùng một đối tượng.

Nhân tiện, bạn đã nói

Tôi thấy mình đang bắt đầu mỗi lớp

, các lớp này dường như là các dịch vụ (và do đó không trạng thái). Bạn đã nghĩ về việc làm cho họ singletons?

Vâng, có một vấn đề. Nhưng không nghiêm trọng. Tôi có nghĩa là bạn có thể cấu trúc mã của bạn như thế này và sẽ không có gì xấu xảy ra, nó có thể được duy trì. Nhưng có một số điểm yếu cho loại cấu trúc đó. Ví dụ, hãy xem xét nếu đại diện cho video của bạn (trong trường hợp của bạn, nó được nhóm trong lớp RawVideo) thay đổi, bạn sẽ cần cập nhật tất cả các lớp hoạt động của mình. Hoặc xem xét rằng bạn có thể có nhiều đại diện cho video khác nhau trong thời gian chạy. Sau đó, bạn sẽ phải khớp đại diện với lớp "hoạt động" cụ thể. Ngoài ra, về mặt chủ quan, thật khó chịu khi phải kéo theo một phụ thuộc cho mỗi thao tác bạn muốn thực hiện trên smth. và để cập nhật danh sách các phụ thuộc được chuyển qua mỗi khi bạn quyết định rằng hoạt động không còn cần thiết hoặc bạn cần hoạt động mới.

Ngoài ra, đó thực sự là một vi phạm SRP. Một số người chỉ coi SRP là một hướng dẫn để phân chia trách nhiệm (và đưa nó đi xa bằng cách coi mỗi hoạt động là một trách nhiệm riêng biệt) nhưng họ quên rằng SRP cũng là một hướng dẫn để phân nhóm trách nhiệm. Và theo trách nhiệm của SRP thay đổi vì cùng một lý do nên được nhóm lại với nhau để nếu thay đổi xảy ra, nó được tập trung vào càng ít lớp / mô-đun càng tốt. Đối với các lớp lớn, không có vấn đề gì khi có nhiều thuật toán trong cùng một lớp miễn là các thuật toán đó có liên quan (nghĩa là chia sẻ một số kiến ​​thức không nên biết bên ngoài lớp đó). Vấn đề là các lớp lớn có các thuật toán không liên quan theo bất kỳ cách nào và thay đổi / thay đổi vì những lý do khác nhau.