Чи є проблемами лише класи з одним (загальнодоступним) методом?

Зараз я працюю над програмним проектом, який виконує стиснення та індексацію кадрів із відеоспостереження. Стиснення працює шляхом розбиття фонових та переднього плану, а потім збереження фону як статичного зображення, а переднього плану - як спрайту.

Нещодавно я приступив до перегляду деяких класів, які я призначив для проекту.

Я помітив, що існує багато класів, які мають лише єдиний публічний метод. Деякі з цих класів:

• VideoCompressor (з compressметодом, який приймає вхідне відео типу RawVideoта повертає вихідне відео типу CompressedVideo).
• VideoSplitter (з splitметодом, який приймає вхідне відео типу RawVideoта повертає вектор із 2 вихідних відео, кожен із типів RawVideo).
• VideoIndexer (з indexметодом, який приймає вхідне відео типу RawVideoта повертає відеоіндекс типу VideoIndex).

Я вважаю себе інстанцірованія кожного класу тільки здійснювати дзвінки , як VideoCompressor.compress(...), VideoSplitter.split(...), VideoIndexer.index(...).

На перший погляд, я думаю, що назви класів достатньо описують призначену функцію, і вони насправді є іменниками. Відповідно їх методами є також дієслова.

Це насправді проблема?

Ні, це не проблема, а навпаки. Це ознака модульності та чіткої відповідальності класу. Користувач інтерфейсу легко зрозуміти з точки зору користувача цього класу, і це сприятиме слабкому з'єднанню. Це має багато переваг, але майже не має недоліків. Я хочу, щоб більше компонентів було б розроблено саме так!

Він більше не орієнтований на об’єкти. Оскільки ці класи нічого не представляють, вони є лише суднами для функцій.

Це не означає, що це неправильно. Якщо функціональність є досить складною або коли вона є загальною (тобто аргументи - це інтерфейси, а не конкретні кінцеві типи), має сенс розмістити цю функціональність в окремому модулі .

Звідти це залежить від вашої мови. Якщо мова має вільні функції, вони повинні бути модулями, які експортують функції. Навіщо робити вигляд, що це клас, коли його немає. Якщо мова не має вільних функцій, наприклад, Java, то ви створюєте класи за допомогою одного публічного методу. Це добре показує межі об'єктно-орієнтованого дизайну. Іноді функціонал просто краще відповідає.

Є один випадок, коли вам може знадобитися клас з єдиним публічним методом, оскільки він повинен реалізовувати інтерфейс з єдиним публічним методом. Будь то для моделі спостереження чи ін'єкції залежності чи будь-чого іншого. Тут це знову залежить від мови. У мовах, які мають функціонери першого класу (C ++ ( std::functionабо параметр шаблону), C # (делегат), Python, Perl, Ruby ( proc), Lisp, Haskell, ...), ці шаблони використовують типи функцій та не потребують класах. Java не має (поки що буде у версії 8) типів функцій, тому ви використовуєте інтерфейси одного методу та відповідні класи одного методу.

Звичайно, я не прихильник написання однієї величезної функції. Він повинен мати приватні підпрограми, але вони можуть бути приватними до файлу реалізації (статичного рівня або анонімного простору імен на рівні файлів на C ++) або до приватного класу помічників, який лише інстанціюється у межах загальнодоступної функції ( Зберігати дані чи ні? ).

Можуть бути причини для вилучення заданого методу у виділений клас. Однією з таких причин є дозволити введення залежностей.

Уявіть, що у вас є клас під назвою, VideoExporterякий, зрештою, повинен мати можливість стиснути відео. Чистим способом було б мати інтерфейс:

interface IVideoCompressor
{
    Stream compress(Video video);
}

що буде реалізовано так:

class MpegVideoCompressor : IVideoCompressor
{
    // ...
}

class FlashVideoCompressor : IVideoCompressor
{
    // ...
}

і використовується так:

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

Погана альтернатива була б мати , VideoExporterякий має багато спільних методи і робить всю роботу, в тому числі в стискає. Це швидко перетвориться на кошмар технічного обслуговування, що ускладнить додавання підтримки для інших форматів відео.

Це знак того, що ви хочете передати функції як аргументи іншим функціям. Я здогадуюсь, ваша мова (Java?) Не підтримує її; якщо це так, це не стільки невдача у вашому дизайні, скільки недолік вашої мови вибору. Це одна з найбільших проблем з мовами, які наполягають на тому, що все повинно бути класом.

Якщо ви фактично не передаєте ці штучні функції, тоді ви просто хочете вільну / статичну функцію.

Я знаю, що я спізнююсь на вечірку, але, як видається, кожен пропустив це:

Це добре відома модель дизайну під назвою: Стратегічний шаблон .

Шаблон стратегії застосовується, коли існує кілька можливих стратегій вирішення підзадачі. Зазвичай ви визначаєте інтерфейс, який застосовує контракт щодо всіх реалізацій, а потім використовуєте певну форму введення залежностей для надання конкретної стратегії для вас.

Наприклад, у цьому випадку ви можете мати, interface VideoCompressorа потім мати кілька альтернативних реалізацій, наприклад, class H264Compressor implements VideoCompressorта class XVidCompressor implements VideoCompressor. З ОП незрозуміло, що тут задіяний інтерфейс, навіть якщо його немає, може бути просто те, що оригінальний автор залишив двері відкритими, щоб застосувати шаблон стратегії, якщо це необхідно. Що саме по собі є хорошим дизайном.

