- Поисковые системы
- Практика оптимизации
- Трафик для сайтов
- Монетизация сайтов
- Сайтостроение
- Социальный Маркетинг
- Общение профессионалов
- Биржа и продажа
- Финансовые объявления
- Работа на постоянной основе
- Сайты - покупка, продажа
- Соцсети: страницы, группы, приложения
- Сайты без доменов
- Трафик, тизерная и баннерная реклама
- Продажа, оценка, регистрация доменов
- Ссылки - обмен, покупка, продажа
- Программы и скрипты
- Размещение статей
- Инфопродукты
- Прочие цифровые товары
- Работа и услуги для вебмастера
- Оптимизация, продвижение и аудит
- Ведение рекламных кампаний
- Услуги в области SMM
- Программирование
- Администрирование серверов и сайтов
- Прокси, ВПН, анонимайзеры, IP
- Платное обучение, вебинары
- Регистрация в каталогах
- Копирайтинг, переводы
- Дизайн
- Usability: консультации и аудит
- Изготовление сайтов
- Наполнение сайтов
- Прочие услуги
- Не про работу
Что делать, если ваша email-рассылка попала в спам
10 распространенных причин и решений
Екатерина Ткаченко
Авторизуйтесь или зарегистрируйтесь, чтобы оставить комментарий
Здравствуйте.
Пишу движoк под свои нужды. Столкнулся следующей проблемой архитектуры ООП.
Есть, к примеру, класс Error. Который может отображать 4 типа ошибок: фатальная, ошибка, предупреждение, информация. Сейчас это все дело вызывается через конструктор. В параметры метода, отсылаю следующую информацию: type ошибки, status code HTTP, code, name. В середине метода с помощью select case определяю уровень ошибки и уже выполняю определенные действия. В данном случае, есть только 4 итерации цикла, но у меня есть методы, в которых таких циклов в 5 раз больше, а количество входящих флагов до 20.
Есть ли смысл создавать отдельные методы для каждого из типа ошибки? Как по мне, это вариант действительно логичнее и удобнее, но? Как насчет производительности? Окупается ли меньшее количество циклов большим потреблением ОЗУ (ибо регистрируется больше методов)?
Есть, к примеру, класс Error. Который может отображать 4 типа ошибок: фатальная, ошибка, предупреждение, информация.
...
Есть ли смысл создавать отдельные методы для каждого из типа ошибки? Как по мне, это вариант действительно логичнее и удобнее, но? Как насчет производительности? Окупается ли меньшее количество циклов большим потреблением ОЗУ (ибо регистрируется больше методов)?
Окупается. Не парьте себе мозг проблемами расхода памяти. ООП - это не о рациональном расходе памяти, а о рациональном коде. Проблемами рационального использования памяти занимаются конкретные языки/среды исполнения/фреймворки.
Сделайте базовый класс Event, куда вынесите весь общий код. И наследуйте от Event классы Fatal, Warning, Information, которые содержат только специфический для каждой ситуации код. В идеале в этих классах у вас не должно быть ни одной строчки повторяющегося кода.
Здравствуйте.
Пишу движoк под свои нужды. Столкнулся следующей проблемой архитектуры ООП.
Есть, к примеру, класс Error. Который может отображать 4 типа ошибок: фатальная, ошибка, предупреждение, информация. Сейчас это все дело вызывается через конструктор. В параметры метода, отсылаю следующую информацию: type ошибки, status code HTTP, code, name. В середине метода с помощью select case определяю уровень ошибки и уже выполняю определенные действия. В данном случае, есть только 4 итерации цикла, но у меня есть методы, в которых таких циклов в 5 раз больше, а количество входящих флагов до 20.
Есть ли смысл создавать отдельные методы для каждого из типа ошибки? Как по мне, это вариант действительно логичнее и удобнее, но? Как насчет производительности? Окупается ли меньшее количество циклов большим потреблением ОЗУ (ибо регистрируется больше методов)?
"Потерявши голову по волосам не плачут"©
Если Вы используете ООП и сделали класс, то от пары лишних методов трагедии не случится точно.
Так что если куча методов оправданна с точки зрения ООП, то делайте кучу.
Другой вопрос, что именно в Вашей описываемой ситуации оправданность кучи методов с точки зрения ООП не очевидна, т.к. судя по описанию, тип ошибки у Вас не более чем параметр, да и действия будут повторяться.
Если код в большинстве случаев у Вас будет вырождаться во что-то вида
то по большому счету куча методов будет являться тут ООП ради ООП.
Если же ситуации в большинстве случаев реально уникальны, то почему вполне можно и бить на отдельные методы.
постройте иерархию классов - ошибок с помощью наследования. Используйте Exception'ы. Потом можно как-то так:
Т.е. вы сможете обработать нужный вам тип ошибок в соотв. catch (), если спец. обработки не требуется, то catch (Exception $ex), если все наследуются от него, будут пойманы тут.
Проблемами рационального использования памяти занимаются конкретные языки/среды исполнения/фреймворки.
Да проблема как раз в том, что с каждым днем это стает похожим на фреймворк.
Может кто-то может посмотреть участки кода, и дать хотя бы пару поверхностных советов по архитектуре. Хочется использовать ООП, но что-то вместо этого выходит не легкий и читабельный код, а комбайн-фреймворк.
Хочется использовать ООП, но что-то вместо этого выходит не легкий и читабельный код, а комбайн-фреймворк.
Все нормально. Так и должно быть. Теперь вы действительно знаете что такое ООП.
Можно все удалить и приступать непосредственно к написанию сайтов решающих практические задачи.
Есть ли смысл создавать отдельные методы для каждого из типа ошибки? Как по мне, это вариант действительно логичнее и удобнее, но? Как насчет производительности? Окупается ли меньшее количество циклов большим потреблением ОЗУ (ибо регистрируется больше методов)?
Откройте для себя Exception-ы. Посмотрите, как сделано в уже имеющихся фреймворках.
ИМХО, следует различать ООП ради ООП и ООП (а также паттерны/архитектуры: MVC, синглтоны итд) для удобства разработчика.
Говоря про производительность, не забывайте про ЛИЧНУЮ производительность - про производительность разработчика.. Это не скорость выполнения программы, а скорость решения поставленной задачи (величина, обратная времени написания нужного кода, а также времени дальнейшей его доработки/поддержки/сопровождения при необходимости). Если речь о разовом коде, разовой задаче - естественно проще "написать как есть" и забыть.. Если речь о более-менее универсальном движке/классе/наборе функций - о повторно используемом коде.. то подход должен учитывать дальнейшую возможность лёгкого "конфигурирования" и "красивого" кода.. В этом плане ИМХО у ООП больше возможностей.
В качестве примера могу привести часть метода контроллера Yii. Проверка наличия в базе опубликованной записи с нужным id и 404 ошибка (в нужном шаблоне - это может быть и основной шаблон сайта и отдельный шаблон для ошибок... и на белом экране с одной строчкой)
При этом, этот участок кода не изменится, если потребуется добавить ограничения просмотра для различных ролей пользователя/конкретных пользователей, т.к. есть accessRules и accessControlFilter (и ещё классы.. в которых код.. код..)
Про потребление памяти, количество циклов и прочее.. - см про преждевременную оптимизацию.
1. Мерять. Ещё раз мерять.
2. Выявлять узкие места.
3. Оптимизировать их (вплоть до написания отдельных компилируемых модулей/демонов и тд)
Естественно, изначально "кривая" архитектура не позволит оптимизировать отдельный кусок - придётся переписывать основу.. Но ещё хуже, когда кривая архитектура будет приводить к сложности её доработки.. к сложности при внесении изменений.. к дублированию кода.. А в дальнейшем с этим "комком" (лапшой?) разбираться разработчику (ну т.е. Вам)
Конечно, всё что можно сделать при помощи ООП (в смысле, решить задачу из "реального" мира), можно реализовать и без него.. Однако, использование ООП имеет свои плюсы (равно как и минусы). Главное - не переусердствовать...
http://habrahabr.ru/post/172119/
http://habrahabr.ru/post/153225/
http://habrahabr.ru/post/23619/
http://habrahabr.ru/post/169601/
и много других статей в поиске по ООП
Метод ошибки выглядит так:
А вот фатальная ошибка вызывается уже процедурой, ибо в этом случае, может быть ошибка связанная и с подключением класса Error.
Будет еще контроль по группам и связь с автодебагером. Пока что похоже на ООП ради ООП. Могли бы вы хотя бы описать как бы лично реализовали данный участок кода?
Я то сам легко могу править свой код и думаю как раз об общей производительности, а не о производительности разработки, да вот только, не планирую работать всегда над данным проектом сам и хотелось бы логичнее. :( В команде не работал, поэтому, не знаю как писать универсальный код.