-
Юбилейный DevConfX пройдет 21-22 июня в Москве. Как всегда — Вы решаете, кто попадет в программу секции Backend — голосуйте за интересные доклады
Программирование классами
- Автор темы Netman
- Дата начала
Димон
Новичок
Согласен, zf не идеален. Но что значит идеальный код? Все люди рассуждают немного по-разному. То что очевидно для меня, не обязательно будет очевидно для другого.
Есть некоторые правила, которых я всегда придерживаюсь в работе (которые не раз экономили время):
- отсутствие глобальных переменных
- конфиг только один для всего проекта
- понятные названия функций и переменных (англ. здесь помогает)
- самодокументированный код (если в коде много коментов, значит что-то с ним не так)
- отсутствие DRY (dont repeat yourself), т.е. нет копипаста
- вынос общей логики в абстрактные типы
- не делать классы по типу "весть трэш в одной корзине"
- выносить общую логику в узловые классы, т.е. поднимать вверх по иерархии наследования
- не "наследовать" холодильник от телевизора, только потому что у обоих есть шнур электропитания
- макимально ограничивать доступ к методам и аттрибутам класса, т.е. если он толко приватный, то не делать его защищенным или публичным
- делать маленькие и понятные методы класса, т.е. не писать функцию, в которой туча if ... else, а разбить ее на несколько подфункций (огромные функции такое же зло, как и глобалсы), НО не плодить ненужные сущности
- не усложнять код, т.е. не применять наследование там где это не нужно
- проверять инвариантность объекта, там где необходимо (т.е. перед тем как что-то с ним сделать проверить все ли аттрибуты в порядке, например объект подключения к БД)
- отлавливать ошибки через try ... catch
- разумно использовать паттерны
- И САМОЕ ГЛАВНОЕ: писать код в первую очередь для человека, а не для компьютера
Это прописано в хороших книгах по программированию (читайте C++ от Бьерна Страуструпа). И это действительно так. Это помогает. И делает жизнь кодера лучше
Надо учиться. Если человек написал DLE или Bitrix и потом гнет пальцы, хрен его кода переубедишь в недальновидности его подхода. Покупают код ведь менеджеры, которые смотрят на цену, скидки и красивую упаковку, а не на то что внутри.
Есть некоторые правила, которых я всегда придерживаюсь в работе (которые не раз экономили время):
- отсутствие глобальных переменных
- конфиг только один для всего проекта
- понятные названия функций и переменных (англ. здесь помогает)
- самодокументированный код (если в коде много коментов, значит что-то с ним не так)
- отсутствие DRY (dont repeat yourself), т.е. нет копипаста
- вынос общей логики в абстрактные типы
- не делать классы по типу "весть трэш в одной корзине"
- выносить общую логику в узловые классы, т.е. поднимать вверх по иерархии наследования
- не "наследовать" холодильник от телевизора, только потому что у обоих есть шнур электропитания
- макимально ограничивать доступ к методам и аттрибутам класса, т.е. если он толко приватный, то не делать его защищенным или публичным
- делать маленькие и понятные методы класса, т.е. не писать функцию, в которой туча if ... else, а разбить ее на несколько подфункций (огромные функции такое же зло, как и глобалсы), НО не плодить ненужные сущности
- не усложнять код, т.е. не применять наследование там где это не нужно
- проверять инвариантность объекта, там где необходимо (т.е. перед тем как что-то с ним сделать проверить все ли аттрибуты в порядке, например объект подключения к БД)
- отлавливать ошибки через try ... catch
- разумно использовать паттерны
- И САМОЕ ГЛАВНОЕ: писать код в первую очередь для человека, а не для компьютера
Это прописано в хороших книгах по программированию (читайте C++ от Бьерна Страуструпа). И это действительно так. Это помогает. И делает жизнь кодера лучше
Надо учиться. Если человек написал DLE или Bitrix и потом гнет пальцы, хрен его кода переубедишь в недальновидности его подхода. Покупают код ведь менеджеры, которые смотрят на цену, скидки и красивую упаковку, а не на то что внутри.
Бред, ты тогда делаешь невозможным расширить свою систему. Я захочу добавить к твоей системе некоторые изменения топустим 1 новый метод, и мне придется хардкодить - изменять твою систему, а не унаследовать твой класс и просто описать еще одну функцию.
Именно с этой книги начинал изучение ООП, но не согласен что у него все подойдет для пхп.
x-yuri
Новичок
чем-то отличается от подъема по иерархии?
а можно подробнее?
а что ты можешь сказать про
http://www.joelonsoftware.com/items/2003/10/13.html
http://blogs.msdn.com/oldnewthing/archive/2004/04/22/118161.aspx
Духовность™
Продвинутый новичок
к чему эти ссылки? к холивору?
x-yuri я вот смотрю за твоими постами, у тебя прям любимое дело умышленно придираться к частностям и СПОРИТЬ. Сейчас автор приведёт тебе кучу доводов в защиту исключений и что дальше? Тема растянется на 100 страниц?
Димон
Новичок
На эту тему мы как-то спорили с техничекским директором. Он рекомендовал все методы делать защищенными для упрощения наследования. Если тебе нужно переопределить один метод из родительского класса, никто не запрещает тебе переопределить его как защищенный из приватного. Если приходится заменять много методов, значит в твоей новой архитектуре не все в порядке. Здесь все зависит от задачи. Если я пишу конкретный тип, то мне незачем делать его методы защищенными. Если это узловой класс или подразумевает это, то тогда некоторые его методы делаются защищенными.
Цитата: "Защищенные методы не вредны, хотя и полезность их тоже никто не доказал".
Здесь опять же нужен здравый смысл. Не надо лепить то что не надо. Избыточная функциональность не есть гуд.
Духовность™
Продвинутый новичок
спорный вопрос. с одной стороны можно шлюз использовать и абстрагироваться от изменения класса. с другой стороны, ты не прав, ИМХО.
Димон
function b()
{
$c = $this->c();
return $c;
}
private function d()
{
return true;
}
}
мне понадобилось сделать свою функцию b() чтоб не менять твой код я создаю новый класс и наследую
class a2{
function b()
{
$c = this->d();
return (int)$c;
}
}
Опа, и фатал еррор. Мне придется еще и тащить функцию d, хоть я и не хочу ее менять.
class a{
function b()
{
$c = $this->c();
return $c;
}
private function d()
{
return true;
}
}
мне понадобилось сделать свою функцию b() чтоб не менять твой код я создаю новый класс и наследую
class a2{
function b()
{
$c = this->d();
return (int)$c;
}
}
Опа, и фатал еррор. Мне придется еще и тащить функцию d, хоть я и не хочу ее менять.
HraKK
читерский довод. если метод объявлен приватным, то его ни в коем случае нельзя использовать так использовать, ведь заприватили его зачем-то. на то он и чёрный ящик. кстати, насколько я знаю, в некоторых языках можно в наследниках использовать названия методов, которые объявлены к предке приватными.
читерский довод. если метод объявлен приватным, то его ни в коем случае нельзя использовать так использовать, ведь заприватили его зачем-то. на то он и чёрный ящик. кстати, насколько я знаю, в некоторых языках можно в наследниках использовать названия методов, которые объявлены к предке приватными.