Проблема, з якою ОП постійно виявляє примушення класів викликати метод, - це проблема з її неправильним використанням ін'єкцій залежності та схемою стратегії. Замість того, щоб інстанціювати його там, де вам це потрібно, клас, що містить, повинен мати члена з об'єктом стратегії. І цей член повинен бути введений, наприклад, в конструктор.

У багатьох випадках схема стратегії призводить до класів інтерфейсів (як ви показуєте) лише одним doStuff(...)методом.

public interface IVideoProcessor
{
   void Split();

   void Compress();

   void Index();
}

Те, що у вас є, є модульним і це добре, але якби ви згрупували ці обов'язки в IVideoProcessor, це, мабуть, має більше сенсу з точки зору DDD.

З іншого боку, якби розщеплення, стискання та індексація ні в якому разі не пов'язані, я б зберігав їх як окремі компоненти.

Це проблема - ви працюєте з функціонального аспекту дизайну, а не даних. Насправді у вас є 3 самостійні функції, які були встановлені OO.

Наприклад, у вас є клас VideoCompressor. Чому ви працюєте з класом, призначеним для стиснення відео - чому у вас немає відеокласу з методами на ньому для стиснення даних (відео), які містять кожен об'єкт цього типу?

При проектуванні OO систем найкраще створювати класи, що представляють об’єкти, а не класи, які представляють діяльність, яку ви можете застосувати. За старих часів класи називались типами - ОО було способом розширення мови з підтримкою нових типів даних. Якщо ви думаєте про OO таким чином, ви отримаєте кращий спосіб проектувати свої класи.

Редагувати:

дозвольте мені спробувати трохи краще пояснити себе, уявіть клас струн, у якому є метод concat. Ви можете реалізувати таку річ, коли кожен об'єкт, ініційований з класу, містить рядкові дані, так що ви можете сказати

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

але ОП хоче, щоб це працювало так:

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

тепер є місця, де клас може бути використаний для зберігання колекції пов'язаних функцій, але це не ОО, це зручний спосіб використання функцій мови мови OO, щоб допомогти краще керувати вашою кодовою базою, але це жоден спосіб "OO Design". Об'єкт у таких випадках є абсолютно штучним, просто використовується таким чином, оскільки мова не пропонує нічого кращого для управління подібними проблемами. напр. У таких мовах, як C #, ви б використовували статичний клас, щоб забезпечити цю функціональність - він повторно використовує механізм класу, але вам більше не потрібно інстанціювати об'єкт, щоб викликати його методи. Ви закінчуєте такі методи, як, на string.IsNullOrEmpty(mystring)мою думку, погані порівняно з mystring.isNullOrEmpty().

Отже, якщо хтось запитує "як я проектую свої класи", я рекомендую продумати дані, які буде містити клас, а не функції, які він містить. Якщо ви переходите до "класу - це купа методів", тоді ви закінчите писати код стилю "кращий C". (що не обов'язково погано, якщо ви вдосконалюєте код C), але це не дасть вам найкращої програми, розробленої ОО.

ISP (інтерфейс принцип сегрегації) говорить , що ні один клієнт не повинен бути змушений залежати від методів його не використовує. Переваги багаторазові і зрозумілі. Ваш підхід повністю поважає ISP, і це добре.

Інший підхід, що стосується також ISP, це, наприклад, створити інтерфейс для кожного методу (або набір методів з високою когезією), а потім мати єдиний клас, що реалізує всі ці інтерфейси. Краще рішення це чи ні, залежить від сценарію. Перевага цього полягає в тому, що при використанні ін'єкції залежності ви можете мати клієнта з різними колабораторами (по одному на кожен інтерфейс), але врешті-решт всі співпрацівники вказуватимуть на один і той же екземпляр об'єкта.

До речі, ви сказали

Я вважаю, що інстанціюю кожен клас

, ці класи здаються послугами (і, таким чином, без громадянства). Ви думали зробити їх одинаковими?

Так, є проблема. Але не важкий. Я маю на увазі, що ви можете структурувати свій код так, і нічого поганого не станеться, це є ремонтом. Але в такому вигляді структуризації є деякі слабкі сторони. Наприклад, врахуйте, що якщо представлення вашого відео (у вашому випадку воно згруповане в класі RawVideo) зміниться, вам потрібно буде оновити всі свої операційні класи. Або вважайте, що у вас може бути кілька зображень відео, які відрізняються за часом виконання. Тоді вам доведеться співставити представлення з певним класом "операції". Також суб'єктивно роздратовано перетягувати залежність для кожної операції, яку ви хочете зробити на smth. а також оновлювати список залежностей, пройдених кожен раз, коли ви вирішите, що операція більше не потрібна або вам потрібна нова операція.

Також це фактично є порушенням SRP. Деякі люди просто розглядають СРП як керівництво для розподілу обов'язків (і переносять його далеко, розглядаючи кожну операцію окремо відповідально), але вони забувають, що СРП також є керівництвом щодо групування відповідальності. Відповідно до обов'язків SRP, які змінюються з тієї ж причини, слід згрупувати разом, щоб у разі зміни вони були локалізовані на якомога менше класів / модулів. Що стосується великих класів, це не проблема наявності кількох алгоритмів в одному класі, якщо ці алгоритми пов'язані (тобто поділитися деякими знаннями, які не повинні бути відомі поза цим класом). Проблема - це великі класи, у яких є алгоритми, які ніяк не пов’язані між собою і змінюються / змінюються з різних причин.