Нет , объект не должен представлять сущность.
На самом деле, я бы сказал, что когда вы перестаете думать об объектах как о физических объектах, это когда вы, наконец, получаете преимущества, которые обещает ООП.
Это не лучший пример, но дизайн кофеварки - это, вероятно, то место, где мне начали светиться.
Объекты о сообщениях. Они об обязанностях. Они не об автомобилях, пользователях или заказах.
Я знаю, что мы преподаем ОО таким образом, но после нескольких попыток становится очевидным, насколько фундаментально сложно расставаться, когда дела идут, когда вы пытаетесь сделать MVC, MVVM или MVW, что угодно. Либо ваши модели становятся смехотворно раздутыми, либо контроллеры. Для удобства навигации важно знать, что все, что касается транспортных средств, находится в файле Vehicle.ext, но когда ваше приложение относится к транспортным средствам, вы неизбежно получите 3000 строк спагетти в этом файле.
Если у вас есть новое сообщение для отправки, у вас есть как минимум один новый объект и, возможно, пара из них. Так что в вашем вопросе о пакете методов я бы сказал, что вы потенциально говорите о пакете сообщений. И каждый из них может быть своим собственным объектом, со своей работой. И это нормально. Это станет очевидным, когда вы разделите вещи на части, которые действительно должны быть вместе. И ты собрал их вместе. Но вы не сразу бросаете каждый метод в смутно подходящий ящик для удобства, если хотите насладиться ОО.
Давайте поговорим о мешках функций
Объект может быть просто набором методов и при этом быть ОО, но мои «правила» довольно строги.
На коллекцию должна быть возложена одна ответственность, и эта ответственность не может быть такой же общей, как «Делает вещи для моторов». Я мог бы сделать такую вещь, как фасад уровня сервиса, но я прекрасно осознаю, что мне лень по причинам навигации / обнаружения, а не потому, что я пытаюсь написать ОО-код.
Все методы должны быть на согласованном уровне абстракции. Если один метод извлекает объекты Motor, а другой возвращает мощность, это, вероятно, слишком далеко друг от друга.
Объект должен работать на тех же «видах» данных. Этот объект работает с двигателями (запуск / останов), этот работает с длинами кривошипа, этот обрабатывает последовательность зажигания, этот принимает форму HTML. Эти данные могут быть полями на объекте, и они могут показаться связными.
Обычно я создаю объекты такого рода, когда я выполняю преобразования, компоновку или просто не хочу беспокоиться об изменчивости.
Я считаю, что сосредоточение на предметных обязанностях ведет меня к сплоченности. Чтобы быть объектом, должна быть некоторая сплоченность, но для того, чтобы он был объектом, не требуется никаких полей или поведения. Если бы я строил систему, которая нуждалась в этих 5 моторных методах, я бы начал с 5 разных объектов, которые делают эти вещи. Когда я нашел общность, я бы либо начал объединять вещи, либо использовал общие «вспомогательные» объекты. Это приводит меня к открытым / закрытым проблемам - как я могу извлечь эту часть функциональности, чтобы мне больше никогда не приходилось изменять этот конкретный файл, а использовать его там, где это необходимо?
Объекты о сообщениях
Поля почти не имеют значения для объекта - получение и установка регистров не изменяет мир вне программы. Сотрудничество с другими объектами делает работу. Однако сила OO в том, что мы можем создавать абстракции, поэтому нам не нужно думать обо всех отдельных деталях одновременно. Абстракции, которые утекли или не имеют смысла, проблематичны, поэтому мы глубоко (слишком много, может быть) думаем о создании объектов, которые соответствуют нашим ментальным моделям.
Ключевой вопрос: почему эти два объекта должны общаться друг с другом?
Думайте об объекте как об органе в человеке - он имеет цель по умолчанию и меняет поведение только тогда, когда получает определенное сообщение, которое ему небезразлично.
Представьте себе сценарий, когда вы находитесь на пешеходном переходе, и машина едет быстро. Как объект мозга, я обнаруживаю стрессор. Я говорю гипоталамусу отправлять кортикотрофин-рилизинг-гормон. Гипофиз получает это сообщение и выпускает кортикотрофный гормон надпочечников. Надпочечники получают это сообщение и создают адреналин. Когда мышечный объект получает это сообщение адреналина, он сжимается. Когда сердце получает то же сообщение, оно бьется быстрее. Есть целая цепь игроков, вовлеченных в запуск сложного поведения бега через улицу, и это сообщения, которые имеют значение. Объект мозга знает, как заставить гипоталамус отправлять оповещение, но он не знает цепочку объектов, которые в конечном итоге приведут к тому, что поведение будет происходить. Точно так же сердце не знает, откуда берется адреналин,
Таким образом, в этом ( упрощенном ) примере объект надпочечников должен знать, как принимать АКТГ и вырабатывать адреналин. Для этого не нужны никакие поля, но мне все еще кажется, что это объект.
Теперь, если наше приложение предназначено только для бега через улицу, мне могут не понадобиться объекты гипофиза и надпочечников. Или мне нужен только объект гипофиза, который выполняет лишь небольшую часть того, что мы можем концептуально рассматривать как «модель гипофиза». Все эти понятия существуют как концептуальные сущности, но это программное обеспечение, и мы можем создать AdrenalineSender или MuscleContractor или что-то еще и не беспокоиться о «неполноте» нашей модели.