• Save
Стандарты и соглашения в сложных ООП-приложениях
Upcoming SlideShare
Loading in...5
×
 

Like this? Share it with your network

Share

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

on

  • 2,784 views

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

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

Statistics

Views

Total Views
2,784
Views on SlideShare
1,276
Embed Views
1,508

Actions

Likes
2
Downloads
0
Comments
0

10 Embeds 1,508

http://mageconf.com 1341
http://mageconf.local 58
http://dev.mageconf.com 37
http://mageconf 31
http://blog.quartsoft.com.ua 30
http://quartsoft.blogspot.com 5
http://www.slideshare.net 3
http://127.0.0.1 1
http://translate.googleusercontent.com 1
http://hghltd.yandex.net 1
More...

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

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

  • 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
    • Плюс: расширяемость вариантов использования одной сущности
    • Минус: связанность объекта контекста и стратегии
  • 15. 3. Иерархия моделей
  • 16. Иерархический подход к набору моделей приложения
    • Управляющие модели
      • Модели знаний
      • Модели сущностей
        • Ресурс-модели, адаптеры
  • 17. Критерии для создания иерархии моделей
    • Сложность задачи
    • Необходимость реализации различных вариантов использования
    • Требования к расширяемости приложения
  • 18. Разделение ответственности
    • Определение роли модели
    • Объявление структуры обмениваемых данных
    • Зависимости, ограничения по использованию других моделей
  • 19. Публичный интерфейс
    • Лаконичный
    • Понятный
    • Ожидаемый
  • 20. 4. Данные в MVC- приложении
  • 21. Обмен данными между архитектурными слоями MVC
    • Представьте себе потоки данных
    • Попробуйте их классифицировать
    • Откуда данные берутся?
    • Где и как их нужно хранить?
  • 22. Обмен данными между моделями
    • Опять: публичный и приватный интерфейс
    • Константы
    • Хранение, распространение, продажа...
  • 23. Классификация данных в контроллере
    • Управляющие данные: параметры маршрутизации
    • Данные: параметры запроса (сессии в том числе)
  • 24. Классификация данных в моделях
    • Управляющие данные:
      • сопутствующие объекты
      • «флажки»
      • справочная информация/константы
    • Данные: САБЖ 
  • 25. Классификация данных во  View
    • Управляющие данные:
      • те же сопутствующие объекты
      • те же флажки
    • Данные:
      • все что надо сугубо шаблону
      • в том числе, результаты промежуточных подсчетов
  • 26. Спасибо!
    • http://mageconf.com/
    • [email_address]
  • 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
  • 32. The End