Элегантные объекты

Объектно-ориентированное программирование, наверное, самая популярная парадигма из всех ныне существующих. В топах популярных языков лидируют именно объектно-ориентированные языки, то есть Java, C#, Python, C++. Всё вроде бы классно, объекты есть, классы есть, да и жизнь цветёт другими красками. Однако, почему иногда складывается ощущение, что мы просто привязываем процедуру к какому-то классу? Мы что-то делаем не так?

Суть проблемы

Допустим, была у нас процедура print(String arg), которая выводила на экран переданное ей значение. А мы взяли, да создали класс InputOutput и сделали нашу процедуру методом. Есть кардинальные отличия? Нет. И даже известно почему.

Причины проблемы

Отношение к объектам

С этого и стоит начать. Чем для начинающего программиста в ООП являются объекты? Тем же, чем и для Википедии, набором именованных свойств, которые можно удалять, добавлять, изменять, или вообще ничего с ними не делать. В большинстве своём из этого и вытекают следующие далее причины. Объект — не просто набор каких-то там свойств. Точнее, так и есть, но к объекту нужно относиться как к «живой» сущности. Мы не вызываем метод, мы «вежливо просим объект сделать это». Мы не можем просто так взять и начать выполнять манипуляции со свойствами объекта, так как это только его свойства, мы не можем узнать, что у него «внутри», ибо это его личное дело. Если мы изменим какое-то свойство у объекта, он уже перестанет быть тем, чем был раньше. Разве это можно хотя бы приблизительно назвать «живой» сущностью? Скорее, какой-то конструктор LEGO.

Getters, setters, публичные свойства

Вот это именно то, о чём я и говорил.

// C# class Person {     public string Name {         get {             return name;         }          set {             name = value;         }     } }

Свойства объекты концептуально не могут быть публичными, это нарушает правило инкапсуляции. Если свойства публичны, то мы имеем не «мыслящий» объект, а глупую структуру данных, которая может только сохранять в себе информацию. Объект должен в себе что-то инкапсулировать. Если он задумался каким-то — пусть он таким и остаётся, это его личное пространство и распоряжаться им может только он в своих методах.
В некоторых языках программирования эту проблему попытались решить, введя data objects, дабы отделить «правильные» объекты от глупых структур данных. Иногда приходится делать и такое. К примеру, Kotlin:

// Kotlin data class Person(val name: String) {     var age: Int = 0 }

Помимо сахара в виде ключевого слова data такие объекты имеют некоторые ограничения и специфичные им методы.

Static методы

Это то, о чём я говорил в начале.

Мы просто вставили нашу процедуру в объект, и всё. Эта функция не использует свойства объекта, можно даже экземпляр не создавать. Должен сказать, что такое бывает полезно, если нужно вынести функции в модули. Однако это модули, а не объекты. Мы же хотим ООП, а не процедурное программирование?

// Java class Program {     public static void main(){        /* Точка входа main() вынуждена являться статической */        System.out.println("hello");     } }

NULL

Тоже своего рода проблема. Язык Kotlin, к примеру, пытается с ней бороться. Но полностью, этого, конечно, не сделаешь, поэтому тип Null в этом языке тоже есть. Однако его следует избегать в ООП. Метод не должен быть процедурой. Если он ничего не возвращает, то он должен хотя бы что-то инкапсулировать. К примеру:

# Python  # Метод достаёт из БД имя и обновляет его в соответствующем свойстве. # ВАЖНО: НЕ МЫ ОБНОВЛЯЕМ, А САМ МЕТОД! # Мы не передаем параметр, а объект сам понимает, что ему делать.  class User:     def update_name(self):         # ... some code ...  #         self.name = name

И ещё не нужно пытаться возвращать свойства объекта, так как свойства нельзя использовать извне.

---

Надеюсь, что я объяснил хоть немного приемлемо, потому что тема специфичная, в самый раз для каверзных вопросов мне и хорошего такого холивара. Подводя итог, выделю самое важное:

• Объект должен быть похож на «живую» сущность;
• Мы «обращаемся, просим» объект сделать что-то;
• Свойства объекта — исключительно его собственность;
• Статические методы — зло;

Ну и цель у этого действа тоже должна быть. Наверняка уже у некоторых был вопрос, мол, мне и так нормально живётся с публичными свойствами и статическими методами, зачем мне это вообще нужно?
Проектировать архитектуру объектов нужно так, чтобы не брать всю обязанность на себя, как в процедурном программировании. Мы должны доверять объекту, знать, что если он сейчас «Вася», то он и в будущем будет «Васей»; если его метод сейчас возвращает «привет», то и в будущем он будет возвращать «привет».

Почти на пальцах объяснил. Спасибо за то, что дочитали =)