Если мы говорим про метод – мы говорим про функциональную абстракцию. В методах (функциях) мы заключаем алгоритм-операцию. Мы можем рассматривать функцию более обще и придавать ей дополнительные свойства, добиваясь своей цели. Но семантика нашего языка именно такая, что мы ограничиваемся только полем фактически выполняемых инструкций.
А что нам может понадобится ещё? При разработке программ нам может быть полезно думать в разрезе сущностей. Сущность – это объединение данных и операций над ними. Совокупность данных определяет некоторое состояние. Операции выполняются не только над аргументами, но и над состоянием контекста. Контекстом и является некоторая сущность.
Ранее я упомянул про чистые функции (Pure Function). Это функции, которые зависят и работают только о того, что им явно передаётся на вход. При работе с классами и объектами мы расширяем контекст функции до состояния объекта. Хорошая функция, как правило, работает с состоянием объекта, в котором она вызывается + с входными аргументами.
Чтобы работать с сущностями нам на самом-то деле классы не нужны. Даже скоп глобальных функций и некие куски глобального состояния мы можем рассматривать как те или иные сущности. А если сущности имеют тенденцию к размножению, т.е имеет несколько одновременно существующих экземпляров с разным состоянием, то нам не составит труда справится и с этим вызовом.
Но если мы прибегнем к синтаксису классов и объектов, нам станет гораздо легче жить. У класса есть несколько первичных определений, которые помогут понять его предназначение. Во-первых, класс – это новый тип данных, который мы вводим в систему. Во-вторых, так как это тип данных – он позволяет сформализировать систему и сделать её более надёжной. Как и в случае с обязательной декларацией параметров и их типов в методах.
Класс возникает тогда, когда мы начинаем осмысливать систему как набор взаимодействующих объектов. Когда мы можем объединить объекты по структуре, мы делаем класс. Это как с дублирующимся кодом. Даже если он отличается в значениях, но структура у него общая, то мы можем создать метод и разные значения подставлять через аргументы.
Например, у нас могут присутствовать пользователи в системе. Что из себя представляет каждый пользователь? Имя, зарплату в час и текущий невыплаченный остаток. В вашей голове пользователь представляет нечто другое? Вполне возможно. Очень ошибочно мнение, что классы и объекты в ООП – это отражения объектов реального мира. На самом деле – это, в первую очередь, описание объектов бизнес-логики. И если в нашем приложение нам нужно, чтобы у пользователя было имя и мы могли начислять ему деньги на основе отработанных часов, то структура у него будет именно такая.
То, что я описал – это члены данных. Мы описали данные, но не операции над ними. В качестве операций может служить операция “Сдать отчёт о работе”. В нём мы указываем отработанные часы и на основе них мы зачисляем пользователю невыплаченный остаток, учитывая его ставку в час.
То, что мы описали – это класс. Когда я говорю где-то в системе, что мне нужен пользователь, то этот пользователь будет именно такой структуры. Я смогу без опаски выполнять заданные операции и работать с доступными данными. А когда уже идёт непосредственная работа с пользователем, мы говорим про объект. Когда у нас уже есть конкретный пользователь, с конкретным именем – это объект. А общее описание пользователя – это класс.