ООП и MVC
21.07.2010 технологии
Aktuba очень убедительно агитирует за ООП, прямо посеял смятение в моей душе. Среди читателей моего блога точно много программистов, у меня к вам просьба: расскажите, как на ваш взгляд быстрей и качественней въехать в тему объектно-ориентированного программирования?
Пока что применительно к PHP, в основном — именно о том, как сделать начальные шаги, вкурить ООП как следует. Кроме PHP также будут очень интересны статьи типа «Как начать программировать на Ruby» и вообще о концепции. Кроме того очень хотелось бы в полной мере осознать преимущества MVC и тоже вкурить это быстренько и качественно.
Расскажите о своём опыте, посоветуйте что-нибудь, покажите примеры красивого правильного кода. Очень жду. Заранее спасибо!
P.S. Мне уже советовали книги о программировании. Правда, пока что прочитал только про интерфейсы Джефа Раскина, но планирую в ближайшее время прочесть Спольски.
Комментарии
Комментирование этой статьи закрыто.
ну здесь в двух словах не расскажешь. Одно скажу точно, что «въехать» однозначно стоит. Книжные примеры типа автомобиль едет (метод класса), имеет 4 колеса (член класса) я считаю так и не обьясняют саму суть. Если будут конкретные вопросы – то велкам, пиши на почту номер аськи – потолкуем :)
не беги вперед. MVC после ООП.
В php только с 5ки пошло более менее ООП.
По MVC многим понравились мои примеры: – rmcreative.ru/blog/post/mvc-view – rmcreative.ru/blog/post/mvc-front-controller-controller-i-router
А вот ООП как таковой… тут надо бы на конкретных примерах и задачах.
Да, если хочешь, могу порассказывать на примерах в аське / jabber.
MVC можно реализовать и без ООП, но… и тут и много «но».
Для понимания ООП начни использовать тот же Codeigniter! Сначала понимание ООП не требуется, а когда понадобится написать свои библиотеки, то потихоньку сам въедешь и не заметишь!
Ага, удобно. MVC вообще шикарный шаблон. ООП вкурил не сразу. Что почитать хз, я позорно на тренинге постигаю такие премудрости.
madbirdy, имхо нужно врубиться вначале, а потом уже фреймворки использовать.
Я лично учил ООП и MVC на курсах Java от NetCracker Technology в своем университете.
[http://forum.sumdu.edu.ua/download/file.php?id=39|Презентация ООП (rar)]
Правда у нас была еще и устная лекция к слайдам. По этим материалам я полностью разобрался в ООП, который применяю не только для Java, но и в C++ и PHP. Главное ж понять =)
[http://forum.sumdu.edu.ua/viewtopic.php?f=6&t=132|Паттерны проектирования] (+ пример MVC).
Впрочем, в инете про MVC есть тоже достаточно много хороших ресурсов.
Секрет в MVC прост: создаешь папки Model/, View/, Controller/. И в них размещаешь классы, отвечающие только за модель программы, графический интерфейс (формочки) и связь между ними соответственно…
Вообще это очень хорошо для разработок в команде: код по ООП и MVC более понятный и его проще дорабатывать.
Пиши в джаббер, если надо рассказать подробней…
Вот видеокурс, но там очень сильно разжевано, т.к. он для начинающих. Тебе что-то по-конкретнее думаю надо.
Ого, стоит о программировании написать, как сразу куча комментариев появляется. Причем некоторые от людей, которых я раньше тут ни разу не видел.
Классно. Спасибо всем! Сейчас у меня неотложные дела, но я обязательно ознакомлюсь с вашей информацией подробно чуть позже.
А кто-то ещё про PHP-4 помнит? :) Двадцать первый век же у нас, пора забыть. Я давно функции PHP-5 использую везде и не парюсь. Там много удобного появилось.
А я скажу что начни юзать фреймворки, да
Codeigniter, Yii
На практике оно быстрее
Хмм.. А может сразу функциональные языки начать курить? Haskell там например.
чтобы понять ооп, надо думать объектами, вот например возьмем твой блог :)
у него есть фабрика(ооп паттерн), которая умеет делать посты, возможно даже посты будут разные, ведь фабрика умеет производить продукцию какого то типа, но не обязательно одинаковую.
сразу видно что такое наследование, например видео пост наследуется от просто поста, отличается он допустим 1 членом класса – videourl
аудио пост отличается к примеру mp3url
ну и конечной реализацией функции toHTML() Они отличаются, ведь они должны уметь выводить сами себя на экран :)
опа, тут мы увидели понятие базовый класс либо, более интересно в данном случае ввести interface, который просит реализации функции toHTML(), назовем например интефрейс IBlogObject.
понимаем, что например что обычная ссылка тоже может выводиться на экран, но она необязательно должна быть блогом! поэтому «понижаем» уровень требований к объекту блога до простого интерфейса IBlogInterface
а там уже как гвоорится
foreach($this->objects as $o) echo $o->toHtml();
делаем контроллер, который обрабатывает какие то действия пользователя, вызываемый через Router, то есть например у нас есть линка /blog/, вызывается контроллер BlogController, у него есть методы actionIndex, actionFull($id)
соответственно ссылки /blog/ /blog/full/$id
приятность ооп в том, что ты можешь сейчас работать с абстарктными данными, если у тебя контроллер будет испольовать всего лишь интерфейс, а не базовый объект, можно и его конечно, главное не сделать его слишком сложным, пример WPPost, там объектик пиздец мягко говоря, но создавать его в вордпрессе – пожалуй самый простой вариант для вывода кастом плагина, который будет подгружать весь дизайн, по сути я бы ограничился интрфейсом IPost: getTitle, getContent, getMetaKeyword(? надо ли обычному объекту сайта?), getMetaDescription (?)
по сути контроллер сам может выводить хтмл, никто же ему не мешает, но часто удобнее для себя и последующих людей, выделить отображение в отдельный файл, его то и называют вьюхой, вьюха может быть без разницы какой реализации smarty/native php/xtemplate/twig/{str replace DLE LIKE :D}/любой другой удобный или неудобный шаблонизатор.
шаблонизатор – круто, но например я захотел сменить систему шаблонизации, и тут мне приходит на помощь так называемый паттерн – Адаптер. я делаю свой класс «прокладку», называю его например View, у нее есть пара методов – assignTplVar (__set), getTplVar(не всегда надо, но я иногда люблю так, __get), show($tpl = default)
по сути все, ну ты можешь конечно свои сущности ввести аля View::fetchBlock($blockname), но это уже не дефолт так сказать :)
что прелестного в этом шаблонизаторе? прелестно то, что этот объект всего лишь прокладка над коненой реализацией, где то в конфигах у меня например указано view.adapter=View_Adapter_Smarty
в констуркторе вьюхи берется эта настройка, делается if (!$adapter instanceOf IView_Adapter) throw new Exception (‘Чо за гавно вы мне подсунули?’);
делаем это потому что, мы имеем всего 3! функции, то есть мы можем сказать – вот переменная шаблона, дай переменную шаблона, отрендери шаблон. по сути это и должен получать адаптер шаблонизатора на вход. Класс. Теперь реализуем этот адаптер: class View_adapter_smarty extends Smarty implements IView_Adapter
екстетндим его потому что удобно же писать $this-> вместо всякой аля $this->smarty-> ерунды :)
реализуем нужные нам функции и вуаля, теперь мы можем менять шаблонизатор не меняя логики приложения ни на строчку (конфиг не считаем ;) )
Ну а модель, что же такое модель :)
ну модель – например тот самый замучаный BlogPost, я просто накину интерфейс модели: getById(), getAll($order, $limit, $offset), delete($this конечно :)), showEditForm(), create, update
во как :)
ну а я бы например сделал модельку BasePost которая реализовывала бы интерфейс который я первым описал в начале камента и умела бы работать с абстрактными модельками, ведь мне абсолютно без разницы какого типа моделька при выводе списка всех постов, будь то музыкальный пост, видео пост либо просто ссылка :) (getAll функция), ну а он бы уже както хитро умел возвращать нужного типа модель для конечной реализации объекта поста.
во как много херни я написал :)
аську не буду рекомендовать, а то мы ночь в разговорах проведем, а работа не ждет :))
от дуда тормозу =)
зы: интересная тема, хорошо что отмылил линк :)
можно в рамочку как небольшой туториал объектного мышления, какбы понимаешь, самое главное – ООП это не классы, наследование и прочая хуета, которую пережовывают везде. это способ мышления, вот представь обычный мир, ты же не задумываешься что все вокруг ООП? а если задуматься? :)
трава, кустарник, куст – все трава, просто реализации разные
булка хлеба, булочка, пирожек – все хлебные изделия
вино, вода, пиво, водка, кока кола – все наследники h2O
все перечисленое мной реализует интерфейс IEatable { function eat(); }
:D
ООП Вокруг нас, это не просто class/interface/ abstract и прочая хуета текстовая:)
жаль не курю, я бы курнул после столько писанины … :)
я бы не советовал юзать фреймворки, потому что они просто предоставят тебе свое представление этих понятий, а не то, что ты бы сам понял, но если тебе надо ооп проект быстро реализовать то да, фреймворки рулят (наверное, я хз не работал даже с ними :), у меня другие методы)
ну и как подытог – ооп даже в самом гавенном представлении лучше сраного joomla, dle и прочего высера говнокода :D
2phpdude: много лишнего и ненужного. Начал с объектов, закончил интерфейсами, шаблонами, моделями и т.д…. Да и метод объяснения, мягко говоря, очень туманный…
2Тормоз: посмотри код, который я тебе присылал и сслыки sam-а, найдешь много общего. У sam-а и брал основу ;)
Если вдруг решишь использовать фреймворк, вот микро-обзор нескольких:
CI (codeigniter) – хорошо показывает основы ООП + очень прост в обучении
Kohana – уже надо получше знать ООП, но более гибкий местами, чем CI. А местами просто в зародыше (это я о KO3).
Zend – гибкий, популярный, масштабируемый. Из минусов – огромная куча лишнего и неудобного (хотя, кому как).
Yii – любимый фреймворк sam-а, у меня не хватило терпения его полностью освоить.
Symphony – никогда не использовал, но судя по постам в блогах, такой же заумный, как Yii.
В любом случае, сначала пойми основы – потом будет проще выбирать ;)
2aktuba да в общем то и не презентовал на статью, это всего лишь мысли, а не вылизанная бумага для хабра и тп :)
@phpdude: многа букаф, но в целом полностью с тобой согласен: и про мышление, и про то, что всё вокруг – сплошное ООП. Да и вся жизнь наша – запрограммирована кем-то))) Ток ты приводишь пример на фабриках, а Тормоз про MVC спрашивал… ;)
У меня есть знакомый, который бывает сидит, смотрит, скажем, на светомузыку в клубе, и может затравить че-то типа: «А вы замечаете, что это же три цикла, запущенные в рекурсии?…» Да он и колбасу режет со скоростью O(n). =)))
Тут уже много чего сказали и повторяться не буду. Из литературы я могу посоветовать вот что:
Методичка по ООП , по которой я в этом году готовился к экзамену, от нашего лектора :-)
Г. Буч, ООА и ООП – хрестоматийная штука, во многом на ней основана методичка. Но читается довольно легко.
Собственно с ООП я знакомился еще до универа по этой книге: http://www.ozon.ru/context/detail/id/1500069/
По поводу MVC – это всего лишь паттерн, при котором четко разделяются хранение данных, логика программы и отображение пользователю. Чтобы его понять проще всего покодить на каком-нибудь фреймворке. Для себя я выбрал Yii и пока вполне доволен его скоростью и относительной простотой, но у него ощущается некотороая неполнота документации – за некоторыми тонкостями приходится лезть в код фреймворка. Буквально в данный момент пишу на нем один сайт и чем дальше, тем больше нравится. Как только представлю, сколько бы я все это вручную с нуля писал – хочется спрятаться под стол :-)
Про ООП в PHP на английском тут – http://net.tutsplus.com/tutorials/php/object-oriented-php-for-beginners/.
MVС – примеры на PHP здесь : http://chtivo.webhost.ru/articles/mvc.php и http://chtivo.webhost.ru/articles/mvc_rate.php .
По design patterns основополагающая книга – GoF (http://www.ozon.ru/context/detail/id/2457392/). Есть также статейка на английском с примерами на PHP – http://net.tutsplus.com/articles/general/a-beginners-guide-to-design-patterns/ (правда, не все примеры, на мой взгляд, там удачные).
По фреймворкам – начинать лучше всего, как уже выше писали, с Code Igniter, тем более есть русский перевод документации на http://code-igniter.ru/ . На данный момент использую Kohana , однако уже подумываю о переходе на Yii из-за множества приятных фишек относительно Коханы.
ЧТо ж вы все за ООП? И никто не скажет ни одного минуса данной вещи.
К примеру, повторное использование кода плохо.. А теперь берем открываем файл с вашим ООП и обычный.. Чтобы понять как ОНО работает достаточно открыть один файл, а чтобы понять как работает с ООП надо переоткрывать кучу доков. ООП придумали идиоты). Функций и классов вполне хватит для всех задач.
Ну что братья быдло-кодеры кто скажит мощные аргументы и приведет сильные доводы, что ООП хуята, а процедурное программирование рулит!
2MA: Чем это повторное использование кода плохо?
Вопрос сторонникам ООП: есть ли какие то реальные преимущества ООП при написании небольших скриптов размером ~1000 строк?
В ООП самое трудное – это проектирование.
Попробуй написать чего-нить с использованием фреймворка, чтоб понять чего это такое.
ООП is BULLSHIT.
Php the same.
Use Ruby on Rails :)
Чтобы юзать ror вовсе не нужно понимать полность ооп, ооп вообще не нужно понимать. Его используют для создания фрэймворков, а для работы с ними не обязательно.
phpdude не согласен, наоборот надо использовать чужие фрэймворки и не писать булшит.
Противникам ООП: реализация паттернов, тот же Singleton pattern. На самом деле в небольших проектах никакого преимущества нет в ООП. Но написав какой-то класс однажды, используешь его везде. И изменения в функциональности вносишь только в нужном тебе классе, в этом достаточно большое удобство. Выше уже была ссылка на статью с NetNuts+ очень неплохо и доступно описаны азы. А попробовать прелесть того же ООП в сочетании с MVC – стоит попробовать написать пару приложений на том же Codeigniter-е: у этого фрейморка на редкость хорошая документация, написанная человеческим языком (-: После этого можно уже писать свои фрейворки или переходить к более серьёзным.
MA, хе, ну ты жжёшь! Раз — корректно спроектированный ООП = автогенерируемая документация, эт раз.
Два — тебе ваще нах не надо знать, чё там вообще написано, в этом сермяжный смысл ООПа. Тебе надо знать, как обратиться к методам объекта, и долго и нудно бить себя по рукам, когда хочется посмотреть, как это работает.
Тормоз, вишь — бурление началось ;)
Спецы! А есть описание паттернов для вебмастера-дебила, типа того, что PHPDUDE давал (но для всех паттернов)? А то я как начинаю читать сухие абстрактные описания — всё, через страницу срубает.
Вот отличные описания для всех паттернов: http://sourcemaking.com/
samlowry, когда и где он такое давал?
2samlowry это были мысли :)
http://wiki.agiledev.ru/doku.php?id=ooad
вот неплохие статей, и ооп статьи выгоднее смотреть про яву, там уже уча написана, идея то все равно одна, синтаксисом только отличается реализация :)
присоединяюсь к samlowry.
Вообще, меня вот долго убеждали в апупенности ООП, но так и не убедили. основные доводы: удобство юзание одного класса однажды написанного во всех последующих сайтах, прозрачность – код типо выглядит понятнее и вообще это типо стандарт, простота – можно стырить чужой класс и не разбираться в нем, как уже говорилось выше.
из минусов: работает медленнее процедур, больше кода если применяется меньше 5 раз в одном скрипте.
так что, есл писать для себя и код не в мегабайтах, то процедуры ничем не хуже.
Ewg: выше — про фабрику на примере CMS блога.
Предлагаю прочитать следующие книги 1-ым обязательно Буча, а потом можно в произвольном порядке.
1. Гради Буч «Программирование с помощью ООП»
2. К.Бек – Экстремальное программирование – разработка через тестирование.
3. Э.Гамма – Приемы объектно-ориентированного проектирования: паттерны проектирования.
4. Стив Макконнелл – Совершенный код
5. М. Фаулер – Рефакторинг
Вместо CodeIgniter я бы взял Kohana, так как у CodeIgniter много кода осталось от 4-ого PHP (по крайней мере раньше было именно так).
ИМХО научиться программировать в ООП-ом стиле – дело не одного года. Всегда есть чему учиться. Самые основы можно схватить быстро. Главное не увлекаться наследованием, по мнению многих авторов (в том числе приведенных выше) лучше предпочитать композицию наследованию.
И еще, стоит ознакомиться с UML, очень помогает при выражении мыслей и работе с шаблонами проектирования.
Успеха!
Так функции я тоже пишу только один раз и потом использую во всех проектах!
ООП тут никаким плюсом не выходит.
2MA, 2ПистоГанза: сколько времени у вас займет поменять шаблонизатор в проекте? С нативного – на смартс, например…
MA, чтобы понять как работает код на ООП хватит одного файла – названия классов и методов само за себя скажет. А вот в процедурах будет жопа – придется либо долго-долго крутить мышкой, либо бегать по файлам, чтобы найти нужные функции…
Процедурное программирование хорошо, но только для мелких проектов, без последующего развития. Развивать и поддерживать такие проекты – ппц какой геморой.
Очередной срач про Nolix потёр и дальше буду удалять оффтопик. Нет, мне не обидно, но если в каждой заметке будут комментарии про эту хрень, будет несколько неприятно.
Пишут какую-то хуйню.
.
Когда проект разростается, то в нем становится очень сложно разбираться. Так? Для того, чтобы как-то с этим справиться, нужно что? Нужно как-то сгруппировать весь хлам. То есть надо объединить кучки кода в какие-то более общие сущности. И далее уже работать с этими сущностями и не париться со внутренними деталями.
.
Главная суть ООП, это то что куски кода можно объединять в объекты и далее этими объектами оперировать.
.
И для того чтобы внутренний хлам нам не мешался, объект снаружи выглядит как «черный ящик». То есть мы не должны знать что там внутри, мы должны знать только его внешний интерфейс. И называется это умным словом «инкапсуляция».
—
Далее, программируя наши объектики и радуясь, мы постепенно приходим к выводу, что многие из этих объектиков похожи друг на друга с небольшими отличиями. И было бы неплохо и в них выделить общие части и расположить их в одном месте, а различия описать для каждого объектика отдельно. Для этих целей люди придумали «наследование».
—
Понимая, эти базовые принципы, можно дойти до полиморфизма, интерфейсов, паттернов… и прочих вещей которые делаются на основе.
—
MVC — это подход, когда бизнес-логику приложения (model) засунули в один объект, а логику внешнего вида (view) засунули в другой объект, и сделали третий объект (controller), который управляет предыдущими двумя.
.
Удобство заключается в том, что все лежит по полочкам. При этом, чтобы поменять внешний вид, не нужно переписывать все приложение. Нужно только переделать ту часть, которая отвечает за view. Так же и с другими частями.
.
Разделяй и властвуй.
.
ps: точки между абзацами вставил потому, что иначе, читать такие портянки текста невозможно.
О, я наконец-то понял, что такое «инкапсуляция» :)
это скрытие данных внутри объекта/сборки и предоставление только методов для получения данных либо вызова методов объекта
sanchosrancho:
«Главная суть ООП, это то что куски кода можно объединять в объекты и далее этими объектами оперировать.»
-
В корне не согласен с тем, что объект – это просто кусок кода. Так можно сказать, что стихотворение – это просто набор слов, или мелодия – это просто набор нот и т.д.
-
«Далее, программируя наши объектики и радуясь, мы постепенно приходим к выводу, что многие из этих объектиков похожи друг на друга с небольшими отличиями. И было бы неплохо и в них выделить общие части и расположить их в одном месте, а различия описать для каждого объектика отдельно. Для этих целей люди придумали «наследование».»
-
Опять же не согласен. Например, табуретка очень похожа на стол. Но разве можно сказать, что класс «табуретка» можно унаследовать от класса «стол»? При таком подходе нарушается принцип подстановки Барбары Лисков, и в итоге код не становится лучше.
Что насчет mvc, тут главное проникнуться идеей.
Есть данные(model). Они хранятся так, как их удобно хранить. Чтобы связанно, полно, непротиворечиво. Мы пока не думаем, что мы можем с ними делать. Просто храним то, что насобирали. Есть стандартный «язык запросов» для получения этих данных.
Есть представление данных(view). Ему не важно откуда данные взялись. Задача представления вывести данные на экран компьютера, мобильного телефона/браузер/десктопное приложение/принтер/мозг пользователя через транслятор мысли. Таких представлений может быть много. Каждое из них имеет свой метод получения данных. Представление сделало запрос так как ему хочется и вывело полученные данные.
Контроллер знает все языки моделей и представлений. Он определяет к какому из представлений обратился пользователь, запрашивает данные из модели и преобразует в формат который нужен данному представлению.
Вроде все
2Evgeny Sergeev
Я сознательно упростил концепцию. Потому что дойти до более сложных вещей так будет проще. Слона надо есть по кусочкам.
-
Но можно сказать, что и класс «табуретка», и класс «стол» можно отнаследовать от класса «деревянная штука» (или же от класса «продукция мебельной фабрики»).
sanchosrancho,
«Но можно сказать, что и класс «табуретка», и класс «стол» можно отнаследовать от класса «деревянная штука» (или же от класса «продукция мебельной фабрики»).»
-
Как раз таки нельзя. :-) Все преимущества полиморфизма сразу теряются.
-
Попробуйте у класса «Стол» выделить интерфейс, который можно вынести в класс «деревянная штука» или «продукция мебельной фабрики». :-)
-
Я бы предположил, что «Стол» – это базовый класс, его могут наследовать классы «Круглый стол» или «Квадратный стол», или «Кухонный стол».
Дуд, кого ты убеждаешь :) Айда на пыху :)
2Faster ага, пошел уже :)
Боже мой, к чему эти придирки? Что значит «нельзя»? Т.е. не при каких условиях нельзя, независимо от предметной области? =)
Интерфейс для класса деревянная штука? Пожалуйста:
— покрасить(),
— сжечь(),
— ебнуть_кого-нибудь_по_голове().
Так сойдет? Полиморфизм на месте?
sanchosrancho: приведенный интерфейс для «деревянной штуки» в контексте стола (да и в контексте любой другой штуки) бессмысленен, так как стол не может никого покрасить (в том числе и самого себя), не может никого сжечь и не может ебнуть кого-нибудь. Все эти действия могут производиться над (!) столом. Например, официант или моляр может реализовывать подобный интерфейс, но они уж точно не являются «деревянной штукой».
-
Кроме этого, важно понимать, что «деревянная штука» – это как минимум два интерфейса «штука» и «дерево» и если первая еще имеет смысл в контексте большого кол-ва разных столов, то «деревянный» – это уже точно частный случай.
-
Относительно «нельзя», могу сказать, что если следовать приведенной логике наследования, то в итоге получится «загнивающий» код. Конечно, никто не может запретить Вам так делать, но точно так же гвозди можно забивать не молотком, а головой (кто сказал, что нельзя?).
добавлю свой камешек в кучку.
codeigniter + документация выльются в мелкий скрипт.
затем попробуй добавлять фишки. постепенно проект разрастется.
при процедурном программировании, как сказал aktuba, достаточно сложно будет контролировать проект.
в codeigniter же(или любом framework – дело религии) подобных проблем не возникает.
—-
с днем админа, если такие тут бывают.
Да, с функциями иногда правда сложновато. Хоть у меня в Daos все функции вынесены в отдельный файл, всё равно сложно добавлять новое или исправлять что-то.
Можешь у меня на блоге посмотреть пост про реализацию паттерна MVC. Старался объяснить максимально просто, на примере процедурного подхода :)
Посмотрел. Общая суть MVC мне и так понятна была, но надо бы не просто понимать, чувствовать все нюансы. Пока этого нет.
Ну, чтобы прочувствоать все нюансы, ИМХО надо просто практиковаться, экспериментировать, читать умные книжки, например от «банды четырех» :)
Говорят, что особенно MVC хорош при ООП, но я в нем пока плаваю :) Пока думаю заюзать фреймворк CodeIgniter.
Перечитываю комментарии. Блин, если сперва вообще ничерта почти непонятно было, тёмный лес, сейчас уже совсем иначе многое воспринимается! Знания растут. Спасибо всем.
доброго времени суток.
простите, но я не смог удержаться.
не могу поверить, что есть еще на свете пещерные человеки, которые кричат о том, что процедурное программирование рулит.
вообще php не самый удачный язык для понимания/практикования ООП, но даже в нем можно углядеть явные преимущества. я тихо ржу и и представляю как сторонники процедурного кала будут справляться с нагрузкой на огромных проектах. интересно каким чудом вы переносите части кода на другой сервер? хотя по всей видимости с таким подходом к программированию этого не произойдет никогда.
автор – советую копнуть Java или C для понимания сути.
Что мне помогло –
видеокурс от школы программирования «Профессионал PHP». Он уже есть в паблике на скачивание. Две – три недели и думаю вкуришь не только ООП но и MVC