ООП: Когда это - объект?

Как всегда, ответ к сожалению: это зависит ...

В начале у вас есть какая-то среда, и вы хотите создать модель для нее. Но вы не будете моделировать каждую вещь, вы будете концентрироваться на важных вещах. Вот почему я начал с: это зависит. Это зависит от того, какие детали вам нужны для выполнения задачи.

Возьмите автомобиль и его колеса - если вы моделируете город и хотите немного трафика, вы можете создать класс 'Car' с атрибутом 'numberOfWheels'. Но если вы проектируете автомобили, то, скорее всего, вы захотите создать класс «Колесо» и добавить четыре из них в класс «Автомобиль».

Основное правило:

1. , если то, о чем вы думаете, имеет более одного атрибута, определите класс
2. , если это, то, что вы думаете о, имеет некоторое поведение, определите класс
3. , если это, о чем вы думаете, может расти или расширяться, определите класс
4. , если это, о чем вы думаете, должен быть сортируемым, сопоставимым, определить класс
5. , если вы не уверены, определить класс;)

Редактировать

Потому что Вы подчеркнули аспект «многократного использования»: я не думаю, что это аспект для решения, использовать ли класс или нет. Подумайте о простом счетчике, целочисленном значении в цикле for. Вы будете использовать эту концепцию сотни раз, но держу пари, что вы никогда не подумаете о том, чтобы обернуть этот бедный маленький int в класс «Counter» - просто потому, что вы используете «концепцию счетчика» несколько раз.

Все является объектом. Иногда вы просто используете примитивную переменную (int) для представления объекта, а иногда вы создаете структуру данных (struct / class). И, естественно, некоторые объекты являются частями других объектов.

Итак, да, если вам нужно что-то сделать в своем коде с той частью посередине, где вы вставляете ключ , это также должно быть объектом в вашем коде. Он может быть представлен просто как string Keyhole и может быть представлен как class Keyhole, он может быть независимым объектом и может быть частью class DoorKnob - но в любом случае это будет объект.

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

Все можно превратить в объект.

ИМО, ответом на ваш вопрос является вопрос - Нужно ли поведение замочной скважины, чтобы моя модель двери была точным представлением?

Когда ответ к вышесказанному утвердительно, идти вперед и включить его. Когда ответ на тот же вопрос отрицательный, я бы предпочел не делать этого.

Я уже ответил на это в на другой вопрос

Объекты кода не связаны с материальными реальными объектами; это просто конструкции, которые хранят связанную информацию вместе.

Не верьте тому, чему учат в книгах / школах Java об объектах; они лгут.

Просто напишите что-нибудь, что выполнит работу, даже если это уродливо, а затем непрерывно проводите рефакторинг:

• устраните повторяющийся код ( не повторяйте себя )
• увеличить сцепление
• уменьшить сцепление

Но:

• не переусердствуйте; будь проще
• не пиши ничего тебе не понадобится

Если ты не получишь массовый (и бесполезная) иерархия классов, тогда вы хорошо поработали, создав элегантный и чистый код.

Помните: ООП - это средство, а не цель.

Есть теория, а затем есть практика ... а затем вы, как инженер-программист, пытаетесь сбалансировать их обоих.

Теоретически, вы должны делать объекты практически всем, пока не упадете до наименьших возможных элементов, примитивных типов (булево, строковое, целое и т. Д.). Ну ... это довольно упрощенно, но с этим редко случается ...

, то есть ...

до тех пор, пока вы действительно не создадите (то есть кодируете классы) вещь.

На практическом конце спектра вы можете определить все в одном большом классе и покончить с этим ... то есть ... до тех пор, пока вам не придется определять тонкие изменения в поведении (внешняя дверь, дверь гаража, дверь собаки и т. Д.) ).

Мой подход состоит в том, чтобы обычно начинать с одного большого класса (уродливо, но это быстро, чтобы кодировать, и я могу получить рабочий прототип быстрее). Затем, если мне когда-либо понадобится определить настройки или новое поведение или повторно использовать какую-то часть целого, тогда я создаю наименьший элемент и реорганизую большой элемент, чтобы использовать меньший элемент вместо определения его собственных атрибутов.

