lina666
@lina666
Изучаю веб ЯП.

Что нужно знать про ООП?

Приветствую всех программистов, недавно углубился в ООП на php.
Скажите где можно получить исчерпывающую информацию как работать с ООП, я умею пользоваться справочником, но когда не знаешь, что в нем гуглить не очень получается находить информацию и на каком сайте есть хороший сборник задач для этой темы?
  • Вопрос задан
  • 3494 просмотра
Решения вопроса 1
Изучая ООП вам нужно будет понять:
  1. основные принципы ООП: инкапсуляция, полиморфизм, наследование. И еще почитайте про абстракцию.
  2. отличие self от static. Почитать про раннее и позднее статическое связывание
  3. принципы SOLID
  4. смысл инъекции зависимостей (Dependency Injection) и инверсии зависимостей (Dependency Inversion - один из принципов SOLID)
  5. основные шаблоны проектирования (design patterns)

Ну и научитесь думать абстрактно) Не завязывайтесь на реализации, прорабатывайте интерфейсы.
Ответ написан
Пригласить эксперта
Ответы на вопрос 7
gzhegow
@gzhegow
Думал, стану умнее, когда адаптируюсь, но нет
А я бы добавил что ООП это украшение кода, а не его суть

Cейчас есть способы платить Амазону и вообще не писать код, создавая апишки в админке с помощью мышки. Все что будет нужно от ПХП - это делать простые скрипты которые передают данные из точки А в точку Б. Там вообще не нужен будет ООП, потому что не будет понятия "цельный проект" в рамках папки с файлами. Цельный проект это будет куча компьютеров, а на этом конкретно есть передача из А в Б. И тут уже PHPшники посмеются)) Они то готовы к такому

Увидев, что тебе понравился первый ответ (может ты его и искал?), я попробую пояснить его для тех, кому термины ничего не говорят:

наследование


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


инкапсуляция

spoiler
это чтобы не вдумываться как оно работает. в электронике телевизоры уже давно не собирают пайкой и проектированием схем, они знают что есть плата, у нее такие-то выходы, и если их правильно присобачить - всё заработает. вот ~интерфейс платы это её название (хотя бы) и список выходов (методов). Реализация - это то что плата делает, внутри там себе, как-то. а Имплементация - это припаивание нужных выходов к нужным местам в твоей программе.


полиморфизм

spoiler
после того как ты понял первые два принципа можно вникнуть в то, что разные машины из первого примера могут ехать по разному. допустим у нас будет бмв, который на рессорах (а почему нет?) - и он перед тем как ехать должен значит колеса свои поднять. вот полиморфизм это про то, что наследник общего класса может работать по своему, что позволяет вместо написания "если-то" - подсовывать наследник, и он сам знает, как ему ехать. то есть мы из родителя ответственность передаем ему самому. но будь осторожен. дальше есть SOLID который идет в обратную сторону - что исполнитель должен нести как можно меньше ответственности. То есть у них даже паттерны друг другу противоречат.


И еще почитайте про абстракцию.

spoiler
это про то что я писал выше в наследовании. Если есть машина - то врядли нам интересно, чтобы в программе была ну вот тупо машина, без номера, стекол и вообще конь в ваккуме. мы поменяем машину как абстракцию, что означает - что она не может существовать не будучи конкретной машиной - бмв например. в результате получаем возможность "требовать" от потомков чего-то - например - в абстрактной машине требуется метод "заправить бак" - но где он этот бак - не понятно. поэтому мы требуем, чтобы каждая из машин описала в своем коде где у неё бак, иначе она не может существовать.


отличие self от static. Почитать про раннее и позднее статическое связывание

spoiler

очень просто. self можно понимать как "этот класс". буквально. ты можешь использовать слово self:: только внутри класса. и когда ты пишешь self::drive() он выполнит действие drive() этого класса. а static:: это то же самое только с учетом наследования. когда у тебя есть класс Машина и там self::drive() - он будет пытаться поехать способом общим для всех машин. Если ты напишешь static::drive() то в первую очередь он попытается поехать способом специфичным для БМВ, а если его нету - вспомнит, что БМВ - это вообще-то машина, и она может ездить как Машина. Это мы говорили про статику. Есть еще динамика или так сказать "обычный способ".

Отдельного внимания заслуживают статические СВОЙСТВА. Выше это было про методы. Статические свойства объявляются глобально для всего дерева наследования. То есть ты как в машине обьявил свойство "обьем бака" и поставил его по умолчанию 40 литров, так оно у всех машин теперь 40 литров. Если ты в БМВ укажешь например 45 литров - БМВ будет иметь собственный бак на 45 литров. Но поскольку статика - это ГЛОБАЛЬНО - то не-бмв если мы внутри кода поставим бак побольше (например у нас есть пользователь который может "купить бак побольше для машины") - поменяет бак ВСЕМ МАШИНАМ кроме Бмв (потому что при обьявлении БМВ явно было указано - что у него свое свойство). Если бы мы создали конкретную машину (экземпляр, объект, сущность) - то мы могли бы использовать "обычное" динамическое свойство - которое бы принадлежало вот прям этой машине, созданной, так сказать "одной из БМВ". А статическое - это про все машины. Поэтому изменять статическое свойство "не вручную" - это не то чтобы глупость, но нужно делать с предельным вниманием и осторожностью.

