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

Ответ 1

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

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

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

Правило большого пальца:

• Если это, о чем вы думаете, имеет более одного атрибута, определите класс
• Если это, о чем вы думаете, имеет какое-то поведение, определите класс
• Если это, о чем вы думаете, может расти или расширяться, определите класс
• Если это то, о чем вы думаете, должно быть сопоставимым, сопоставимым, определить класс
• Если вы не уверены, определите класс;)

Edit

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

Ответ 2

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

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

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

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

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

Ответ 3

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

Государство

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

Поведение

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

Идентичность

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

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

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

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

Ответ 4

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

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

Ответ 5

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

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

Ответ 6

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

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

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

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

Сценарии для создания этого свойства противоположны:

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

Ответ 7

Учебный способ принятия решения о детализации объекта заключается в объединении.

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

Объект почти не слишком мал.

Ответ 8

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

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

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

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

class Door
{
    bool HasKeyHole;
}

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

 class Door
 {
    Point KeyHoleCoordinates;
 }

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

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

class Door
{
    KeyHole Hole;
}

Ответ 9

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

Ответ 10

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

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

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

Ответ 11

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

Как и везде, вы также имеете "угловые случаи". Я часто вижу это с парами. Две пророчества, которые связаны друг с другом, но обычно ни с чем другим. Они не всегда группируются в отдельный объект реального мира. Например sortDirection и sortField. Независимо от того, принадлежат ли они в своем собственном объекте, зависит от того, что представляет собой родительский объект. Является ли это сортируемой реализацией List? Ладно, держи его там. Это Door? Ну, я бы, возможно, внедрил его.

Ответ 12

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

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

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

Ответ 13

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

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

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

Ответ 14

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

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

что...

пока вы на самом деле не создадите (то есть код классов) вещь.

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

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

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

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

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

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

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

Ответ 15

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

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

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

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

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

Но:

• не переучивать; сохранить его простым
• не пишите материал вам не понадобится

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

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

Ответ 16

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

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

Ответ 17

Все можно сделать в объекте.

IMO, ответ на ваш вопрос - вопрос: является ли поведение ключевого отверстия, необходимое для того, чтобы моя модель двери была точным представлением?

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

Ответ 18

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

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

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

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

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

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

Ответ 19

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

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

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

Ответ 20

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

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

(Пока что для очевидного ответа)

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

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

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

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