Pull to refresh
0
0
Переслегин Дмитрий @dmitry_dvp

Пользователь

Send message
До встречи на конференции лидеров WEB-разработки

Не слишком самоуверенно?
все последующий попытки сделать игру этого жанра были мягко говоря неудачными.

p.s. всякий раз, когда мой недопровайдер обрубает мне связь - нахожу папочку TTD и погружаюсь в этот безумно интересный мир
И я ничего не понял. 3 двери - по 33% на каждую ... две двери - по 50% на каждую .... откуда 2/3 - не понимаю
мне кажется ещё до написания ф-ии человек должен знать, static она будет или нет. И уже тем более он обязан отметить её как static
лучше - третий вариант, которого вы не описали

class News extends DAO {
const TABLE_NAME = 'news';
static function getTableName()
{
return self::TABLE_NAME;
}
static function getObjects()
{
parent::getTableObjects(self::getTableName());
}
}
Возможно вы правы. Наверное мне следует себя пересилить и принять наконец такие конструкции в коде как "get_class", "фишка static::CONST", и т.д.

но пока удается прожить без этого (возможно лишними усилиями), и я этом рад :-)
честно признаться не понял что вы сказали, скорее всего из-за своей недалекости, но вот последнее предложение у меня вызвало массу эмоций:

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

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

А своих работах я вижу, где за счет этой фишки я могу убрать 5-10 строк кода (заменить геттеры), но делать этого не стану, ибо константа должна быть константой
быть может я недалек, но что-то мне подсказывает, что пользование такой "фишкой" только усложнит понимание и сопровождение кода
ну вот я и говорю - структура рабочая, но непереносимая. Т.е. реального применения интерфейсов и наследования - нет.
Я не готов описать это в одном сообщение. Если кратко: ООП следует применять исходя из принципов создания четкой и гибкой структуры приложения, что вовсе не означает необходимость инкапсуляциии всего в классы
тогда непонятно зачем вам вообще интерфейс DbCacheStorage, если фактически применить другой объект (например ApcCacheStorage), реализующий этот интерфейс нельзя ибо тогда приложение останется без коннекта к СУБД
Абсолютно согласен с вами, но в реалиях жизни времени на самодокуметирование - нет.
А жизнь облегчить можно так же и докой (даже результат работы phpDocumentor'а может оказаться юзабельнее интерфейсов на видном месте)
Пункты 3 и 29 - вообще одно и тоже ... автору списка - дизреспект
>> Не всё должно быть ООП, часто это излишне, поскольку каждый метод и объект занимает много памяти.

туда же ... не все должно быть ООП, но вовсе не по этой причине
>> Было: if (strlen($foo) > Стало: if (!isset($foo{5})) { echo "Foo is too short"; }

в топку такие советы. Сэкономленная наносекунда не покроет расходов времени на формирование мимики на лице программиста, получившего такой код в поддержку
а не получается ли у вас 2 подключения к DB? одно от CacheStorage, а второе от основного DB, используемого в приложении?
упс. Думал об одном, а написал другое:
В общем я перестраховываюсь на случай рефакторинга "поднятие метода"
Я бы сформулировал так:
Меня не тянет к ключевому слову interface.

А вдруг я затра обнаружу у всех своих "реализаторов" интерфейса IPrintable, один и тотже метод "::print()" - мне станет жутко неуютно
Об этом применении уже было сказано:
http://habrahabr.ru/blog/php/38961.html#…
http://habrahabr.ru/blog/php/38961.html#…

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

Information

Rating
Does not participate
Location
Москва и Московская обл., Россия
Works in
Date of birth
Registered
Activity