Статика предполагает что в твоем классе просто лежит умение что-то делать. Вот к примеру ты умеешь пользоваться компьютером. Статика - это "умение пользоваться компьютером", а динамика это действие в процессе "использование компьютера". В коде и то и то описывается как функция. И то и то нужно вызвать. Но отличается возможность подсовывать данные на ходу. Так в умение можно передать только требования. В действии в процессе как минимум есть исполнитель, а как максимум - есть другие исполнители, без которых наш исполнитель сделать ничего не может. В сложном коде иначе довольно трудно что-то сделать!


принципы SOLID

spoiler
с ними всё сложно. они настолько абстрактны и рекомендуемы, что их вроде бы все описали, но когда нужнее - никому не понятно, а я спрашивал, многих. звучит "Солид" громко. а на практике это титул на вашей груди "я знаю солид" - а зачем он? - ну там барбара есть лисков есть, одно действие в каждом методе, пэк мэк и кончился гений. Так с большинством теорий в программировании - слово слышал, смысл понимаю, когда нужно? почитайте. Привыкай. Солид это про то чтобы стараться, чтобы каждое действие в классе выполняло одну единственную задачу, то есть, например, когда ты будешь создавать наследников от этого класса - ты сможешь подменить один единственный кусочек. Чем больше вещей делает функция в классе - тем сложнее её подменить, потому что ты меняешь сразу несколько вещей, которые ты скорее всего не хотел менять. Буковка L там про Барбару что-то было - напоминает о том, что наследник должен на вход принимать то же, что и родитель в этом же действии. То есть водить машину он может по своему, но если родителю требовался пилот, то и потомку тоже надо чтобы был пилот, иначе - это другая абстракция. Это помощь в организации мыслей


смысл инъекции зависимостей (Dependency Injection) и инверсии зависимостей (Dependency Inversion - один из принципов SOLID)

spoiler
обычно в PHP например чтобы создать обьект нужно написать $obj = new MyObject(); Чтобы помочь обьекту что-то делать ему требуются другие обьекты и чтобы их сунуть - нужно понять где создается первый и именно там создать второй, подсунув в первый $obj = new MyObject(new MyHelper); Фишка в том, что обьекты эти со временем начинают создаваться из других обьектов, а не в общем потоке программы. То есть одни обьекты начинают служить заводами для других обьектов. И вот каждый раз можно крышей уехать чтобы помнить кому и кто требуется в помощь, без чего кто не может работать. Отсюда присоединяется специальный механизм, где ты в настроечном файле указываешь что такой-то класс при создании должен на вход автоматически получить вот такие-то классы, а они в свою очередь - такие-то. Дальше внутри кода класса ты отталкиваешься от того, что помощники уже будут здесь, а не может будут может нет. Вместо того чтобы указывать помощников вручную каждый раз - ты описываешь настройку, которой они все будут руководствоваться, чтобы прийти на помощь в нужный момент куда надо.


основные шаблоны проектирования (design patterns)

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


Ну и научитесь думать абстрактно) Не завязывайтесь на реализации, прорабатывайте интерфейсы

spoiler
здесь важно понимать - что БЫСТРЕЕ сделать чтобы оно сразу работало, а потом выносить общие куски в другие файлы. но в задачке посложнее это неизбежно превратиться в ужас и кашу - общие куски лежащие наруже папки с какой-то штукой, и потому пытаешься их присобачить и там и здесь, и всё это рушится и пошло оно лесом. Поэтому МЕДЛЕННЕЕ НО РАЗУМНЕЕ сначала прикинуть что может пойти не так, и пойти от общего к частному. Дальше определяется оплатой за работу и всеми этими человеческими штучками, которые компьютеру чужды

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


думаю сейчас ты увидишь как набегут великие архитекторы, которые давали тебе советы по этим словам и начнут говорить что то не про это, а это не так и это не здесь. вот это еще одно что надо знать про ООП. Ты никогда не услышишь, что ты прав, потому что термины заменили им мозг, а если им сказать об этом - они объединяются в стаи, чтобы завалить тебя стикерами и унижениями.
Ответ написан
BojackHorseman
@BojackHorseman Куратор тега PHP
...в творческом отпуске...
нужно знать, что углубляться в ООП на примере php - плохая идея
Ответ написан
@Evident
От ООП в php одно название, потому что даже перегрузки методов нет.
Чтобы проще постичь ООП, переходите на Java или C#.
Ответ написан
@AndrewRusinas
Напишу с точки зрения джаваскриптора. С php знаком поверхностно, и, как по мне, там это бесполезная затея. Как и, простите, сам php (сугубо моё мнение, не холивара ради).

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

Например, класс User. Может, он умеет создавать записи в блог? А может есть класс Blog, с методом .newPost()? А может и вовсе Post.new()?

Для меня эти вещи оказались избыточными, хотя возможно во мне говорит нехватка опыта и я буду рад, если меня поправят.
Ответ написан
@S-a-n-d-r-0
Список принципов ООП скудный и охватывает далеко не все. Почитайте это:
https://ru.wikipedia.org/wiki/Категория:Принципы_п...
Ответ написан
@rook_lem
Всё, что нужно знать про ООП:
1) Это не "серебряная пуля"
2) Это главенствующая, но далеко не самая правильная парадигма
3) Есть куда более привлекательные, понятные и позволяющие писать более надёжный код подходы

https://tproger.ru/translations/oop-the-trillion-d...
Ответ написан
Ваш ответ на вопрос

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

Войти через центр авторизации
Похожие вопросы
от 150 000 до 180 000 руб.
Vigrom Москва
До 150 000 руб.
N1.RU Новосибирск
от 100 000 руб.