вопрос по ООП

[grigori]

Суть не в том, что мы доказываем необходимость использования полей класса для доступа к данным где только возможно. Мы так _НЕ_ считаем.

Смысл наших постов - нет причин не использовать поля _никогда_.
Целесообразность использования полей определяет программист, и ДОГМЫ тут НЕТ.

Причины никогда не использовать register_globals существуют всегда
Причины [не]использовать поля могут [не]существовать, в зависимости от логики объекта.

Последователи святого TDD ... успокойтесь, наконец, не переходите на личности : )))
Не все принимают вашу религию, не все...

 

[whirlwind]

ИМХО, можно сформулировать покороче 6 страниц. Все знают что DRY - это хорошо и что code reuse это то же хорошо. Хорош или плох тот или иной класс, зависит от того, в скольких проектах он заюзан. Используется ли доступ к публичным свойствам или нет, не влияет на количество проектов, в которых используется класс. Но от этого напрямую зависит получится ли унифицировать класс для использования его в еще большем количестве проектов, а это уже связано с тем, насколько класс поддается модификации. Публичные атрибуты не способствуют рефакторингу -> класс трудно поддается модификации наследники ограничены поведением базового класса (нельзя ничего сделать с атрибутом ни при установке ни при получении) -> вместо того, что бы изменить несколько строк исходного или унаследованного класса, приходится писать новый -> срок жизни класса меньше -> класс плохой

 

[HraKK]

брррред. Вернее софистика

 

[whirlwind]

HraKK глубокомысленный вывод, подкрепленный непробиваемыми, просто-таки железными аргументами. Мне не остается ничего, кроме как скромно удалицо читать учебники.

 

[HraKK]

whirlwind
Нет просто сегодня у меня нету времени остаивать, это мнение. Я вернусь к нему немного позже. Не возражаешь?

 

[grigori]

Автор оригинала: whirlwind
Хорош или плох тот или иной класс, зависит от того, в скольких проектах он заюзан. Используется ли доступ к публичным свойствам или нет, зависит, получится ли унифицировать класс для использования его в еще большем количестве проектов, а это уже связано с тем, насколько класс поддается модификации. Публичные атрибуты не способствуют рефакторингу ... -> класс плохой

Это действительно Софистика.
Утверждение "Хорош или плох тот или иной класс, зависит от того, в скольких проектах он заюзан." является догмой, и я лично с ней не согласен.
Скорость работы каждого конкретного проекта и компактность исполнения для меня важнее, чем количество копий класса.
Мне лучше редактировать несколько строк класса каждый раз, чем оставить треть функционала для совместимости.
Лучше написать 3 разных класса, чем держать 2/3 неиспользуемых методов, используемых в других проектах.

Есть отличный фреймверк Horde... Но это просто _не_мой_ подход к программированию.

 

[HraKK]

grigori
+1 Именно это и собирался написать... но последние дни очень занят(

 

[Vallar_ultra]

grigori

Эт если проекты разовые и не синхронизируются друг с другом. backward compatibility - это тоже важно, особенно в больших коммерческих проектах.

 

[HraKK]

Я не приемлю универсальность. При достижении универсальности мы всегда чем-то жертвуем.

Я всегда делаю что то типа незавершенного framework'a который подправив можно использоввать в одном, или другом проекте. Затраты мизерные - результат порой громадный.

 

[Vallar_ultra]

HraKK

А если ты будешь продавать сам framework, а не его custom-вариации???? Тогда как быть?

 

[HraKK]

Я продаю проекты. Система на которой я ее реализую никому не надо.

А если будут покупать - поверь она не подойдет для сайтов заодынденьсклепаю! Она для более серьезных проектов. И там универсальность неприемлима. Онли маштабируемость/рефакторинг.

 

[grigori]

Vallar_ultra - я, конечно, могу попросить определение "больших проектов"... но это уже занудство и "не в ту степь"
Да, именно про "большие" я и пишу.

-~{}~ 19.01.07 23:53:

Автор оригинала: HraKK
Я не приемлю универсальность. При достижении универсальности мы всегда чем-то жертвуем.

Я всегда делаю что то типа незавершенного framework'a который подправив можно использоввать в одном, или другом проекте. Затраты мизерные - результат порой громадный.

Комрад, я с тобой

-~{}~ 19.01.07 23:56:

Автор оригинала: Vallar_ultra
А если ты будешь продавать сам framework, а не его custom-вариации???? Тогда как быть?

Каждый работает на своём рынке.
Просто не надо сравнивать, что правильней.

Я нашел себе рынок готовых решений "под ключ", включающее, к тому же, и настройку сервера, и 24*7 support.

 

[Vallar_ultra]

grigori & HraKK

Вобщем я согласен с вами, но только в том что для создания законченного проекта этот подход хорош. В случае если этот инструментарий упаковывается в какую-то графическую оболочку и начинает продаваться как пакет, то тогда этот подход уже не канает. ИМХО.

 

[grigori]

Хехе Так оно и есть.
Нужен человеку сайт знакомств за $150? Нет проблем!

А вот когда у владельца проекта сайт начинает тормозить, он обращается к нам с вопросом "чё делать?", и платит уже за индивидуальное решение.

Так и живём

 

[HraKK]

Если этот твой продукт упаковать в красивую оболочку получишь - битрикс)

 

[Vallar_ultra]

grigori

Твои б слова - да богу в уши! Не.... лучше нашему нач-ву! Во!

HraKK

битрикс - это удар ниже пояса!

 

[whirlwind]

grigori
HraKK

Ну если вы подгоняете под догму все, что не укладывается в ваше мировостприятие - прошу ваше определение "хорошего" класса. Только давайте сразу не будем про скорость, иначе я просто вынужден подозревать что ваши проекты не более в чем 10-20 неуклюжих классов, наполненными хаками. В этом случае уж пусть мои классы будут софистикой, чем спорить с вами. Если для вас 15 минут переписывания с нуля дешевле 15 секунд "освежения" в пямяти того, чем занимается этот класс - флаг вам в руки и побольше таких "счастливых" проектов.

 

[С.]

Vallar_ultra, есть заточенные под клиента решения и есть универсальные. С первыми все ясно. Из вторых на РНР я знаю только один полностью универсальный пакет -- сам РНР. Любые попытки его "улучшить" это значит начинать его "затачивать". А поскльку заточить его до конца невозможно (потеряется универсальность), то получается говно, плавающее в проруби и немогущее пристать к никакому краю.

 

[Vallar_ultra]

С.
Согласен. Но ведь если разделить Базовый Функционал, Бизнес Модель, Представление и Систему управления всем этим хозяйством - то эта какашка не будет хотя-бы вонять....
Почему никто из коммерсов этого не сделает?

 

[С.]

Почему никто из коммерсов этого не сделает?

Во-первых, потому, что это не будет продуктом и его нельзя продать. Это даже не полуфабрикат, а так, заготовка какая-то.

Во-вторых, эти три слона такие аморфные, что до сих пор никто не знает, где кончается один, и начинается другой. Типичный пример - фанатовский инпут с шаблонами. Поэтому любое решение окажется либо примитивным, либо нарушающим принципы.

Лично я считаю, что есть одна ниша, куда можно развиться РНР без потери универсальности - надстройка над HTTP. Например, приложение не должно знать, откуда пришли данные из гета, поста, сессии или куков. Один раз указал правила и забыл. Но почему-то во многих системах даже контролер этого не делает, и модель работает напрямую с HTTP. Уродство!