miron_baton, к Вам дальнейший комментарий не относится, Вы любитель. И извиняюсь за оффтоп.
Еще раз убедился, какой же низкий уровень у большинства программистов.
Один не видит дерева, другой не видит проблемы у третьего паттерны бесполезная вещь.
Вы что, товарищи, совсем не разбираетесь? Начальниками рано стали? Кто-нибудь работает программистом из прокоментировавших?
А, один работает, сорри.

Теперь по теме. Общий каркас - типичное дерево, однако есть один нюанс. Как вы пишете у каждого класса помещения, которые должны безусловно наследоваться от одного предка, есть набор уникальных свойств, которые, естественно надо как то обрабатывать. Еще проблема, что более крупные комнаты состоят из более мелких но тем не менее трактуются как тоже комнаты.
Первую проблему можно решить двумя способами, либо все мыслимые свойства включить в общий предок, что не есть хорошо, либо использовать паттерн "Декоратор" и добавлять свойства уже непосредственно объекту.
Вторую проблему может решить паттерн "Компоновщик".
Но это так, навскидку. Могут быть варианты в зависимости от ТЗ.

ViPRos, я не настаиваю на званиях. Просто книжки читаю. Иногда.
ТС, уточните ТЗ. А именно, что в проекте подвергалось в процессе наибольшим изменениям. Исходя из этого можно подобрать паттерн. Ведь именно для этого они и нужны. И так как разработка уже некоторое время велась, то это должно быть известно. Что переделывали (дорабатывали) чаще всего?

ViPRos, этот паттерн меня не устраивает квалификацией представителя. Позовите того кто это разрабатывал.

ViPRos, тогда два вопроса.
Вы всерьез не видите дерево на рисунке ТС?
Вы действительно не понимаете различия в иерархии часть-целое и иерархии наследования?

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