Например. Я кодирую класс двери, и оттуда я могу создать (создать экземпляр) столько дверей, сколько захочу, но они все одинаковые и ведут себя одинаково. Теперь я понимаю, что мне нужно также определить окна, которые вращаются вокруг петель ... подождите ... двери также имеют петли. Здесь я создаю класс петли, который может использоваться как дверью, так и окном, и удаляю любой способ, который у меня был до того, как определить шарнир в классе двери. Затем продолжайте работать до тех пор, пока я не столкнусь с ситуацией, когда я смогу повторно использовать некоторые детали в нескольких объектах (дескриптор, рамка и т. Д.).

• Никогда не сверлите объект, пока вы не должны, но ...
• Никогда не дублируйте код, который можно использовать повторно.

С этим эмпирическим правилом я могу быстро получить код, и обычно он сходится к уровню детализации, достаточному для удовлетворения потребностей.

Затем, имея опыт, вы получаете четкое представление о глубине, когда вы хотите, чтобы ваши объекты были гранулярными, без необходимости постоянно перефакторинг ваших объектов, что отнимает много времени. Однако я обнаружил, что ре-факторинг отнимает много времени, но не так много, как разработка самого проекта с самого начала. Рефакторинг практически неизбежен, поэтому лучше начинать рефакторинг рано и часто.

В любом случае ... мои два цента, надеюсь, это поможет.

Пока объект имеет только одну цель / ответственность, его не следует больше разделять (если только он не слишком большой, что не должно иметь место).

Создавайте предметы до тех пор, пока вы сможете делить их и завоевывать их. Если вы сделаете много мелких предметов, вы не сможете хорошо справиться со всеми. С другой стороны, несколько больших объектов не могут быть легко использованы повторно.

Мой совет: тренируйся! Во время практики вы получите представление о том, какая гранулярность вам нужна - для этого нет общего правила.

Вам также следует подумать о том, сколько подобъектов вам нужно. Дверь имеет одну ручку, а не четыре или пять и не список ручек. Также суб-объекты имеют свои собственные свойства? Цвет или материал важны? Тогда лучше держите ручку как отдельный предмет.

Я бы посоветовал вам подумать о том, как вы собираетесь его использовать. Подумайте, какие операции вам придется делать с вашей «вещью», а затем подумайте, что будет самым простым способом сделать это. Иногда будет проще сделать его свойством другого объекта, иногда будет проще сделать его новым собственным объектом.

Универсального рецепта не существует, может быть много факторов, которые делают одно решение лучшим. Просто рассмотрите каждый случай отдельно.

Добавлено: Чтобы привести пример с дверью / дверной ручкой / замочной скважиной - что вы будете делать с замочной скважиной? Вот некоторые факторы, которые делают логичным сделать замочную скважину отдельным объектом:

• Вы хотите сохранить многие свойства замочной скважины, такие как размер, форма, направление, количество штифтов, может ли ключ повернуть один или два раза и т. д .;
• На дверной ручке может быть несколько замочных скважин;
• Вы хотите задать замочную скважину только для чтения (например, заблокирована она или нет). и затем разрешать изменять их только с помощью определенных методов (например, метод «разблокировать», который принимает в качестве параметров объект «ключ»);
• Замочные скважины хранятся в отдельной таблице БД, по одной замочной скважине на строку БД (затем может иметь смысл сделать объект замочной скважины, имитирующий структуру БД);
• В вашей системе есть методы, которые были бы элегантно реализованы, если бы они могли использовать замочную скважину в качестве параметра;

Сценарии для придания ему свойства противоположны:

• У каждой дверной ручки может быть только одна замочная скважина, и она имеет только одну или очень мало правильных связи;
• замочные скважины хранятся вместе с дверными ручками в БД;
• Обычно вас не волнует только замочная скважина, вы просто хотите, чтобы она описывала свойство дверной ручки (например, или не существует);

Как гласит старый клише, «объекты должны быть существительными». Каждый раз, когда вы обнаруживаете, что думаете о предмете , он, вероятно, должен быть объектом. Каждый раз, когда вы обнаруживаете, что думаете о действии, вероятно, это должна быть функция или метод.

Конечно, есть исключения из вышеуказанных правил, и реальность может быть немного более сложной. Тем не менее, это, вероятно, лучшее место для начала, чтобы начать думать о концепции.

