Циклы в программном обеспечении для семейных деревьев

Расслабьте ваши проверки.

Не необходимо менять правила, которые, вероятно, очень полезны для 99.9% ваших клиентов, чтобы помочь им избежать ошибок при вводе данных.

Вместо этого измените сообщение об ошибке "нельзя добавить связь" на предупреждение с опцией "добавить все равно".

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

Насколько я знаю, даже христиане принимают браки (и, следовательно, детей) между двоюродными братьями и сестрами, что превращает семейное дерево в семейный DAG.

Вывод из этого: выбирайте правильные структуры данных.

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

Это непростая задача. Если вы хотите сохранить структуру дерева, я предлагаю сделать следующее:

Представьте, что A имеет детей с собственной дочерью.

A добавляет себя в программу как A, так и B. Однажды в роли отца, давайте назовем его бойфрендом.

Добавьте функцию is_same_for_out(), которая сообщит части вашей программы, генерирующей вывод, что все ссылки, идущие к B, должны перенаправляться на A при отображении данных.

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

Исходя из этого, вы можете работать над синхронизацией кода между A и B, чтобы избежать несоответствий.

Это решение, конечно, не идеально, но может служить первым шагом.

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

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

Это одна из причин, почему такие языки, как "Go", не имеют встроенных утверждений (assertions). Утверждения используются для обработки случаев, о которых вы, вероятно, не подумали, и слишком часто это происходит. Вы должны утверждать лишь то, что невозможно, а не просто маловероятно. Утверждение маловероятного — это то, что портит репутацию утверждений. Каждый раз, когда вы пишете assert(, отдохните десять минут и действительно подумайте об этом.

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

Утверждать, что ваш пра-пра-пра-дедушка был вашим отцом, как невозможное, — это разумно.

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