Я тут намедне, сам не зная для чего, сочинил для своего фреймворка Active Record. Ну, а чтобы не зря, попробую извлечь отсюда пользу.

Итак, сейчас будет атракцион невиданной щедрости. Чайник в ООП научит вас, прожженых оопэшников, настоящему ООП, а не какому то там, прости Господи, транзакшен скрипту, который они пытаются выдать за чистую монету.

Шучу. Просто хочу разобраться на практике, как правильно проектировать приложение, чтобы оно реально отвечало требованиям Объектного программирования, а не было бы обычной процедуркой на объектах.

Сначала нужно разобраться, что есть ООП. Я еще два года назад пытался разобраться, что это. Но толком не смог, так как нет в природе однозначного его толкования.

Однако можно просто пойти от обратного. Посмотреть, что есть процедурное программирование. Это вовсе не отсутствие классов и объектов, как многие думают. Если функционал разбит и инкапсулирован по объектам, это еще не всё. Это просто процедуры. Если они, процедуры, вызываются по очереди, линейно, то это и есть процедурное программирование, какими бы паттернами их не колбасили. Особенно весело смотрится в этом свете контейнер зависимостей. Это ни что иное, как способ глобального доступа к процедуре в любом месте программы. Настоящее ООП должно быть параллельным.

Ну да оставим лирику. Нужно только еще отметить, что чистого ООП в природе не бывает. Я имею ввиду PHP конечно, а не объектные языки типа смалтолк и иже с ним.

Так вот. Сейчас я, на глазах у всех, попробую написать маленький интернет-магазинчик, стараясь придерживаться "чистого ООП". А заодно проверю в боевых условиях свою поделку. А так же попробую проанализировать пользу/вред этой методологии.

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

_____________
Если вам недостаточно собственных заблуждений, можно расширить их мнениями экспертов.

Нужно уважать мнение оппонета. Ведь заблуждаться - его святое право.

Настаивал, настаиваю и буду настаивать на своем. На кедровых орешках.

twin

Первое, что нужно сделать, чтобы спроектировать ООП приложение, это забыть про базу данных. Напрочь. Нет её, не существует. Она понадобится только в самом конце, когда проект будет готов.

Соответственно нужно забыть как страшный сон любые упоминания о CRUD запросах.

Вместо таблиц СУБД нужно пользоваться классами моделей. Для того и изобретались такие паттерны, как ActiveRecord или DataMaper.

А чтобы было совсем камильфо, нужно для начала прикинуть, какие будут использованы сущности, и какие между ними возникнут взаимоотношения.

Но сначалча нужно обозначить предметную область в виде технического задания. Я не буду углубляться в дебри ubiquitous language, сделаю морду по проще. Обозначу это списком хотелок, на основе которого и буду пытаться нарисовать диаграмму взаимоотношений.

любопытно.

_____________
HTML, CSS (Bootstrap), JS(JQuery, ExtJS), PHP, MySQL, MSSql, Posgres, (TSql, BI OLAP, MDX), Mongo, Git, SVN, CodeIgnater, Symfony, Yii 2, JiRA, Redmine, Bitbucket, Composer, Rabbit MQ, Amazon (SQS, S3, Transcribe), Docker

Достала попкорн.

Чего хочет заказчик (это реальный заказ кстати )

Есть небольшой специфический ассортимент товаров. Нужно сделать:

1. Каталог (витрину), он же прайс
2. Склад
3. Корзину
4. Кассу (систему оплаты)
5. Отдел заказов
6. Систему учета движения активов и аналитики

Каталог не должен зависеть от наличия товаров на складе.
Склад должен взаимодействовать с корзиной и кассой (автоматический учет наличия товаров)
Корзина должна решать, в зависимости от наличия товара, куда отправить пользователя. В кассу или отдел заказов.

Это клиентская сторона. Со стороны администрирования должна быть возможность редактирования каталога и склада. В отделе заказов должна работать система выполнения заказа или его отмены. Учет движения активов должен производиться автоматически.

Это в общих чертах. На самом деле, если вдаваться в подробности, всплывает куча деталей. Об этом дальше.


_____________
Если вам недостаточно собственных заблуждений, можно расширить их мнениями экспертов.

Нужно уважать мнение оппонета. Ведь заблуждаться - его святое право.

Настаивал, настаиваю и буду настаивать на своем. На кедровых орешках.

уже очень интересно.

Мне интересно в плане качества кода готового результата (в плане кода).

_____________
Люди, имеющие низкий уровень квалификации, делают ошибочные выводы, принимают неудачные решения и при этом неспособны осознавать свои ошибки в силу низкого уровня своей квалификации

chee
всем интересно, но и момент проектирование тоже очень интересен.

_____________
HTML, CSS (Bootstrap), JS(JQuery, ExtJS), PHP, MySQL, MSSql, Posgres, (TSql, BI OLAP, MDX), Mongo, Git, SVN, CodeIgnater, Symfony, Yii 2, JiRA, Redmine, Bitbucket, Composer, Rabbit MQ, Amazon (SQS, S3, Transcribe), Docker

