#java #oop
#java #ооп
Вопрос:
Я работаю над немного сложной головоломкой для интервью. Я мало что знаю о лучших практиках в дизайне.
Я хочу написать один большой класс, который в первую очередь решит проблему. Затем я хочу разделить его на столько подклассов, сколько захочу.
Считается ли это хорошим способом в отрасли для создания хорошего дизайна?
Ответ №1:
Нет. Это не так.
Проектирование ваших объектов должно быть одним из ваших первых приоритетов, а не последним.
Хороший объектно-ориентированный разработчик рассмотрит проблему, решит, какие объекты необходимо создать, приступит к созданию этих объектов, а затем объединит их для решения более масштабной проблемы.
Если вы попытаетесь создать один гигантский класс, который выполнял бы всю работу сам по себе, вы получите очень тесно связанный код, который нельзя разбить на классы … но мог бы быть, если бы вы правильно разработали код заранее.
Комментарии:
1. Не обязательно. Если назначение действительно представляет собой головоломку, подобную некоторым проблемам с наймом, тогда имеет смысл разработать ключевой алгоритм таким образом, чтобы он не мешал вашему мыслительному процессу (псевдокод, python и т.д.), А Затем преобразовать этот прототип во что-то, что хорошо работает, хорошо выглядит и т.д. Беспокойство по поводу OO-дизайна может быть не самым эффективным первым шагом.
2. @scompt.com — Если бы OP задали вопрос об алгоритмах в интервью, я бы не ожидал, что они будут беспокоиться о том, чтобы сделать его надлежащим OO (поскольку большинство вопросов об алгоритмах сосредоточены на алгоритме). Это звучит как вопрос дизайна.
3. Вопрос интервью проверяет как логику, так и хорошие методы объектно-ориентированного проектирования. Головоломка основана на «Игре жизни Джона Конвея». Я разобрался с логикой.
4. Просто чтобы добавить к замечанию @ Justin, при таком подходе «большого класса» вам также будет сложнее исправлять ошибки компиляции и потенциальные баги на начальном этапе разработки.
Ответ №2:
Я постараюсь ответить с возможным подходом, который вы могли бы использовать. Сначала сформулируйте свою проблему в несколько предложений, которые вы хотите решить. В этих предложениях существительные являются вашими классами и переменными. Глаголы — это ваши методы. С этого момента вы можете начать писать свою первую версию кода
Ответ №3:
При написании кода для производства мой опыт показывает, что реальная практика находится где-то посередине. При проектировании системы придумайте классы, которые, по вашему мнению, вам понадобятся (смотрите Ответ Skyzer, чтобы узнать, как лучше подумать о разделении вещей). По мере реальной реализации вашего решения вы, вероятно, дойдете до того, что некоторые объекты станут слишком большими; будут выполнять слишком много. На этом этапе вы можете еще раз взглянуть на дизайн и посмотреть, сможете ли вы разбить объект на несколько объектов меньшего размера. Каждый объект должен отвечать за одну «вещь», но определение того, что такое «вещь», может меняться со временем, поскольку данная «вещь» становится более сложной.
Аналогично этому — написание методов / команд. Каждая команда должна делать что-то одно, и делать это хорошо. Для меня это означает, что легко писать тесты для этой команды, потому что тесты могут очень четко определять, что делает команда. Когда количество действий, выполняемых командой, становится слишком большим (хорошим показателем этого является большое количество логических ветвей, таких как if, вызывающих все больше и больше тестов), разбейте команду на несколько меньших, каждая из которых может быть протестирована.