Турникет А большую пропустит, маленькую - нет. Турникет Б - пятнистую пропустит, не пятнистую - нет

Любой объект имеет конечное кол-во свойств.

Т.е вы предлагаете турникету знать о всех свойствах всех объектов ? Правильно понял ?

Набот этих свойтсв определяет уникальность данного типа чемоданов/тележек.

Турникету не нужны все свойства, а только те которые определяют allow/denied

Ага. У кошки это цвет. У самолета это размер. У единорога это рог.

Т.е ваш вариант это вариант 1 из моего вопроса?

Мое мнение - варинат 1. У себя делал бы так. Через Voters все бы решилось на раз-два

Ну вот вотеры пропагандируют вариант 1.

Но сдаётся мне тут нарушается инкапсуляция данных объекта.

1. Турникет умеет открываться и закрываться. Этого достаточно.
2. Кошка и прочие умеют подходить к турникету и запускать процесс пропуска. Если открылся - умеют проходить.
3. После инициации процесса, некий "менеджер турникета" начинает по очереди обходить все существующие правила и спрашивать у каждого "умеешь валидировать объект X?"
4. Если валидатор нашелся, то передаешь ему объект и он (валидатор), возвращает менеджеру решение - пропускать или нет.
5. Менеджер открывает турникет или нет

Каждое правило - отдельный класс интерфейса "TurnuketValidatorIntefrace"

Правила загружаются в менеджера через DI. Например через tagged_iterator

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

Осталось должаться человека которые предложит еще и вариант 2 - и можно считать что воскресный разговор прошел в тихой дружеской обстановке

Т.е вы за 3-й?

Нет. У вас там написано, что есть тот, кто всё про всех знает. Мой менеджер ничего ни про кого не знает, он делегирует валидацию другим. Это разное

Он только открывает турникет. А решение делегируется валидаторам

Валидатор будет знать про сам объект и для чего валидировать т.е турникет

Open-close принцип соблюден