ݺߣ

ݺߣShare a Scribd company logo

Стандарты и соглашения всложных ООП-приложениях

•
•
Magecom Ukraine
Magecom Ukraine

Презентация Антона Макареко

1 of 32
Стандарты и соглашения в сложных ООП-приложениях Стандарты оформления кода Шаблоны проектирования в архитектуре проекта Построение иерархии моделей для решения задач бизнес-логики Классификация данных на разных уровнях MVC- приложения
1. Стандарты оформления кода
Зачем нужны стандарты оформления кода Команда говорит на одном языке Важно для больших объемов кода Необходимо для проектов с открытыми исходниками Раскрывает возможности различных IDE
Составляющие стандартов кода Файловая структура и именование файлов Именование классов, методов ипеременных Стиль кода Техническая документация к коду
Сравнительная характеристика стандартов Zend Framework Изначально под php5 Базовые требования phpdoc (структура пакета, лицензия) Не определяет процесс релизов и проекты Изменений немного PEAR Развивался с php4 Больше требований phpdoc (информация о релизах, авторах) Подразумевает процесс разработки проектов PEAR За последнее время сильно мутировал
Принятие стандарта в open-soruce -проекте Всегда: основные положения поформатированию иименованию Иногда: собственная «шапка» илицензия в phpdoc Никогда: личная информация вкомментариях или phpdoc
2. Шаблоны проектирования
Архитектурный шаблон MVC Классифицирует объекты и базовый алгоритм взаимодействия Определяет роль любого объекта всистеме Вводит ограничения наиспользование данных иуправляющие вызовы
Шаблон Registry Назначение: обычно глобальный объект, иногда данные Место в MVC : Controller, View Плюс: легкий доступ отовсюду Минус: связывание кода
Шаблон Observer Назначение: подписчик, обработчик событий Место в MVC : в любой части Плюс: возможность соблюдения независимости модулей системы Минус: сложно отлаживать, иногда конфликты с другими подписчиками
Шаблон Iterator Назначение: модель с набором данных (коллекция) Место в MVC: Model Плюс: возможность отложенной загрузки данных, инкапсуляция получения элементов
Шаблон Adapter Назначение: выравнивание интерфейсов, утилитарная модель Место в MVC: Model Плюс: абстракция ресурсов
Шаблон Strategy Назначение: общий интерфейс для разных алгоритмов поведения Место в MVC: Model Плюс: расширяемость вариантов использования одной сущности Минус: связанность объекта контекста и стратегии
3. Иерархия моделей
Иерархический подход кнабору моделей приложения Управляющие модели Модели знаний Модели сущностей Ресурс-модели, адаптеры
Критерии для создания иерархии моделей Сложность задачи Необходимость реализации различных вариантов использования Требования к расширяемости приложения
Разделение ответственности Определение роли модели Объявление структуры обмениваемых данных Зависимости, ограничения поиспользованию других моделей
Публичный интерфейс Лаконичный Понятный Ожидаемый
4. Данные в MVC- приложении
Обмен данными между архитектурными слоями MVC Представьте себе потоки данных Попробуйте их классифицировать Откуда данные берутся? Где и как их нужно хранить?
Обмен данными между моделями Опять: публичный и приватный интерфейс Константы Хранение, распространение, продажа...
Классификация данных вконтроллере Управляющие данные: параметры маршрутизации Данные: параметры запроса (сессии в том числе)
Классификация данных вмоделях Управляющие данные: сопутствующие объекты «флажки» справочная информация/константы Данные: САБЖ 
Классификация данных во View Управляющие данные: те же сопутствующие объекты те же флажки Данные: все что надо сугубо шаблону в том числе, результаты промежуточных подсчетов
Спасибо! http://mageconf.com/ [email_address]
5. Схема реализации PayPal Express Checkout
Контроллер и модель Checkout Контроллер startAction() returnAction() cancelAction() reviewAction() editAction() saveShippingMethodAction() placeOrderAction() _initToken($setToken = null) Модель start($returnUrl, $cancelUrl) returnFromPaypal($token) prepareOrderReview($token = null) updateShippingMethod($methodCode) placeOrder($token, $shippingMethodCode = null)
Модели Pro и Config Модель Website Payments Pro: общая бизнес-логика вызовов платежной системы Config: справочная информация оконстантах и зависимостях
Модель платежного метода Создание вызовов платежной системы Передача информации по транзакции в объект платежа
Модель API Адаптер непосредственных вызовов шлюза платежной системы Обслуживает всю группу платежных методов Website Payments Pro
The End

More Related Content

