Чому я бачу стільки миттєвих класів без держави?

Я бачу безліч миттєвих класів у світі C ++ та Java, які не мають жодного стану.

Я дійсно не можу зрозуміти, чому люди так роблять, вони можуть просто використовувати простір імен з вільними функціями на C ++ або клас із приватним конструктором і лише статичними методами на Java.

Єдина користь, про яку я можу подумати - це те, що вам не доведеться змінювати більшу частину коду, якщо згодом вирішите, що вам потрібно інша реалізація в певних ситуаціях. Але це не випадок передчасного дизайну? Його можна перетворити на клас пізніше, коли / якщо стане відповідним.

Я помиляюся? Чи це не OOP, якщо я не вкладаю все в об'єкти (тобто інстанційні класи)? Тоді чому в стандартних бібліотеках C ++ і Java так багато просторів імен утиліт та класів?

Оновлення: я, звичайно, бачив багато прикладів цього в своїх попередніх роботах, але я намагаюся знайти приклади з відкритим кодом, тому, можливо, це все не так часто. Все-таки мені цікаво, чому це роблять люди, і наскільки це звичайно.

Я бачу безліч миттєвих класів у світі C ++ та Java, які не мають жодного стану.

Деякі можливі причини створення класів без власних іварів:

• Держава є або може міститися в надкласі.

• Клас реалізує деякий інтерфейс і повинен бути миттєвим, щоб екземпляри могли передаватися іншим об'єктам.

• Клас призначений для підкласу.

• Зручний спосіб групувати пов'язані функції. (Так, можуть бути кращі або різні способи зробити те саме.)

Я помиляюся? Чи це не OOP, якщо я не вкладаю все в об'єкти (тобто інстанційні класи)?

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

Кейлб та Роберт Харві вже вказали, що таке утиліти, а також деякі законні причини для класів "без даних". Ці описи точні, але стосуються позитивних аспектів.

Я хотів би лише зазначити, що зловживання класами корисних програм, безумовно, може бути анти-схемою OO (див . Опис c2wiki ). Ця цитата красиво резюмує:

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

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

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

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

Багато цих класів взаємодіють з даними, навіть якщо вони явно не містять їх, і потрібно робити це способами, які вимагають активності декількох одночасних екземплярів. Наприклад, сеанс без стану, який взаємодіє із збереженою в базі даних процедурою, передаючи вхідні дані в якийсь пакет PL / SQL і передаючи результати назад в викликаючу програму. Ця річ повинна існувати в декількох випадках, але сама по собі не містить полів даних.

В об'єктно-орієнтованих мовах, де класи не є об'єктами, ви можете зробити набагато більше з об'єктом, ніж клас.

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

Для деяких класів можливості, надані інстанцією, здаються малоймовірними. Можливо, вам не потрібно буде замінювати одну реалізацію Cosine на іншу, наприклад. Виявляється, в основному функції утиліти не потребують цих можливостей, тому в основному утилітні функції мають класи, які не є миттєвими.