Всем добрый вечер! Было бы интересно узнать у гуру что является признаками хорошего тона программирования в классах на php. Давно программирую в модулях и недавно начал разбираться в ооп. Знакомый программист глянув в мой класс тут же сказал "во первых призаком хорошего тона является обращение к свойствам через методы". Такие вещи в учебниках не пишут интересно сколько еще существует таких правильных и важных тонкостей.. заранее спасиб!
wmlcode, это является хорошим тоном (а точнее заделом на будущее) в случае если язык не поддерживает геттеры и сеттеры. пхп это не касается...
Яснее? Обращение к свойствам через методы действительно стоит выписывать. Чтобы потом при переделке $adres['string'] в $adres['shortstring'] и $adres['longstring'] не переписывать все модули, где он используется. - для того ООП и нужен. Если это на тему, что такое сильно тормозит скрипт - пример в студию. Реальный, а не миллион вызовов без обертки.
если честно 2 с лишним года пишу, до сих пор не понял для чего нужно писать свои классы и использовать ООП. хотелось бы знать для чего используется первое и второе,и причины. Чужие классы если приходится разбираю, а вот писать как то не приходилось,хотя возможно где то я просто сделал функции которые выполняют работу классов.
ооп - это логика, а написана она в классах или функциях - это вторично, хотя кое-чего в функциях будет написать сложно. первое - это логическое разделение на куски так, чтобы они были "черными ящиками" друг для друга. при полной замене одного куска остальные этого просто не замечают, как вызывали и передавали так и передают. Называется инкапсуляция )) Второе - это наследование. Возьмем пример. Нам нужен проект с кучей мелких разных (по функционалу) форм. Пишем класс, который получает данные и выводит их. Какие - неважно, те что у него есть. Сам он создавать объекты никогда не будет и является абстрактным. А вот ему наследуют классы simpleform, complexformA, complexformB который представляют вполне рабочие формы с минимальным функционалом. Теперь, если нам нужно создать свою новую форму, мы создаем класс myComplexFormA0, который наследует классу complexFormA, до/переписываем ему одну функцию (метод) и подставляем шаблон. Все. Почему бы просто не скопировать класс complexFormA ? Потому что когда мы захотим переделать его, мы это сделаем в одном месте и все формы, созданные не только нами, но и васями пупкиными, будут продолжать правильно работать. тоже самое и с базовым абстрактным классом. Переписали под другой шаблонизатор - остальные этого не заметили. Теперь представим, что абстракный класс - работы с базой как самый тупой пример - пишет Вася, шаблонизатор - Петя, а логику формы - миша. Вечером они втроем сели и расписали какие методы будут использоваться и разошлись по домам писать. Утром Вася принес класс db , Петя класс template, Миша класс form Каждый из них использовал ночью класс-заглушку, то есть у Миши были для отладки классы db и template, которые выдавали хоть что-то правильно по структуре, пусть всегда и одно и тоже. В результате утром все работает с первого раза, отладка вся была разбита заранее на логически внятные маленькие части с четким распределением что в каком месте обрабатывается и в каком виде выдается. При этом Миша и Петя никогда не видели запроса MySQL, а Вася не знает что означает JS. Чтобы все это работало, необходимо задать чуть более жесткие, чем обычно, правила написания кода, чтобы избежать в будущем ситуаций "эту функцию поменяли, а соседняя уже использует старую структуру", который неизбежен при "процедурном подходе". Нужно выдумать такие правила, чтобы тупо их выполнять и самому не отслеживать все варианты цепочек что где используется. Все равно что-то забудешь/не учтешь, и все разъедется. "Правила ООП" - отдавать свойства через методы, не пускать к себе чужих функций даже если это сейчас кажется удобным и т.п. - именно такой набор, который позволяет писать код, плюс разделять логику на отдельные части для быстрого написания и отладки отдельных кусков.
попиишешь лет 10 - поймешь, что разработка в ООП в сотни раз продуманнее и быстрее чем во всем остальном, плюс наращивание функционала при грамотной модели классов не сравнима с другими подходами, но это никоим образом не лишает функций своих преимуществ.
просто когда один занимаешься несколькими проэктами можно смело забыть о необходимости свои действия связывать с чьими-то еще + есть привычка, по возможности всегда писать код самому, даже если уже есть какие-то готовые библиотеки для выполнения каких то задач. Правда когда написание так растягивается иногда бывает натыкаешься древнюю часть кода и думаешь какже она легко упрощается. А насчет инкапсуляции, я давно уже догадался , что все функции и должны работать как черные ящики Функцию можно точно также отнаследовать, просто дописать к ней нужный функционал и встроить использование "старой версии" У меня до сих пор используется в паре мест вариант который просто вызывает функцию с параметром "old" или "new",где new это просто новый стандарт обработки. Большое спасибо за лекцию, теперь я знаю когда стоит применить то что я обычно не использую!
вот когда стали это реализовывать, получилось ООП. С тех пор его где-то ухитрились улучшить, а где-то испортить, и много народу лепит косяки не понимая логики. Но она (логика) от этого не изменилась. И писать ООП с помощью ООП, не изобретая велосипеды, проще, надо просто въехать в тему ))