Стандарты и соглашения всложных ООП-приложениях

  • 1.
  • 2. Стандарты и соглашения в сложных ООП-приложениях Стандарты оформления кода Шаблоны проектирования в архитектуре проекта Построение иерархии моделей для решения задач бизнес-логики Классификация данных на разных уровнях MVC- приложения
  • 3. 1. Стандарты оформления кода
  • 4. Зачем нужны стандарты оформления кода Команда говорит на одном языке Важно для больших объемов кода Необходимо для проектов с открытыми исходниками Раскрывает возможности различных IDE
  • 5. Составляющие стандартов кода Файловая структура и именование файлов Именование классов, методов ипеременных Стиль кода Техническая документация к коду
  • 6. Сравнительная характеристика стандартов Zend Framework Изначально под php5 Базовые требования phpdoc (структура пакета, лицензия) Не определяет процесс релизов и проекты Изменений немного PEAR Развивался с php4 Больше требований phpdoc (информация о релизах, авторах) Подразумевает процесс разработки проектов PEAR За последнее время сильно мутировал
  • 7. Принятие стандарта в open-soruce -проекте Всегда: основные положения поформатированию иименованию Иногда: собственная «шапка» илицензия в phpdoc Никогда: личная информация вкомментариях или phpdoc
  • 8. 2. Шаблоны проектирования
  • 9. Архитектурный шаблон MVC Классифицирует объекты и базовый алгоритм взаимодействия Определяет роль любого объекта всистеме Вводит ограничения наиспользование данных иуправляющие вызовы
  • 10. Шаблон Registry Назначение: обычно глобальный объект, иногда данные Место в MVC : Controller, View Плюс: легкий доступ отовсюду Минус: связывание кода
  • 11. Шаблон Observer Назначение: подписчик, обработчик событий Место в MVC : в любой части Плюс: возможность соблюдения независимости модулей системы Минус: сложно отлаживать, иногда конфликты с другими подписчиками
  • 12. Шаблон Iterator Назначение: модель с набором данных (коллекция) Место в MVC: Model Плюс: возможность отложенной загрузки данных, инкапсуляция получения элементов
  • 13. Шаблон Adapter Назначение: выравнивание интерфейсов, утилитарная модель Место в MVC: Model Плюс: абстракция ресурсов
  • 14. Шаблон Strategy Назначение: общий интерфейс для разных алгоритмов поведения Место в MVC: Model Плюс: расширяемость вариантов использования одной сущности Минус: связанность объекта контекста и стратегии
  • 16. Иерархический подход кнабору моделей приложения Управляющие модели Модели знаний Модели сущностей Ресурс-модели, адаптеры
  • 17. Критерии для создания иерархии моделей Сложность задачи Необходимость реализации различных вариантов использования Требования к расширяемости приложения
  • 18. Разделение ответственности Определение роли модели Объявление структуры обмениваемых данных Зависимости, ограничения поиспользованию других моделей
  • 19. Публичный интерфейс Лаконичный Понятный Ожидаемый
  • 20. 4. Данные в MVC- приложении
  • 21. Обмен данными между архитектурными слоями MVC Представьте себе потоки данных Попробуйте их классифицировать Откуда данные берутся? Где и как их нужно хранить?
  • 22. Обмен данными между моделями Опять: публичный и приватный интерфейс Константы Хранение, распространение, продажа...
  • 23. Классификация данных вконтроллере Управляющие данные: параметры маршрутизации Данные: параметры запроса (сессии в том числе)
  • 24. Классификация данных вмоделях Управляющие данные: сопутствующие объекты «флажки» справочная информация/константы Данные: САБЖ 
  • 25. Классификация данных во View Управляющие данные: те же сопутствующие объекты те же флажки Данные: все что надо сугубо шаблону в том числе, результаты промежуточных подсчетов
  • 27. 5. Схема реализации PayPal Express Checkout
  • 28. Контроллер и модель Checkout Контроллер startAction() returnAction() cancelAction() reviewAction() editAction() saveShippingMethodAction() placeOrderAction() _initToken($setToken = null) Модель start($returnUrl, $cancelUrl) returnFromPaypal($token) prepareOrderReview($token = null) updateShippingMethod($methodCode) placeOrder($token, $shippingMethodCode = null)
  • 29. Модели Pro и Config Модель Website Payments Pro: общая бизнес-логика вызовов платежной системы Config: справочная информация оконстантах и зависимостях
  • 30. Модель платежного метода Создание вызовов платежной системы Передача информации по транзакции в объект платежа
  • 31. Модель API Адаптер непосредственных вызовов шлюза платежной системы Обслуживает всю группу платежных методов Website Payments Pro