У Вас потрясающе романтические представления о причинах отраслевых процессов :)
Друзья, мне бы поработать надо, вечером все отвечу!
И еще раз: хотите поговорить про форматирование кода - создавайте тему, обсудим, что такое "нормальное форматирование".
Может Вы просто не умеете его готовить? А функции-то хоть в php Вы используете? Или goto хватает? :)
Наверное, все-таки классов? И-таки чем сишные объекты правовернее, ну, кроме статической типизации, про которую тоже можно поспорить?
Посмотрите всякие фреймворки. Они только с виду страшные, если поковыряться - много интересного найдете :)
Да любой пример :) Хоть бы вот этот:
и т.д. В окружении веб-сервера это все не имеет смысла, в вебе не нужны объекты, висящие в памяти и ждущие событий, в вебе объекты существуют на протяжении долей секунды, от создания до отдачи клиенту. (Возможны исключения, но с ними нечасто приходится сталкиваться). А в JS всю эту кутерьму как раз можно использовать. Подумайте над архитектурой тетриса, например, как бы Вы его стали реализовывать :)
Поскольку при наследовании потомок сохраняет интерфейс родителя, использование наследованных классов действительно можно считать полиморфизмом, но лишь в том случае, когда это происходит прозрачно для клиентского кода. Под "родным кодом", который "не меняется", я имел ввиду исходники, поставляемые сапой. В клиентском же коде мы можем сделать какие-то правки, можем дописать к базовому классу какой-то функционал и явно использовать его - тогда наследование останется, а полиморфизм исчезнет. Ну, думаю ясно, это все философия :)
Потому что эффективность оффлайн-программистов в буржунии измеряется непустыми строками кода ;) Предлагаю прекратить оффтопный холивар про скобки и заняться делом, т.е. холиваром про ООП. Хотите поговорить о скобках - велкам в отдельный топик.
Как тут уже сказали, это не лучший пример ООП. Тем не менее, даже в таком виде он позволяет делать небольшие трюки.
1. Наследуемся от их класса, переопределяем raise_error(), делаем отправку уведомления об ошибке по мылу, или по аське, или запись в лог, или еще что угодно. "Родной" код при этом не меняется, мы можем его обновлять. Это наследование.
2. Другие методы тоже можно переопределять, как именно - вопрос фантазии. Если бы декомпозиция класса была выполнена более аккуратно, вариантов было бы больше. Например, можно сделать, чтоб ссылки брались не из медленного файла, а из какого-нибудь быстрого кэша. Поскольку информация о способе хранения и извлечения данных спрятана за интерфейсом, клиентский код от наших экспериментов не пострадает. Это инкапсуляция.
3. Можно, например, написать адаптер, приводящий вызовы нескольких разных бирж к единому интерфейсу, использовать какой-нибудь порождающий шаблон, чтоб изолировать код, который решает, какая биржа лучше подходит на этой странице (т.е. будет создавать экземпляр нужного класса), и далее во всем клиентском коде отображать ссылки, вообще не имея понятия, откуда они взялись. Это полиморфизм.
Тут можно поспорить, что на функциях можно сделать то же самое.
Во-первых, пример не самый удачный - когда интерфейс по сути состоит из единственного метода, действительно выигрыш не велик. Но это не значит, что ООП плохо, просто этот конкретный класс спроектирован в стиле "минимализм" :)
Во-вторых, даже на этом примере прекрасно видна важная прикладная причина удобства ООП: понятный способ хранения служебных данных, используемых несколькими методами. В функциональном стиле пришлось бы либо засорять глобальную область видимости (жди проблем, например при многократном вызове), либо - таскать между вызовами какую-то структуру, что усложняет интерфейс, требует доп. описания в доках и т.д.
Ну и наконец самый простой, но очень важный аргумент. Сейчас ООП - это не только стандарт технологический, но и стандарт мышления большинства специалистов. Они видят мир в терминах классов и методов. Если ты видишь мир как-то иначе, будет довольно сложно общаться с коллегами и использовать результаты их труда. Это не хорошо и не плохо, просто на сегодняшний день это так. Наверное, потом будет как-то еще.
P.S. Кстати, могу еще рассказать, почему многим пыхарям сложно въехать в ООП. Дело в том, что большинство примеров, удачно иллюстрирующих основные принципы, не слишком применимы в вебе, в силу специфики среды (которая в большинстве случаев - однопоточная, синхронная, и где объекты не существуют на протяжении долгого времени). В вебе приходится иметь дело с абстракциями другого рода, и это сбивает с толку. Я бы, кстати, рекомендовал веб-программистам, желающим въехать в ООП, тренироваться в области JavaScript. Хотя там реализация ООП довольно нетривиальная, реальные практические преимущества подхода, мне кажется, там понять легче.
Хотелось бы посмотреть бенчмарки, желательно с абсолютными величинами. А то по вашим словам может сложиться впечатление, что проект, выполненный в процедурном стиле, только за счет стиля работает втрое быстрее :)
1. Проблема - закончилась оперативная память, которую может сожрать PHP.
2. 35 мегов - это довольно много. На шаред-хостинге едва ли дадут увеличить, но все же попробуйте
ini_set("memory_limit","50M");
3. Вероятно, скрипт устроен неправильно, едва ли есть реальная необходимость держать столько добра в памяти. Обратитесь к разработчику - как правило, можно найти, что за мусор скапливается.
4. Если скрипт умеет сохранять состояние и стартовать с произвольного места - можно выкрутиться относительно просто - в итерации проверять, сколько памяти потрачено, и при приближении к лимиту - сохраняться и прекращать работу с последующим повторным вызовом.
Есть мысль протащить контрабандой канистру контрабандного рома. Погрузим Ктулхе в барабан 😂
Костя, мы с Олегом вроде обрулили историю с оборудованием, завтра Олег едет в кабак смотреть (я может присоединюсь), в понедельник днем едем на репетиционную базу. Олег сказал, что со слов кабачников звук у них хороший, и нам свой тащить скорее всего не придется.
И да, мой телефон: 8 (985) 119-59-92, мало ли кому пригодится :)
Chikey.ru, будете проповедовать свою ересь, когда выйдете из бана, ок? А пока почитайте правила форума, пригодится.
Тему закрываю за отсутствием ТС.
юни, Костя вроде говорил, что "Director" - не окончательный вариант.
И такое название на сайте было еще до этой темы, если не путаю.
Ну и чего, 130 постов, а ни названия, ни сисек? Топику незачот :(
Чем zAdmin / dataman перестал устраивать, кстати?
По сабжу +1 к юни, "Генерал" хорошее слово. А в буржуйском варианте может быть "Generalized CMS", т.е. "Обобщенная CMS", что вполне отражает суть, как я ее помню.
Дык мало знать, что они просто "есть", хочется ж еще и посмотреть.
И я бы рекомендовал в первую очередь внести в каталог CMSMagazine не свои работы, а работы нескольких разных партнеров, т.к. наличие сторонних разработчиков ("отчуждаемость") - сверхважный показатель, отличающий настоящий продукт от внутреннего студийного инструмента. Пока я не вижу ни одной реальной работы, сделанной за пределами студии Диафан.
А ты внимательнее посмотри, вдруг и правда есть?
Для интерпретации любых цифер, собранных по известной методике, надо немного включать мозг. Непрозрачность методики и нехватка данных - серьезные упреки любому рейтингу, если же методика ясна при достаточно полной выборке - все претензии к тому, кто не может должным образом проанализировать данные. Сорри за оффтоп.
diafan, скриншоты из ворда (вроде таких) очень неудобно читать, ИМХО.
Друзья, если вы думаете, что можно создать тему про работу в "Веб-строительстве", не указав вилку цен (что запрещено правилами "Работы"), а потом еще 20 постов обсуждать эти не указанные цены (что запрещено теми же правилами)... то вы неправильно думаете :)
ТС, укажите приемлемый диапазон, участники, хватит флудить.
Уношу топик в "Работу".
