Выход из процедурного мышления

Я программировал (как работу) примерно через 3-4 месяца после окончания университета, изучающего компьютерные вычисления.

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

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

Как долго/много практики, прежде чем вы сможете действительно правильно программировать, используя методы oop, в отличие от использования классов, заполненных процедурным кодом.

Кроме того, есть ли какие-либо рекомендации о том, как реально продвигаться, чтобы правильно проектировать решения проблем?

Ответ 1

Я думаю, что это просто требует много практики.

Некоторые люди говорят: ООП моделирует объекты реального мира. Но то, что они обычно говорят вам в школе тоже, и, как я понимаю из OP, это действительно не помогло.

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

Я думаю, что главная сложная часть ООП - это именно то. Вы не можете просто взглянуть на свою проблемную область, которая, например, касается автомобилей, и сказать: я знаю, мне нужен класс Car! Даже если вам нужен класс Car, это знание не поможет вам решить, что действительно положить в него. Очевидно, вы не можете просто положить все сотни тысяч функций, которые касаются автомобилей внутри этого класса. Итак, как вам это удается? Как отрезать его? Что должно отвечать классу Car? Кто также должен знать о классе автомобилей? Это трудные вопросы, на которые никто не может ответить, кроме автора самой программы. И даже самые опытные редко отвечают на все вопросы в первый раз.

Но я думаю, что есть некоторые общие принципы ООП, которые следует соблюдать. Держите coupling между объектами как можно ниже. Следуйте закону demeter. Принципы SOLID хорошо учитываются. Но самое главное: сохраните DRY полностью.

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

Ответ 2

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

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

Ответ 3

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

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

Как долго/много практики, прежде чем вы сможете действительно правильно программировать, используя методы oop, в отличие от использования классов, заполненных процедурным кодом.

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

Кроме того, есть ли какие-либо рекомендации о том, как реально продвигаться, чтобы правильно проектировать решения проблем?

Я настоятельно рекомендую прочитать эти 2 "книги" S.O.L.I.D. принципов и 31 дня рефакторинга. Один из SOLID очень хорош в аспектах дизайна кода, особенно в гибкой среде. Рефакторинг помогает вам определить возможности улучшения в существующем коде.

Ответ 4

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

Ответ 5

Глядя на Численные рецепты в C, вы получите процедурное программирование. Функциональные вызовы с бесконечными списками параметров, управление потоком программ распространяется по многим процедурам. Возьмите простой алгоритм, такой как "Runke-Kutta" и поместите его на язык OOP по вашему выбору. Инкапсуляция и передача сообщений - это совершенно другое мышление.

OOP - это, как уже сказал TokenMacGuy, "взаимодействие объектов реального мира". В то время как процедурное программирование больше фокусируется на "алгоритмах".

Одним из шагов в обучении ООП является способность трансформировать/моделировать объекты реального мира в свойства и методы класса. Такие книги, как "Эффективная Java", "Шаблоны реализации", GoF помогают вам выбирать лучшие практики, ставя объекты реального мира в код.

Ответ 6

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

Ответ 7

Внедрить COM-объекты в C, и вы поймете разницу между ООП и процедурной...

Кстати, изучение объектных моделей (например, COM, но это так 1995...) - хороший способ понять превосходство ООП по модульности. Возьмите свою любимую огромную библиотеку (Qt - хорошее начало, если вы в С++ или python), и читайте документы, пишите небольшие программы.