В большинстве случаев дверная ручка будет отдельным объектом, который может быть назначен дверному объекту.

Чрезмерное использование объектов скажет:
Есть объект для замка, для каждого цвета есть свой цветной объект («коричневатый» для двери, «серебристый» для замка и ручки), и материальные предметы («дерево» для двери и «сталь» для ручки и замка)
Здесь вы можете увидеть разницу между классом и объектом:

Класс - это абстрактная (не в смысле языка программирования) форма чего-либо. Вы можете назвать что-нибудь ручкой, и все знают, что это такое. Вы знаете, что ручка имеет цвет и материал.

Если вы покупаете ручку, у вас в руке есть конкретная ручка-предмет определенного цвета и материала. Теперь вы можете изменить цвет объекта ручки, например, покрасить его в черный цвет.

Но есть большая разница в программировании объектов и реальных объектов. Эти базовые примеры помогают понять только базовые принципы ООП. Вы должны освободиться от этого очень скоро!

(Для тех, кому интересно: прямоугольник - это квадрат или квадрат - прямоугольник?)

Один из способов узнать, когда вам нужно создать объект, а когда нет, - это написать краткое описание того, что вы пытаетесь выполнить, простым языком. Если вы счастливы, что вам удалось выразить проблему в своем описании, вы можете выбрать объекты из этого текста в качестве классов-кандидатов. Затем удалите те, которые явно не нужны.

Конечно, вы обычно добавляете гораздо больше классов в свой SW, и вы все равно удаляете некоторые, которые вы выбрали таким образом, но это отправная точка, которую я часто использовал. Обычно после этого я рисую грубую ER-диаграмму, которая уточняет, какие классы мне нужны. Я также смотрю на классы-кандидаты на предмет сходства с целью наследования.

Так что, если вы чувствуете необходимость объяснить замочную скважину в своем кратком описании, то это хороший кандидат для класса.

Другой способ посмотреть, является ли дверная ручка взаимозаменяемой. Я бы сделал дверную ручку отдельным объектом, который является собственностью двери. Возникает вопрос, хотите ли вы сделать дверную ручку частным классом, если только дверь может иметь эту ручку. Я лично предпочитаю не использовать здесь частный класс, но это вполне законная возможность. Используя отдельный объект в качестве свойства двери, вы теперь можете перемещать этот экземпляр ручки с одной двери (экземпляра) на другую (например, меняя ручки с одной двери на другую в вашем доме).

Еще один интересный аспект это расширяет вашу иерархию ... У вас могут быть необычные ручки, запираемые ручки и т. д., которые можно реализовать, расширив вашу базовую дверную ручку.

В общем, если вам нужно больше информации от него, чем просто одна вещь (не только состояние ручки, но также ее цвет, ее точное местоположение, есть ли у нее паз для ключа, возможность изменять его состояние / поведение и т. д.), а затем сделать его объектом. Таким образом, если вы не можете сохранить всю информацию, которую дверь должна знать о ручке, в простой String , Number или Boolean , сделайте это fullworthy Ручка .

Как и везде, есть и «угловые футляры». Я часто вижу это с парами. Два свойства, связанных друг с другом, но обычно ни с чем другим. Они не всегда сгруппированы в отдельный объект реального мира. Например, sortDirection и sortField . Принадлежат ли они к их собственному объекту, зависит от того, что представляет родительский объект. Это сортируемая реализация List ? Хорошо, оставь это там. Это Дверь ? Что ж, я бы, может быть, вынес бы это на внешний вид.

Решая, является ли что-то объектом или нет, спросите себя, имеет ли оно следующее ...

Состояние

Есть ли у кандидата значимое состояние? Если это не так, то все методы в нем, скорее всего, слабо связаны. В этом случае вы, вероятно, определили библиотеку модуля многократно используемых функций.

Поведение

Действительно ли объект что-то делает в домене? Например, он просто заполнен средствами доступа, которые манипулируют структурой или записью.

Идентификация

Действительно ли объект существует в домене как идентифицируемая сущность? Есть ли какой-то врожденный аспект сущности, который отличает ее от других подобных сущностей? Дверная ручка является примером - на самом деле у нее нет идентичности, поскольку одна дверная ручка, вероятно, будет такой же, как другая.

