Задумываю большой проект, который планирую развивать постепенно. Сейчас это скромный сайт с базой данных их трёх таблиц. Если я сделаю всё что хочу , то это будет приложение с множеством функций и 50 - 100 таблиц в базе. Насколько необходимо сразу писать в ооп? Процедурно ещё что то могу написать , ооп пока что для меня вещь не понятная. Я читал статьи на тему что для большого проекта лучше писать на ооп, но всё таки хотелось узнать мнение живых людей. Спасибо.
Сам месяца три - 4 столкнулся с проблемой, когда надо было оптимизировать свой громадный код, из if и всякой фигни состоял... благо красивый кодинг присутствовал. После перевода в ООП, важные результаты в шабку класса отправлялись, код сократился. Более удобно кодить становится. Это первое что заметил с большим плюсом.. Ну а что лучше function vs OOP - это уже другая тема... но буду на стороне оопки, так как любую переменку сможешь использовать дальше в других частях кода, как мост перешагивающий через весь мегаполис ( так если понятно )
Единственный случай когда для проекта сложнее "Hello world" может использоваться процедурный стиль — это легаси. Что-то большое, созданное за большие деньги очень давно. Когда нельзя вот так просто взять и переписать всё. Потому что бизнес не любит простои.
Если проект действительно большой и долго планируется его поддерживать, то пофиг как его писать, всё равно через полгода придется переписывать )
Да неужели? Жизненно необходимо! Тем более, большой. Это позволит в нем не запутаться, если даже будешь переписывать через полгода, как говорит Ромаш. Хотя я считаю, что ты только писать его будешь год-полтора. Отпишись через годик, если я оказался прав. Если не прав - отпишись через два.
Да всяко. На старте большого проекта с непонятным изначально вектором развития трудно заранее заложить верную архитектуру. Потому сначала будет пруф-оф-концепт, а затем рефакторинг всего и вся.
Мне кажется это самая распространенное проблема у тех, кто начинает свой проект - перфекционизм. Многие думают о красоте кода, о его оптимизации, что усложняет и так не легкий процесс разработки, а особенно когда ты работаешь один. Потом вторая проблема, ты думаешь чем обобщеннее модель, тем проще будет писать код в будущем. Это не так, надо понимать, чем больше кода, тем больше его надо обслуживать. Чем выше абстракция кода, тем сложнее его обслуживать. Вопрос использования ООП это по сути задача оптимизации, вы взвешиваете профит от использования ООП и риски. И принимаете решение. Надо понимать в конечном счете каждое решение будет стоить денег. Мое мнение, что ООП - это затратно, дорого по деньгам и по времени. А если проект не сложный (нету сложной математики, графики и не пускаете короабли в космос и т.п.), то смысла нету тратиться.
да, честно говоря, я интуитивно так и предполагал ... я не смогу сейчас спроектировать всё что хочу изза нехавтки зананий, опыта, денег и т.д.... я смирился с тем, что надо будет переписывать --- Добавлено --- Извините...не понял что вы написали --- Добавлено --- честно говоря, я вообще себе не представляю ситуации - "ну вот, я наконец то написал приложение до конца и больше писать не надо". Мне кажется это какое то вечное движение.... главное момент когда он начнет давать результат... а у меня на сайте есть форма заказа и сайт уже дает результат (хыхы) . и теперь я хочу добавлять для пользователей всё больше и больше удобств...потихоньку... --- Добавлено --- Звучит очень разумно...
Объясняю "на пальцах" ООП это не прихоть, а необходимость! Классы и интерфейсы помогают поддерживать порядок, упрощают модификацию кода, ускоряют "въезжание" в проект новых разрабов и т.д. Короче снижает стоимость владения, увеличивает качество продукта. То есть без вариантов новый проект должен быть в объектном стиле, с понятным API, слабо связанный и т.п. Современный, короче. НО, *ЛЯ!!! Существуют не только новые проекты. Бывают системы с большой историей. "Легаси" — унаследованный код, который хочется сапгрейдить под современные стандарты. Однако толковый менеджер проекта понимает, что рефакторинг может обойтись дорого и при этом не иметь значимого внешнего эффекта. Рефакторинг это и есть переделка внутренности с сохранением функционала, как его видит потребитель. Владелец бизнеса будет спрашивать "а нахуа я плачу, а ничо не улучшается. почему заявки на новый функционал не выполняются, а вы тратите время на непонятную муйню". А ведь ещё могут быть накладки и новые баги! То есть для менеджера тотальная переделка крупного проекта на ООП это самоубийство. Долго, дорого, бестолково. Поэтому серьезные переделки откладываются на потом. А улучшения делаются эволюционно, а не революционно. Чтобы хотябы единство стиля сохранялось. Иначе вообще наступит полная потеря контроля. Вот что такое "легаси", чем работа на действующий бизнес отличается от "ковыряния для себя" и почему именно ООП бывает не нужен.
на стадии прототипа можно писать хоть жопой. Пока нет людей и нет просадок производительности, или нет нет команды, которая трудится за зарплату, то пиши как хочешь, лишь бы быстрее и работало бы. Это единственные критерии.
поддерживаю. на начальной стадии главное чтобы побыстрее. вот когда дали добро (и бюджет), надо сесть, выдохнуть и спланировать всё правильно чтобы тотально не переписывать в ближайшие год-два.
ООП, процедурки, все упирается в архитектуру конечную. А она бывает разная. У меня, например, как уже говорил когда-то, 100% процедурное ядро в проекте. Оно очень быстрое, без оверхедов и избыточности. Разделено на файлики, а каждый файлик - простыня функций, которые никак не связаны друг с другом. Вроде процедуры, а спагетти-боли нет. Это нижний слой абстракции, то, что под капотом. В случае чего, туда просто заходим, и правим, дописываем, рефакторим нужную функцию, ни о чем не беспокоясь. Разделено на файлики оно не просто так. Файлики поделены по принципу общности функций для такой-то задачи. То есть есть фрагмент, отвечающий за работу с БД, есть фрагмент, отвечающий за работу с ФС и тд. Над ними стоит статичный сборщик, который дублирует сигнатуры всех публичных функций из ядра (ведь есть и функции, не предназначенные для работы снаружи), и формирует из них API. И когда я дергаю API::$send_query($query), например, этот сборщик смотрит, с какой функцией слинкована данная сигнатура, подключает фрагмент ядра, в котором она содержится, и проксирует вызов в нее. В итоге снаружи API - монолитное. Изнутри - поделено на фрагменты. И вот вроде бы полностью процедурное ядро уже оказывается обвязано ООП-статикой. В то же время существуют и внешние компоненты системы, которые построены строго на ООП, покуда являются своего рода "приложениями" для остальной системы и требуют инстанцирования по запросу. И вот уже оказывается, что на уровне над API система объектно-ориентированная... Внимание вопрос. Стоит ли вообще обдумывать "ооп против процедурок" в то время, как это не обязательно взаимоисключающие подходы? Они просто разные. Со своими плюсами и минусами. Используйте процедуры там, где нет смысла в ООП. Используйте ООП там, где глупо использовать процедуры. Не гонитесь за модой, гонитесь за рациональностью. Вот и все.
Мои 5 копеек про ооп. Ну например можно в приватных свойствах объекта хранить данные и сделать доступ к ним через публичные методы - это инкапсуляция данных. Только естественно это если нужна какая то логика установки или получения этих данных. Потом ты можешь указать у аргумента метода уточнение типа - родительский класс, и подставлять этому методу потомков(с разной реализацией одних и тех же методов). Это полиморфизм. Это первое что сразу пришло в голову. Вообще надо иметь ввиду что например в ООП есть наследование, абстрактные классы, интерфейсы, всё это выливается в шаблоны проектирования, которые решают задачи, которые, например, при процедурном придётся решать хер пойми как.
Процедурный стиль быстрее? или меется ввиду что написано так у вас что работает быстрее? --- Добавлено --- Из всего написанного мне не так много поянтно... единственное что понял, надо пока что писать как умею, тем более что и так знаний мало... и быть готовым в будущем переписать , переделать часть проекта
быстрее, но это экономия на спичках. Когда приложение вырастет то узкое место будет совсем не тут. А вот поддерживать и развивать далее этого монстра выйдет дороже, чем если бы это было ООП.
В моем случае нет, я же описывал, там нет макаронокода. Процедурный код является как бы продолжением статического класса API. Все четко по полочкам, все подчинено строгой логике. Все на своих местах. Без спагетти. "Совершенство - не когда нечего добавить, а когда нечего убрать"(с) ООП - удобство, за которое мы платим оверхедами. Накрутить их можно всегда и везде, в десять слоев. Но если можно обойтись без них, без вреда в перспективе - я стараюсь обходиться без излишеств. В моем случае считай что есть статичный класс API, который содержит только сигнатуры функций, но на самом деле обслуживает набор процедурных библиотек. Это сделано не потому, что хочется прям экономить на ООП-обвязке, не. В данном случае архитектурное решение завязано на то, что очень хотелось статичное API, но очень не хотелось пилить страдающий ожирением файл. Вот и было решено оформить все в виде "ромашки", где лепестки - это процедурные либы, а центр - статичный линкер. До таких вещей еще надо, что называется, дойти. На это нужно время. И да, ты за деревьями лес не увидел. Основной посыл не в том, что "юзайте процедуры, они быстрее!!11расрас", не. Основной посыл в том, что все зависит от конечной архитектуры. Которая, к слову, будет у тебя по ходу пьесы меняться кучу раз, прежде чем устаканится. --- Добавлено --- --- Добавлено --- Ни то ни другое не должно быть самоцелью. Здравомыслие и расчет. Более ничего не нужно.
Учитывая , что я вообще не знаком с ооп, ощущаю что мне надо продолжатть процедуры и паралельно изучать ооп. по мере изучения сравнивать и переделывать. Другого решения пока не появилось. Спасибо.
Ты поймешь, что тебе нужно ООП, когда упрешься в необходимость его использования. Пока ты учишься она, видимо, еще не наступила. Но наступит так или иначе. Всему свое время.
До тех пор пока твоим движком рулишь ты один - это работает. Когда твой движек начнут юзать и допиливать другие - начнется основное веселье. ООП больше дисциплинирует, позволяет других тоже придерживаться заложенной зависимостью, логикой и порядком в коде. С набором разрозненных процедурок это сложнее обеспечить, но можно, по сути реализовав тот же ООП самому. а зачем делать то что уже реализовано.
Развели тут холивар понимаешь, а потом приходит перец, приносит свои макароны обернутые в типа ООП с кучей статических функций. На вопрос где у тебя хоть какая-то выгода от применения ООП? Молчит, краснеет и ковыряет пальчиком стол, молвит заученые: ну, другим допиливать, полиморфизм, все дела. Ребята, но ведь можно и на сях писать с "почти" ООПом, но это не делает ООП серебрянной пулей, не зацикливайтесь. Если можно делать проще - делай проще, будет нужда - будешь думать, городить интерфейсы, но имеено для веба (в 95%), все-таки в силу специфики - крайне редко такое бывает действительно нужно. Часто начинается, из-за отсутсвия опыта, но присутвия знаний: а не запилить-ли такую архитектуру, чтобы в случае чего было потом меньше было геморроя, только этот "случае чего" - не наступает, а следом так и лежат тонны абстракций, интерфейсов (и время потраченное на проектирование оных) ходит автор вокруг и спотыкается.
использовать ООП не значит делать сложнее. это кстати основное заблуждение. наоборот, с ООП код может стать более простым и легким в поддержке. никто не заставляет сразу городить сотни абстракций. все делать в меру, ориентируясь по ситуации и задаче. принцип KISS работает и с ООП. холиварить тут действительно неочем. Суть в том, что ООП давно уже норма, знать и использовать которую должен любой программист, который хочет зарабатывать этим бабки. Для себя - пиши как угодно. дело твое. Для заказчика - будешь писать так как потребуется ему. А серьезному заказчику потребуется ООП на 99%. ибо это уже давно стандарт. Везде где платят хорошие деньги - требуют знание ООП. и чтоб писать новое, и чтоб разбираться с многослойными абстракциями и оверхедом. это реалии. можно сколько угодно гнобить ООП, но незная его - ничего незаработаешь в Вебе. а наговнокодить можно хоть на ООП хоть на процедурках, хоть на чем.