Возможно ли более OO?

is it possible to over object-orient your code

да

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

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

Да, конечно, есть :-) объектно-ориентированные методы - это инструмент ... если вы используете неправильный инструмент для данной работы, вы будете чрезмерно усложнять вещи (подумайте о ложке, когда все, что вам нужно, это нож).

Для меня я сужу «сколько» по размеру и масштабам проекта. Если это небольшой проект, иногда он добавляет слишком много сложности. Если проект большой, вы все равно будете брать на себя эту сложность, но она окупится простотой обслуживания, расширяемости и т. д.

Да, это определенно возможно - тоже обычное дело. Однажды я работал с парнем, который создал структуру данных для привязки к раскрывающемуся списку, чтобы он мог позволить пользователям выбирать пол. Да, это было бы полезно, если бы список возможных полов изменился, но пока этого не произошло (мы не живем в Калифорнии).

Мой совет - не зацикливаться на этом. Обычно это приводит к чрезмерному или недостаточному выполнению ЧТО-ТО (если не ОО). Эмпирическое правило, которое я обычно использую, таково: если это облегчает понимание проблемы, я использую объект. Если другая парадигма облегчает мне понимание, чем если бы я использовал объект, я использую это.

Эта стратегия еще не подводила меня.

Я предполагаю, что это возможно, но сложно ответить вам абстрактно (без каламбура). Приведите пример более ОО.

Да. См. Концепцию «золотой молотокантипаттерн»

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

Если вы думаете, что больше объектов более объектно-ориентировано, тогда да.

При объектно-ориентированном дизайне необходимо уравновесить несколько факторов. Большая часть объектно-ориентированного проектирования направлена ​​на снижение сложности и управление ею. Итак, если вы получаете очень сложные решения, вы не делаете слишком много объектно-ориентированного подхода, но делаете это неправильно.

Да, точно так же, как можно перенормировать проект базы данных.

Похоже, это один из тех дебатов пуристов и прагматиков, которые никогда не закончатся. <: S

Многие люди пытаются спроектировать свой код для максимальной гибкости и повторного использования, не задумываясь о том, насколько это вероятно. Вместо этого разбейте занятия на группы в зависимости от программы, которую вы пишете. Если у вас будет ровно один экземпляр определенного объекта, вы можете подумать о его слиянии с содержащим его объектом.

Да и это просто. Код лучше не просто потому, что он объектно-ориентирован, не больше, чем просто потому, что он модульный или функциональный, или общий, или генеративный, или основанный на потоках данных, или аспектно-ориентированный, или что-то еще.

Хороший код - это хороший код, потому что он хорошо продуман в своей парадигме программирования.

Хороший дизайн требует ухода.

Чтобы быть осторожным, нужно время.

Пример для вашего случая: я видел ужасающие фрагменты Java, в названии которых будучи «объектно-ориентированным», каждый класс реализует некоторый интерфейс, даже если никакой другой класс не будет реализовывать этот интерфейс Когда-либо. Иногда это взлом, а в других - совершенно бесплатно.

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

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

Я думаю, что четкий ответ - да, но в зависимости от домена, о котором вы говорите, это может быть ДЕЙСТВИТЕЛЬНО да или меньше, так что да. Если вы создаете приложения высокого уровня .Net или Java, то я думаю, что это последнее, поскольку объектно-ориентированный подход в основном встроен в язык. С другой стороны, если вы работаете над встроенными приложениями, то опасность и вероятность того, что вы закончили OO'ing, высоки. Нет ничего хуже, чем видеть, как человек действительно высокого уровня входит во встроенный проект и чрезмерно усложняет вещи, которые, по их мнению, уродливы, но являются наиболее простыми и быстрыми способами сделать что-то.

Я думаю, ваш вопрос должен быть следующим: "Можете ли вы улучшить архитектуру своего приложения?"

И, конечно, ответ еще есть. ОО - это просто подход к дизайну. Если вы тратите свое время на создание ненужной сложности в системе, потому что «Полиморфизм качается!». Тогда да, может быть, вы закончили OOing.

Самый ответ XP - Независимо от того, какой подход вы предпочитаете (объектно-ориентированный, процедурный и т. д.), Дизайн должен быть настолько сложным, насколько это очевидно необходимо..

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

is it possible to over object-orient your code?

Нет. Но можно чрезмерно усложнить ваш код. Например, вы можете использовать шаблоны проектирования ради шаблонов проектирования. Но вы не можете чрезмерно объектно-ориентироваться в своем коде. Ваш код либо объектно-ориентирован, либо нет. Так же, как ваш код либо хорошо разработан, либо нет.

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