Как использовать ооп на практике?

Вот выучил я что такое классы, объекты, наследование и т.п. А как его использовать на практике не пойму(когда php выучил также было)...
Есть два своих проекта написанных процедурно, но хотелось бы их под ооп переделать. А как процедурный код превратить в ооп'шный я хз. Желательно для начала без mvc или эти вещи неразрывно связаны? Как вы научились этому? К фреймворкам потом доберусь.
  • Вопрос задан
  • 1719 просмотров
Решения вопроса 4
@Wentixon
ООП гораздо сложнее чем ты думаешь. Самый оптимальный способ изучить его это делать проекты на современных фреймворка и изучать сами эти фреймворки и разбираться, почему разработчики сделали именно так. Паттерны, solid поизучай. Это необходимо, иначе ты будешь делать не ооп а какую то пародию, которая скорее будет создавать проблемы, чем решать их
Ответ написан
@red-barbarian
Ну прежде всего понять, что есть две (точнее больше) парадигмы. ОО и процедурная.
Это типы мышления. Первая это разбивать систему на части, как на компоненты. И описывать связи между ними. Вторая - Описать структуру данных и функции на ними. И у них есть свои плюсы и минусы. (да. ООП это не волшебная пуля.)
Второе. Применения ООП эффективно к достаточно сложной системе. Сложная в смысле, что твой мозг определит там много частей и много связей между ними. Например вывести на экран приветствие это вряд ли сложное.
Третье. Понять , что дублирование это зло. Это не только копипаст, но делать дважды похожие классы компонентов с начала. Применять нужно наследование. В суперклассы переносить общее.
Четвертое. Система должна быть гибкой. Если приходят новые требования, нужно легко их реализовывать. И реализовывать локально. Т.е. по мере поступления изменений, мы находим места которые часто изменяются и стараемся вынести их в отдельные классы. В итоге получаем, при новом изменении, мы меняем только этот класс ничего более не цепляя.
Пятое. понять что между компонентами есть некий протокол взаимодействий. И для компонент важен именно он, а не реальный объект по ту сторону. Пример: розетка . не важно какая она в стене, в удлинителе, или от большой черной коробки, но в нее можно подключить утюг, компьютер, чайник и проч. Есть протокол - две дырки, напряжение 220 и достаточная мощь и этого достаточно. Это дает возможность менять компоненты не затрагивая остальные.
Примерно так.
По поводу принципов. любых. (ооп или солид) Обязательно нужно знать что они решают. Какую проблему. Это позволит не усердствовать. А применять в меру. оставляя код проще.
ну и книги по анализу.
Ответ написан
Комментировать
qonand
@qonand
Software Engineer
Вот выучил я что такое классы, объекты, наследование и т.п. А как его использовать на практике не пойму(когда php выучил также было)...

Что бы использовать ООП на практике нужно понимать саму философию ООП, понимать какую роль в этой философии играют те же классы, наследования и т.п. Мало просто знать что из себя представляют основные ООП-понятия. Что бы понять философию можно: поработать в какой-то более менее крупной компании работающей над ООП проектом/пройти какие-нибудь толковые курсы/почитать соответствующие книги, например того же Бертрана Мейера

Есть два своих проекта написанных процедурно, но хотелось бы их под ооп переделать. А как процедурный код превратить в ооп'шный я хз.

а вот этого Вам пока делать не стоит. Переделка проекта в ООП будет для Вас слишком сложной. Лучше сделайте какой-то учебный проект с нуля, с применением ООП парадигмы
Ответ написан
Комментировать
Нужно переписать кучу своего и чужого кода, что бы понять как делать правильно.
Философия бесполезна. Всё начинается с момента, когда наконец понимаешь, как не стоит делать.
Пока силы есть, можно много кода "лопатой накидывать". Плюс ещё IDE помогают быть беспечным.
Ответ написан
Комментировать
Пригласить эксперта
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы