Мне не нравится данное решение, потому что мне не нравится сам подход хранения ссылок друг на друга. Это типичное отношение многие-ко-многим (человек может иметь много домашних животных и домашнее животное может иметь много хозяев). В реляционных БД в таких случаях заводится третья таблица и отношение многие-ко-многим сводится к двум отношениям один-ко-многим. В реальности отношение человека с домашним животным является внешней характеристикой по отношению к ним обоим: нельзя сказать, что наличие/отсутствие домашнего животного это неотъемлемая характеристика человека. Наличие животного это не цвет глаз. Может ещё ссылку на перочинный ножик в Human положить? Класс Person/Human/Whatever не должен иметь поля, указывающего на животных или указывающего на отсутствие животных.
Я думаю, что ваш подход ещё вызовет у вас головную боль и предлагаю одуматься:
class Person
{
};
class Pet
{
};
class PetOwnerRelations
{
public:
vector<Pet*> petsOfOwner(Person* owner);
vector<Person*> ownersOfPet(Pet* pet);
};
наиболее легко понятным человеку, который видит его впервые в жизни!
Да, а с увеличением времени работы с кодом человек всё хуже бы в нём разбирался? )
Это было бы просто идеально для работодателя! Можно было бы менять программистов как перчатки!
К тривиальным условиям вопросов нет. Я про те условия, логика которых не всегда может быть понятна из контекста.
Этот метод рано или поздно пригодится, поверьте. Я видел, как серьёзнейшие программисты копипастили подобные условия в другие методы. Я ещё ни разу не пожалел, что вынес в метод тривиальное условие, даже встречающееся только один раз в классе. Иногда бывает трудно определить, в какой момент условие перестает быть тривиальным, и я перестраховываюсь. Тем более трудно предсказать, когда оно понадобится (я же не Нострадамус). «Ой, надо добавить условие; хмм, кажется в каком-то методе оно встречалось; а черт с ним заново напишу; а нет, нашел, ctrl+c, ctrl-v.» И опять, я выношу метод, чтобы все вызовы внутри находились на одном уровне абстракции. И он мне совсем не мешает, он обычно константный, лежит себе спокойно в подвале cpp-файла.
Когда «всё красиво», то и изменения делать легче.
При создании прототипа вы всё равно используете примерно те же абстракции, что и в готовом коде. Некоторые части кода прототипа можно будет спокойно перенести в готовый код.
Я просто сам не очень люблю читать длинные статьи и придерживаюсь идеи, что статью можно считать законченной, когда из неё ничего нельзя выкинуть. Хотя эта статья — капля в море, безусловно.
Спасибо! Первый раз узнал про этот ресурс.
Я вообще обожаю, когда мне удаётся без изменения логики сократить объём кода или улучшить читаемость или упростить/улучшить архитектуру.
А при каких условиях может вообще появиться не константный Get?
Если используешь стороннюю библиотеку или просто модуль, написанный кем-то другим, кто не использует const'ы.
не нравится — не ешь
Согласен.
От себя маленькое добавление. Лично мне нравится избыточность богатство возможностей, предоставляемое этим языком. C++ имеет недостатки, но надо понимать, что C++ создан из компромиссов между требованиями к производительности, совместимости, переносимости, идеологией zero-overhead и т.д. В C++ ничего не добавлялось просто так. Устраняя избыточность, обязательно будешь жертвовать чем-либо (обычно производительностью).
В любом случае, С++ может быть таким, каким захочешь, ведь никто не запрещает использовать «неизбыточный» C++ в виде фреймворков, таких как Qt. «you can be my princess, or you can be my whore»
Каждая новая фича сопровождается подробным объяснением, для чего она нужна. И, опять-таки, zero-overhead позволяет не знать об этой фиче до тех пор пока не наткнешься на проблему, которая с помощью этой «избыточной» фичи решается тривиально.
Я высказал своё мнение по-подробнее в этом комментарии
Я думаю, что ваш подход ещё вызовет у вас головную боль и предлагаю одуматься:
Да, а с увеличением времени работы с кодом человек всё хуже бы в нём разбирался? )
Это было бы просто идеально для работодателя! Можно было бы менять программистов как перчатки!
Этот метод рано или поздно пригодится, поверьте. Я видел, как серьёзнейшие программисты копипастили подобные условия в другие методы. Я ещё ни разу не пожалел, что вынес в метод тривиальное условие, даже встречающееся только один раз в классе. Иногда бывает трудно определить, в какой момент условие перестает быть тривиальным, и я перестраховываюсь. Тем более трудно предсказать, когда оно понадобится (я же не Нострадамус). «Ой, надо добавить условие; хмм, кажется в каком-то методе оно встречалось; а черт с ним заново напишу; а нет, нашел, ctrl+c, ctrl-v.» И опять, я выношу метод, чтобы все вызовы внутри находились на одном уровне абстракции. И он мне совсем не мешает, он обычно константный, лежит себе спокойно в подвале cpp-файла.
Совершенно верно! Надо было мне это вынести в заголовок, а содержимое поста оставить пустым )
Ну да, бывает и такое (может это даже я). Но вообще абстракции нужны для того, чтобы как раз не продираться, когда не надо.
Я люблю C++
А так, в общем-то, ничего )
И вам спасибо!
При создании прототипа вы всё равно используете примерно те же абстракции, что и в готовом коде. Некоторые части кода прототипа можно будет спокойно перенести в готовый код.
И спасибо, за «З.Ы.» )
Я вообще обожаю, когда мне удаётся без изменения логики сократить объём кода или улучшить читаемость или упростить/улучшить архитектуру.
Если используешь стороннюю библиотеку или просто модуль, написанный кем-то другим, кто не использует const'ы.
Согласен.
От себя маленькое добавление. Лично мне нравится
избыточностьбогатство возможностей, предоставляемое этим языком. C++ имеет недостатки, но надо понимать, что C++ создан из компромиссов между требованиями к производительности, совместимости, переносимости, идеологией zero-overhead и т.д. В C++ ничего не добавлялось просто так. Устраняя избыточность, обязательно будешь жертвовать чем-либо (обычно производительностью).В любом случае, С++ может быть таким, каким захочешь, ведь никто не запрещает использовать «неизбыточный» C++ в виде фреймворков, таких как Qt. «you can be my princess, or you can be my whore»
Каждая новая фича сопровождается подробным объяснением, для чего она нужна. И, опять-таки, zero-overhead позволяет не знать об этой фиче до тех пор пока не наткнешься на проблему, которая с помощью этой «избыточной» фичи решается тривиально.