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

Question

Я пытаюсь понять ориентацию объекта. Я немного понимаю, конечно, но иногда я не на 100% уверен. Как вы решаете, что следует превратить в объект (маленький объект - часть другого большого целого объекта) или что не стоит быть объектом, или, может быть, это должно быть просто свойство этого большого целого объекта?

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

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

Спасибо

Answer 1

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

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

Надеюсь, это немного помогло прояснить ваше замешательство.

Answer 2

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

Answer 3

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

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

то есть ...

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

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

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

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

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

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

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

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

Answer 4

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

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

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

Answer 5

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

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

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

Answer 6

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

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

Answer 7

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

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

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

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

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

Но:

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

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

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

Answer 8

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

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

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

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

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

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

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

Answer 9

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

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

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

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

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

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

Answer 10

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

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

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