Логика применения ООП

В процессе изучения ООП возник такой вопрос, просьба к опытным форумчанам подсказать, как же правильно.
Какова логика применения ООП и как его правильно применять?

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

Но в проектах стандартных не очень понятно как правильно применять ООП. Различные книги и статьи про "паттерны проектирования" не очень понятны на начальном уровне, если честно. Поэтому поискал практические уроки по ООП и просто готовые не сложные движки, нашел вот такие примеры:

-----

1. Например, гостевая книга - есть класс GBook, в котором абсолютно все методы (публикация, удаление, вывод), свойств нет, в index.php создается объект new GBook и в зависимости от $_REQUEST['action'] вызывается определенный метод. Т.е. никаких различий с процедурных подходом, только доступ к методам "со стрелочкой".

2. Или блог с админкой - тоже один класс Article, свойства - title, author, text итд, методы вывода объявлены статическими, при каком-то действии - создается объект, и в зависимости от $_REQUEST['action'] вызывается определенный метод. Здесь единственный плюс - что в конструкторе данные сразу присваиваются свойствам.

Обычно пишут, что "это простые примеры, а вот если в вашем проекте есть пользователи с разграничением прав итд". Но даже если добавить регистрацию пользователей - можно добавить класс Users и опять же все то же самое что и с Article.
Расширять Users (в обычном проекте с админами, модераторами, пользователями) не имеет смысла, разграничение прав проще делается дополнительным свойством.

3. Если я правильно понял суть MVC, то если ту же админку делать на MVC, то никакие классы Article и Users не нужны, просто классы Model, Control, View. При этом в Model описываются все методы, работающие с базой итд и эти методы управляют как пользователями так и статьями и комментариями.
В Control - управление в зависимости от действий пользователя и View - подключает шаблоны.

Но это не сильно отличается от процедурного подхода - в отдельном файле пишутся все функции (по сути та же Model), в другом - switch ( $_REQUEST['action'] ) по которому вызываются функции (тот же Controler) и подключаются шаблоны (View). Т.е. преимущество MVC здесь - есть, а какие преимущества у ООП ?

-----

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

Ну и если кто-то знает статьи на эту тему, несложные исходники с практическим ООП (не пустые наборы классов делающих непонятно что)

0

Ну и если кто-то знает статьи на эту тему, несложные исходники с практическим ООП (не пустые наборы классов делающих непонятно что)

Скачай codeigniter например, самый просто фреймворк (ИМХО). Посмотри как все там устроено и как все работает, думаю после это все вопросы отпадут.

1

Начнем-с...

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

А как быть с тем фактом, что и раньше игры писались, а ООП при их создании не применялось? Следовательно описать возможно и без ООП.

Сообщение от ячсмит Различные книги и статьи про "паттерны проектирования" не очень понятны на начальном уровне, если честно

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

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

Самое главное преимушество ООП заключается в том, что используя его можно написать больше работающего, легко поддерживаемого кода без повторов(копипастинга), нежели в функциональном программировании

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

Когда и где применять ООП? Везде где считаете нужным, там и применяйте, хоть в Hello World, хоть создайте свой класс Calculator с одним методом sum. С приходом опыта вы сами будете понимать где нужен ООП, а где можно и просто статический метод класс применить, а где вообще лучше не писать код

P.S.
Насчет статей и прочей лабуды - тут помочь не могу (я просто не помню ни ссылок, ничего... ), в интернете лежит много чего, да и найдутся те, кто посоветовать может

1

http://habrahabr.ru/post/23619/
http://lib.nsu.ru:8080/jspui/b... -part2.pdf

1

Сообщение от webphp Скачай codeigniter

посмотрел codeigniter и yii, но это все таки пока сложновато

Сообщение от vasiatka http://habrahabr.ru/post/23619/ http://lib.nsu.ru:8080/jspui/b... -part2.pdf

да, я это читал) я не прошу чтоб мне кто-то доказал, что ооп вообще надо использовать (это и так понятно), вопрос в том, чтоб понять как

Например:

В примере с блогом, где есть один класс Article и методы вывода (getAll, getArticle) объявлены статическими, а для остальных создается объект. Почему? Можно ли все методы объявить статическими и объект вообще не создавать? (если не использовать конструктор, получается синглтон? или нет?)

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

Или, например, в каких типах сайтов надо пирменять MVC а в каких не надо. Тот же блог можно сделать и на MVC. Но нужно ли?

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

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

0

Охххх...

Сообщение от ячсмит В примере с блогом, где есть один класс Article и методы вывода (getAll, getArticle) объявлены статическими, а для остальных создается объект. Почему? Можно ли все методы объявить статическими и объект вообще не создавать?

да можно

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

да не будет отличаться, это и есть ФП используя "слова" из ООП

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

На нем делают ресурсы, которые необходимо использовать в единичном экземпляре.

Сообщение от ячсмит Или, например, в каких типах сайтов надо пирменять MVC а в каких не надо

решать опять таки вам. Если вы только учитесь - на любом сайте. А дальше с опытом.

Сообщение от ячсмит Тот же блог можно сделать и на MVC

можно

Сообщение от ячсмит Но нужно ли?

решать вам, если учитесь применять MVC - пишите блог на MVC

Сообщение от ячсмит Или, например, есть интернет-магазин с регистрацией. Какие в нем должны быть классы? Товары и пользователи? Или заказы? И как группировать методы по классам? Можно же все методы запихать в один класс, по идее и так будет работать. И опять же, где нужны статические методы, а где объекты создавать.

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

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

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

___________
Итог: Вы так и не поняли что такое ООП, и не поймете, просто задавая вопросы, тут надо заняться применяя ООП (прям как в сексе кстати, можно прочитать 1000 отличных книг, то так и не понять в чем смысл).

___________
P.S.
Прочитайте ещё раз что такое ООП, что такое классы, что за объекты и почему нет смысла создавать один статический класс со всеми методами.

1

Сообщение от ячсмит Можно ли все методы объявить статическими и объект вообще не создавать?

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

1

Сообщение от AmsTaFFix И кстати, нагородить код, а потом понять что он неправильный - это признак того, что за время вы научились чему-то новому

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

Сообщение от AmsTaFFix Вы так и не поняли что такое ООП, и не поймете, просто задавая вопросы

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

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

0

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

1

создайте свой блог, форум, портал, просто создайте. И вы начнете понимать. И во время разработки - задавайте вопросы

0

Сообщение от ячсмит Тогда наверное надо переформулировать вопрос: Подскажите несложные исходники (или статьи, или что-то еще), в которых реализуется ООП. Полегче фреймворков, но посложнее, например, простого блога.

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

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

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

2