Представлены эти два класса (вместе с бизнес-логикой и логикой доступа к данным) для проверки кода.Рецензент засмеялся, глядя на код, и посоветовал мне заново сделать уроки.Он сказал мне, чтобы я провел какое-то исследование и не дал мне никаких подсказок.
Плохой обзор, нет смысла заставлять вас искать его, особенно если вы действительно не видите ничего плохого в своем собственном коде.
Я не смог найти ничего плохого.Немного неловко выглядит, что «подменю» - это базовый класс, а не меню.Но мое требование таково ... меню состоит только из двух уровней (под-подменю никогда не будет).
Я не нахожу вашу реализацию смешной, но наивно, что есть такая вещь, как "никогда", довольно забавно.Если бы у меня была копейка за каждый раз, когда кто-то говорил, что что-то никогда не произойдет, и в конце концов это случилось, я бы стал на 15 пенсов богаче.
Если вы требуете, чтобы в меню было только дваУровни, не создавайте код, расширяющий это требование.Однако, если у вас есть возможность очень легко открыть свой код для будущего расширения, то почему бы не сделать это?Там нет затрат, просто выгода.И в вашем случае, я думаю, что «открытие для будущего расширения» действительно довольно просто.
Что в них смешного?Был бы признателен, если бы кто-то показал мне путь для улучшения этих классов.
Это не обязательно смешно или неправильно.Я бы сделал это иначе: если меню может содержать меню, не будет ли это композицией?И если да, в чем разница между меню и подменю?Подменю - это меню, в котором есть родитель, но должно ли оно заботиться?Должен ли он знать?На самом ли деле оно отличается от самого меню?
class Menu
+addSubmenu( Menu menu ) : Menu
+addItem( Item item ) : Menu
Так будет выглядеть моя попытка, вероятно.