Не в качестве рекламы, посоветую посмотреть на Дзен-мани. Я долгое время перебирал способы наиболее простого мониторинга семейного бюджета, перепробовал разные варианты, и самым удобным оказалось именно дзен-мани.
В чем преимущества? Они умеют подключаться к апи банков и синхронизировать расходы и доходы автоматически. Это оказалось настолько удобно, что я раз в день перед сном просто проверяю правильные ли категории были заасайнены на расходы
В довесок к хорошей статье скажу что и события не обязательны — решать обработку сообщений можно и на уровне данных, имею ввиду отдельную джобу, которая выгребает заказы, которым еще не было отправлено в сообщение, помещает из в очередь, а оттуда они уже рассылаются. В таком подходе есть место для маневров масштабируемости и полной разгрузки основного сервиса с которым взаимодействуют пользователи
еще важный момент это понимать какой компонент разрабатывается — если это каркас/фреймверк, то скорее всего понадобятся хорошо продуманные абстракции, в случае же разработки доменной логики или каких-то инфраструктурных вещей — нужно делать максимально понятно и строго
Мое мнение как разработчика, достаточно долго пишущего на WPF, что ViewModel ни что иное как абстракция View (на самом деле из названия понтяно)). Суть вьюмодели в том чтобы в абстрактном виде задавать то, как должна выглядить вьюха. Так например в wpf есть классы, которые абстрактно описывают коллекции (например ListCollectionView, ObservableCollection). Мы и пишем вьюмодель ориентруясь на асбтракцию представления. А то КАК будет отображена это коллекция (ListView или ListBox или TreeView) решается на уровне представления. Это я все к тому что, по хорошему, не место значений размеров окна во вью модели, это исключительно ответсвенность вьюхи, вьюмодель — абстракция
Мне кажется, или это решение очевидное в силу того что это ASP.NET MVC? Вроде же как в конвейере можно переопределить практически любую часть. (Я к тому что такое решение самое «природное»)
Да, ставить БД в основу основ при проектировании системы, с одной стороны — не хорошо. Но порой в базу данных и закладывается вся предметная область, так как это, скорее всего, это удобно.
С другой стороны правильнее проектировать систему исходя из подхода который был выбран. Выбираем ООП — мыслим в терминах объектов и классов, а дальше уже думаем где у нас будут данные храниться, и главное — как храниться.
ну как это не связано… разве не добавляет удобства повторно использовать код ОО-принцип? Разве не природно отнаследоваться от какого-то функционального класса, переопределить нужные методы, добавить что то свое и получить новый класс, часть поведения которого унаследовано (повторно используется) от написанного ранее класса?
Цитата:
Согласен, в каждом руководстве по ООП или С++ написана эта глупость.
Обоснуйте почему это глупость? Разве не легче создавать сущности из таблиц бд (может не самый лучший пример, но все же) и потом оперировать ими как реальными объектами, строить взаимодействия и т.п. чем писать какой то процедурный код, где все будет не так природно?
мне кажется вся суть не в красоте и правильности кода с точки зрения какой-то концепции…
Одно из основных преимуществ ООП — повторное использование кода, которое не составляет особого труда. Зная и используя этот гуманитарный подход получается достаточно легко писать функциональные библиотеки, которые с легкостью можно использовать где угодно. А ООП тут при том что мы оперируем объектами, что является достаточно природным для нашего мировозрения
Не в качестве рекламы, посоветую посмотреть на Дзен-мани. Я долгое время перебирал способы наиболее простого мониторинга семейного бюджета, перепробовал разные варианты, и самым удобным оказалось именно дзен-мани.
В чем преимущества? Они умеют подключаться к апи банков и синхронизировать расходы и доходы автоматически. Это оказалось настолько удобно, что я раз в день перед сном просто проверяю правильные ли категории были заасайнены на расходы
О чем собственно статья?
"предпочитайте композицию наследованию" :)
С другой стороны правильнее проектировать систему исходя из подхода который был выбран. Выбираем ООП — мыслим в терминах объектов и классов, а дальше уже думаем где у нас будут данные храниться, и главное — как храниться.
Посыл хороший, согласен, код, конечно не так хорош, и архитектура тоже. Но хабр немного не то место где нужно такие посылы реализовывать.
А то что вы пишете такой код в таком возрасте, это похвально. Вы же это хотели услышать, не так ли?
Цитата:
Согласен, в каждом руководстве по ООП или С++ написана эта глупость.
Обоснуйте почему это глупость? Разве не легче создавать сущности из таблиц бд (может не самый лучший пример, но все же) и потом оперировать ими как реальными объектами, строить взаимодействия и т.п. чем писать какой то процедурный код, где все будет не так природно?
Одно из основных преимуществ ООП — повторное использование кода, которое не составляет особого труда. Зная и используя этот гуманитарный подход получается достаточно легко писать функциональные библиотеки, которые с легкостью можно использовать где угодно. А ООП тут при том что мы оперируем объектами, что является достаточно природным для нашего мировозрения