L>Ага. Вот так вот и рождаются монстры, когда класс "автомобиль" наследует классы "двигатель" и "кузов седан", которые, в свою очередь, наследуют кучу других классов.
Так это неправильно. Автомобиль является агрегатом из двигателя, кузова и прочей хрени, но никак не потомком кузова или двигателя.

G>Если аналитики и архитектор начинает "описывать объекты реального мира", то их сразу надо уволить, ибо пользы они не приносят.

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

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

Здравствуйте, SkyDance, Вы писали:

G>>Если аналитики и архитектор начинает "описывать объекты реального мира", то их сразу надо уволить, ибо пользы они не приносят.

SD>Если они не могут найти и проанализировать взаимодействие объектов реального мира, нет никаких шансов на то, что не появятся "автомобили, наследники двигателя" и прочие чудеса.
Да при чем тут объекты реального мира, как они помогут?

Вот у тебя есть проблема — надо выкопать яму. Приходит аналитик и начинает описывать объекты "земля", "заказчик" хз что еще, а потом архитектор, не зная, что за проблема начинает придумывать методы объектам "земля" и так далее.
А надо было всего-то экскаватор нанять.

Очень мало решений реальных проблем можно получить анализируя "объекты реального мира".

Яркий пример показывают различные системы учета (бухгалтерии), там обычно есть периоды, операции закрытия итп. А на практике надо уметь быстро получать оборот за любой период, что решается материализованными представлениями.
Излишний фокус на "реальном мире" только мешает.


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

G> А если ты создаешь систему для пользователей, то надо сначала персоны и сценарии, потом код, их реализующий, а потом только искать общность создавая классы и объекты.

О, вот видишь. С третьего раза ты тоже смог понять, от какой печки плясать при моделировании комнаты.

Большинство кандидатов в лучшем случае останутся на уровне "вот объект класса стул, у него свойства — цвет, размер, и метод 'упасть на пол'".

Здравствуйте, SkyDance, Вы писали:

G>> А если ты создаешь систему для пользователей, то надо сначала персоны и сценарии, потом код, их реализующий, а потом только искать общность создавая классы и объекты.

SD>О, вот видишь. С третьего раза ты тоже смог понять, от какой печки плясать при моделировании комнаты.
Моделировать можно что угодно, только не нужно оно. Зачем тебе моделировать машины, когда ты делаешь систему автоматизации подбора и продажи зачастей?

SD>Большинство кандидатов в лучшем случае останутся на уровне "вот объект класса стул, у него свойства — цвет, размер, и метод 'упасть на пол'".
Без контекста задачи это может быть вполне правильным ответом.

G>Моделировать можно что угодно, только не нужно оно. Зачем тебе моделировать машины, когда ты делаешь систему автоматизации подбора и продажи зачастей?

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

G>Без контекста задачи это может быть вполне правильным ответом.

Может и быть. Все собеседование и нужно для того, чтобы дать контекст и посмотреть, как будет вести себя кандидат. Это, конечно, сложнее, чем выдать бумажку с гномиками или очередной тест "выберите правильные ответы". Зато и информации даёт больше. Обеим сторонам.

Здравствуйте, SkyDance, Вы писали:

G>>Моделировать можно что угодно, только не нужно оно. Зачем тебе моделировать машины, когда ты делаешь систему автоматизации подбора и продажи зачастей?
SD>Чтобы продемонстрировать процесс мышления. На собеседовании я не жду от кандидата немедленной выдачи на гора правильного решения наших задач.
Единственно правильный процесс мышления — узнать какая проблема должна быть решена, прежде чем чего-то выдумывать.
Все остальное — однозначно no hire для аналитиков или архитекторов.

G>>Без контекста задачи это может быть вполне правильным ответом.
SD>Может и быть. Все собеседование и нужно для того, чтобы дать контекст и посмотреть, как будет вести себя кандидат. Это, конечно, сложнее, чем выдать бумажку с гномиками или очередной тест "выберите правильные ответы". Зато и информации даёт больше. Обеим сторонам.
Еще раз: правильное поведение — узнать больше о решаемой проблеме. Все остальные варианты на практике нежизнеспособны.

G>Отличный пример далеких от практики вопросов. Чуть более чем 100% уверен, что ответы на эти вопросы не пригодятся в работе, а подавляющее большинство соискателей тупо гуглят такие задачки перед собеседованиями.

Ну если за ответами на такие вопросы приходится в гугл лезть, то стоит подумать — а может программирование не для тебя?

Здравствуйте, gandjustas, Вы писали:

D>>Или — есть массив из миллиона элементов. Каждый элемент — число от 0 до 100. Как сортировать будете?

G>Отличный пример далеких от практики вопросов. Чуть более чем 100% уверен, что ответы на эти вопросы не пригодятся в работе, а подавляющее большинство соискателей тупо гуглят такие задачки перед собеседованиями.

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