Если вы ответите «нет» на некоторые из них, то, вероятно, у вас нет объекта - и это нормально, библиотека или модуль могут быть ценным артефактом многократного использования

Прежде всего, не беспокойтесь об этом ...

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

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

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

Это имеет смысл в 80-е годы, когда пользователей было не так много, а размер баз данных был не слишком велик. В то время было полезно хранить индексы и таблицы в разных физических томах.

Теперь есть логические тома, рейды и так далее, и нет необходимости хранить индексы и таблицы в разных табличных пространствах.

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

Объект - это структура данных, объединенная с набором методов, которые могут работать с этой структурой данных. Свойства объекта содержат состояние объекта, а методы работают с состоянием.

Какое состояние системы вы пытаетесь смоделировать? Присутствует ли это в двери, ручке или в какой-то их комбинации?

Есть некоторые методологии, которые пытаются четко определить объектную модель до начала кодирования. Другие методологии (например, TDD) позволяют объектной модели проявляться в процессе кодирования. В вашем случае я бы рекомендовал кодировать некоторые приложения малого и среднего размера с использованием TDD, так что вы можете увидеть преимущества и недостатки различных моделей. Редко есть один «правильный» способ смоделировать данную ситуацию, но некоторые модели намного проще использовать и понимать, чем другие; Распознавание шаблонов, применимых к ситуации, которая находится перед вами, приходит с опытом.

Итак, итоги: создавайте много моделей. Подумайте о доменах приложений, смоделируйте их и код. При этом все станет намного яснее. Сделайте песочницу и прыгайте.

моделируйте их и кодируйте. При этом все станет намного яснее. Сделайте песочницу и прыгайте.

моделируйте их и кодируйте. При этом все станет намного яснее. Сделайте песочницу и прыгайте.

Это немного зависит от использования. В качестве примера: если дверная ручка является важной частью и может (потенциально) использоваться на другой двери (или другая ручка может использоваться для «этой»), то, вероятно, это должен быть объект.

Если на С другой стороны, он нужен только для того, чтобы позволить вам открывать и закрывать дверь, он должен быть просто частью дверного объекта.

Хрестоматийный способ определения гранулярности объекта состоит в том, чтобы идти путем связности.

Если большинство методов вашего объекта работает с большинством полей объекта, то объект достаточно мал ( Для данного значения «большинство»).

Объект почти никогда не бывает слишком маленьким.

Все является объектом. От кварков до электронов, атомов и элементов, пыли, людей, автомобилей, мира и вселенной.

Даже мысли, идеи или чувства являются объектами.

(Пока что очевидный ответ)

Приходя к " решение, какие дезертиров быть объектом »; Я знаю это так просто, как , должно ли оно вести себя каким-либо образом и будет ли оно использоваться более одного раза .

Как только вы используете что-либо более одного раза, это стоит быть функцией или даже объектом.

Кроме того; будет ли он повторно использован другими вещами? (Объекты, проекты, программы и т. Д.) Вот какие мысли возникают у меня, когда я решаю, что должно, а что не должно быть объектом.

Но, как я сказал выше, вопрос тривиален, поскольку все сам по себе является объектом.

Старый добрый Платон уже получил ответ (вроде) ...

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

Это объект, если вам нужно думать о нем как о ... объекте.

То есть, если вам нужна абстракция.

"Ключевое отверстие" в вашем пример может быть описан на разных уровнях абстракции, и только последний из списка вы, вероятно, назвали бы «объектом»:

1) Может быть логическим свойством, если вам просто нужно знать, что у вашей двери он есть:

---

class Door
{
    bool HasKeyHole;
}

---

2) Это может быть пара координат, если вы просто хотите нарисовать дверь и поставить кружок вместо ключевой дыры

---

 class Door
 {
    Point KeyHoleCoordinates;
 }

---

3) Может быть специально определенный класс KeyHole , если вы хотите инкапсулировать логику и некоторые свойства ключевой дыры и работать с ними вместе, возможно, передав их или разрешив взаимодействие с ключом

---

class KeyHole
{
    Point Coordinates;
    bool OpensWithKey(Key key);
}

class Door
{
    KeyHole Hole;
}

---