Продолжим. На основе полученной информации можно уже набросать заготовку предметной области (домена). Фактически это пункты хотелок, постепенно обретающие более конкретные, осязаемые формы - сущности. Чтобы это лучше себе представлять, лучше их визуализировать - нарисовать на бумаге. Итак, получаем отдельно взятые субстанции, соответствующие пунктам ТЗ, плюс очевидную на текущий момент, и самую главную - товар.

_____________
Если вам недостаточно собственных заблуждений, можно расширить их мнениями экспертов.

Нужно уважать мнение оппонета. Ведь заблуждаться - его святое право.

Настаивал, настаиваю и буду настаивать на своем. На кедровых орешках.

Пока все просто - это делает (как минимум в уме) любой разработчик, даже если начинает проектирование с базы данных. Собственно осталось разобраться, из чего состоят эти квадратики, и вот уже готова голая структура таблиц. Но - тссс! Забыли про базы данных. Что это такое? Не видел.

Однако тут зачастую возникает ошибка. Разработчик полагается на заказчика, а часто прямо просит его конкретизировать данные. Какие, мол, интересуют параметры товара? Что должно быть представлено на витрине? Какие характеристики должны учитываться при складском учете?

Вся беда в том, что заказчику это настолько очевидно, что он (не со зла) может опустить часть важных параметров, как сами сабой разумеющиеся. Однако ни разработчик, ни тем более компьютер, не могут предвидеть возможные ситуации, где проявятся эти недомолвки.

Так вот, на этом этапе лучше всего вспомнить детство, и начать игру в "магазин". Разработчик чур покупатель, заказчик - соответственно продавец. В идеале должно быть не два человека, а чем больше, тем лучше. Несколько покупателей, и несколько сотудников магазина.

Три-чеыре: начали.

_____________
Если вам недостаточно собственных заблуждений, можно расширить их мнениями экспертов.

Нужно уважать мнение оппонета. Ведь заблуждаться - его святое право.

Настаивал, настаиваю и буду настаивать на своем. На кедровых орешках.

- Здравствуйте. Что вы тут продаете?
- Тандыры.

- О как. А что это такое?

- Такая печка для шашлыка
- Печка? Большая наверно?
- Нет, не очень, на дачу самый раз

- Ух ты! Наверное тяжелая?
- В двоем поднять можно

- И как оно работает?
- Надеваете мясо на шампур, и суете туда.
- А где взять шампур?
- Они идут в комплекте

- И сколько вот это чудо стоит?
- ..... рублей


И так далее. Чем больше и изощреннее будут вопросы, тем проще проектирование и качественнее продукт.

А пока осталось снабдить сие идентификатором, и модель товара в первом приближении готова.

_____________
Если вам недостаточно собственных заблуждений, можно расширить их мнениями экспертов.

Нужно уважать мнение оппонета. Ведь заблуждаться - его святое право.

Настаивал, настаиваю и буду настаивать на своем. На кедровых орешках.

Прикольно тут то, что сей квадратик без пояснений понятен как разработчику, так и заказчику. Даже если он не знает английского языка - полно переводчиков. Суть все равно поятна: наименвание, но и в Африке наименование, а прайс так вообще святое дело. Это и есть основа ubiquitous language (общий язык), чтобы проект был понятен обоим сторонам без дополнительных пояснений.

_____________
Если вам недостаточно собственных заблуждений, можно расширить их мнениями экспертов.

Нужно уважать мнение оппонета. Ведь заблуждаться - его святое право.

Настаивал, настаиваю и буду настаивать на своем. На кедровых орешках.

Однако, здравствуйте продолжим.

- А что так дорого?
- Вам повезло! У нас сейчас проходит акция. Покупаешь два тандыра по цене трех, и получаешь третий бесплатно!


В итоге всех этих игрищ получим уже более менее конкретный набор сущностей:

_____________
Если вам недостаточно собственных заблуждений, можно расширить их мнениями экспертов.

Нужно уважать мнение оппонета. Ведь заблуждаться - его святое право.

Настаивал, настаиваю и буду настаивать на своем. На кедровых орешках.

Закономерно должно возникнуть два вопроса.
1. Куда девался склад?
2. Как эти сущности будут взаимодействовать между собой?

Сначала нужно усвоить, что называется сущностью в ООП. Это объект, у которого есть идентификатор, и ктороый хранит свое состояние.

Ответ на первый вопрос может сначала шокировать. Склада, как сущности не бывает в природе. Нет, все конечно видели огромные здания с надписью "склад". Но это здание. Стены, пол, потолок - все можно потрогать. А склад потрогать нельзя. Склад - понятие абстрактное. Это просто упорядоченная куча чего-либо. Говорят как - "устроили тут склад мертвых негров!"

Так вот, можно конечно и абстрактной сущности присвоить идентификатор, но будет это уже слишком. Так что склад, это ни что иное, как сервис. Ровно как и витрина, касса (биллинг) и иже с ними.

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

Первый этап - из чего состоит
Второй - как это взаимодействует
И третий - как оно вообще работает, шайтан-машина.

_____________
Если вам недостаточно собственных заблуждений, можно расширить их мнениями экспертов.

Нужно уважать мнение оппонета. Ведь заблуждаться - его святое право.

Настаивал, настаиваю и буду настаивать на своем. На кедровых орешках.