Допомога студенту. Архітектура програми

Доброго часу доби, форумчани.
Дали завдання мені, треба придумати архітектуру проекту,
так, щоб логічно працювало. В надії, що тут є люди, які розбираються з архітектурою ПЗ і готові помогти.
Ось текст завдання
pastebin.com/xjU23vxr
Програма має розроблятись у Visual Studio 2013
на мові програмування с++.
Я думав можливо зробити клас сесію, в якій буде вказівник стан перебування користувача(паттерн стан) і вказівник на Ebay(буде представляти бекенд). Користувач буде вводити команди якісь команди. Їх буде парсити якісь один функція і буде видавати об’єкт команда(вона інкапсуює характеристики команди). Який буде хендлетись в обробітнику подій сесії. Там з характеристик команди буде вибиратись чи має право команда передаватись до бекенду(Ebay). В самому бекенді команда буде хендлитись теж і перевіряти валідність команди, на рахунок даних які є. Тут би якось зробити оброблення команди. Може chain of responsibility. Зробити декілька хендлерів котрі по черзі будуть обробляти команду.
Це взагалі то завдання на паттерни. Я так орієнтуюсь в них, а тут практичне завдання в якому треба декілька скомбінувати, і задумався.
Я чув, що для чогось подібного юзається MVC. він тут підходить. Просто я ше його не розгялядав. Варто це робити? Якщо він підходить то, як саме повинен виглядати.
Насправді можу хоч зараз почати писати. В скінченний автомат зажену роботу з юзером. А даватиму йому команди просто вибором циферок і буду їх хендлети. Але то не гарно. І там потім якісь кастилі на пишу. І буде огедний код. Тому і питаюсь людей з досвідом. Може шось порадять.
п.с. Прочитав книгу Head First Design Patterns by Eric T Freeman

👍ПодобаєтьсяСподобалось0
До обраногоВ обраному0
LinkedIn
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Напишите в личку свой email, завтра сброшу диаграммы и описание, точнее уже сегодня.

Шось не дуже вдало завдання написане. Навіть порахувати не вміють:

Програма має складатися з трьох логічних частин: backend,historyLoader, userInterface, reports

Я не дуже зрозумів, до чого тут іБей, вам потрібно свій бекенд написати. Інше питання, як фронтенд (userInterface) має працювати з бекендом. Логічно було б через сокети.. Про це нічого у завданні нема.

Взагалі, пошукайте бібліотеки для складових частин — якийсь серверний фреймворк та бібліотека для серіалізації об’єктів у якийсь формат у файли для бекенду, обробка командної строки для userInterface. Від інтерфейсів цих бібліотек далі й відштовхуйтесь.

дякую, вам, за відповідь.
Так, там у завданні не точність, самі сміялись з того:)
Ви трохи переоцінили складність завдання. Воно має виконуватись на локальній машині. І не використовувати мережу(ми ще цього просто не вчили)

Взагалі, пошукайте бібліотеки для складових частин — якийсь серверний фреймворк та бібліотека для серіалізації об’єктів у якийсь формат у файли для бекенду, обробка командної строки для userInterface. Від інтерфейсів цих бібліотек далі й відштовхуйтесь.
Ну це навчальний проект. Я думаю, тут малось на увазі, придумування своїх велосипедів. Тому обробку командної стрічки для userInterface. Серіалізація об’єктів і потрібно самому написати. А оскільки, це треба самому писати, то треба і гуд архітектуру придумати. Тут то я і завис

Я б оцінив здатність використовувати готові бібліотеки вище, аніж писати свої, особливо як для початківців. Спитайте вчителя, чи він не проти. Чи якнайменше, хоч подивіться на код готових рішень, перед тим як писати своє, це дуже гарний спосіб вчитися програмуванню, як на мене.

Ок, тоді про паттерни. Окрім очевидних паттернів, які ви вже назвали, якто Command, State, чи Front Controller, є деякі не такі очевидні, але дуже корісні для гарної архітектури.

1) Inversion of Control, або Dependency Injection martinfowler.com/.../injection.html Для конфігурації та зв’язку між окремими модулями. Можна використовувати навіть без спеціалізованих бібліотек.

2) Еvent bus, або event channel — Команда публікує івент, об’єкти аукціонів слухають, та публікуюсть свої івенти, які слухають юзери, та змінюють свій стан..

3) Immutable — для shared state, конфігурацій

4) Decorator (усілякі інтерцептори, наприклад для контролю доступу, логгінгу)

5) Visitor, Composite для серіалізації графів об’єктів

дякую. Тут мені треба буде розбиратись, як саме правильно використовувати ці паттерни і як зв’язати їх з іншими. Не підкажете, де б було можна це побачити?

На жаль на С++ не зможу підказати, давно вже нічого не писав на ньому, доведеться самому гуглити, то вже краще ви самі.

як на мене просто пробуй розбити це на якісь окремі функціональні модулі...
в паттерни поки в тебе нема загальної картини, сильно не вдавайся...
потім зможеш оптимізувати....
бо все, що я побачив — це купа тексту і більше нічого...

Тут то я з вами погоджуюсь. Купа тексту.
Архітектор з мене такий собі.
Я зараз, на стадії усвідомлене незнання:)
Я тому і написав сюда, бо чую , що треба буде переписувати код по 3 раза.
Тому і думав. Що люди порадять архітектуру на такий проект.А якби ще я зрозумів чому так, то б ціни мені не було.
На мою субєктивну думку, часто виникають такі такси, там інтернет магазини всякі. Можливо люди порадять інформацію на цю тему.
Beaver Green написав архітектуру, але для недосвідченого мене це важкувато осягнути, як воно все там працює.

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

На любом из этапов иногда приходит понимание того, что где-то подобные проблемы встречала, и начинаешь шерстить различные ресурсы, чтоб узнать, как подобную проблему решил кто-то другой, не для того, чтоб применить решение у себя, а для того, чтоб иметь как можно больше выбора вариантов решения. Если их не вижу, то особо по этому поводу не сушу себе голову, пытаясь адаптировать решения чуть похожих проблем под свои нужды. Я считаю, что от опыта никуда не уйдешь и со временем, если работа нравиться, в решениях начнут появлятся больше оттенков. Опыт уже будет подсказывать в каком конкретном случае какой architectural pattern больше подходит и на каком этапе (но это мне кажется уже больше зона ответственности архитектора), на каком этапе реализации решения какой design pattern подходит лучше (это мне кажется зона ответственности разработчика), ну и какие из них когда не стоит использовать, и по каким причинам. На решение любой проблемы конечно влияют как требования, так и сроки, но я бы очень хорошо подумала, стоит ли в твоем конкретном случае этим заморачиваться.

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

Желаю тебе успехов, Юра.

Могу предложить топ-левел архитектуру, которую применяю для энтерпрайз приложений.
Часть первая — доменная модель. Здесь все объекты предметной области и их свойства:

Містить класи для представлення товарів, користувачів, ставок (bids) на аукціоні“
Користувач має інформацію про свій тип, логін, пароль, ПІБ, країну, номер кредитної картки, історію покупок та ставок, рейтинг продавця (0-100), відмітку перевіреного продавця (встановлюється адміністратором аукціону), рейтинг покупця (0-100)
Товар має назву, опис, кількість одиниць (наприклад, 5 пар взуття, як одна позиція в аукціоні), ціна, тип продажу (аукціон, фіксована ціна), термін аукціону (1,3,5 днів), мінімальне зростання ставки, доставку в обмежену кількість країн (або у всі можливі), обмеження на рейтинг покупця.
Ставка має інформацію про того хто її зробив, іі значення і час.
Вторая часть — сохранение и загрузка этих объектов (из базы или файла). Тут можно использовать шаблон репозиторий и ORM.
Третья часть — бизнесс процессоры. Это реализация бизнес — правил, как проверять объекты, как считать цену и т.д. Можно применить шаблон конвейер (он же пайплайн или форкфлов): доменная модель заходит на “конвейер” а классы — операции ее по очереди обрабатывают.
Четвертая часть — юзер интерфейс. В случае консоли MVC смысла не имеет (нету представления как такового). Лучше использовать шаблон команд и контроллер для их обработки. Контроллер реализует конечный автомат.

дякую, написано напевно шикарно, але я не шарю деяких аспектів.
Ну точніше багатьох :)
Ну я б не сказав шо я непутящи. Про багато речай вами згаданих імплементив, але поодинці. І не бачу, як вони взаємодіять. Покажете світло в кінці тунелю?
ви не знаєте десь лайт версії цієї архітектури, щоб її можна було пощупати.
Мені б приклад сеансу роботи, щоб зрозуміти хто кого запускає і юзає.
прочитаєте, те що я написав знизу, якщо звісно ви матимете час.
____________________________________________________________

Часть первая — доменная модель
Це так ж сама модель що і в MVC?
Третья часть — бизнесс процессоры. Это реализация бизнес — правил, как проверять объекты, как считать цену и т.д. Можно применить шаблон конвейер (он же пайплайн или форкфлов): доменная модель заходит на «конвейер» а классы — операции ее по очереди обрабатывают.
це Chain of Responsibility? А як саме організовані класи які хендлять ціну, ставки. Я в них передаю команду?
Ну тут багато питань. Так я бачу вашу програму.
Заходить юзер
це єкийсь об’єкт сесії
в нього є вказівник на контролер, далі сесія має мати доступ до моделей якось.
я методі прінт викликаю в контролера. так я він описує стан.
в контролерає хендлер команд.
І юзер в тому консольнці вводить Login:NoName pass: qwerty. За допомогою якось функції генериться команда(LoginCommand). Яка йде до контролера. Він рішає чи допустима команда(не на приклад show items). Далі контролер має звернутись до моделі юзера і спитати чи такий зареєстрований. Як це виглядає? user.checkUser(LoginCommand) і він каже ок че ни ок. Далі сесіє сетає собі залогінений юзер. І міняє стан контролера. Малює нове в консольці. Стартова сторінка користувача. Там є командний радок. він пише шось типу (show items) команда(ItemsShow) яка йде до хендлера в контролері який каже така команда дозволена цьому юзерові. Йде до моделі товару і каже дай мені всі товари. Змінює контролер(стан) на стан показу товарів. і виводить то шо дала йому модель товару. А коли команда робити ставку вона буде оброблятись тими хендлерами в частині 3 у вас згадані. Але як ті хендлери будуть знати шо товар на акціоні чи на ціні на продаж.
Шось мені здаєтьяс це зовсім не то що ви написали.
Дякую за прочитання)

гийс, я тут погуглив. По ходу тут найкраще MVC заходить.
так/ні?
в мене виникло питання як у ньому в’юшки міняти?

через controller задаешь параметры view и оно должно обновиться

ну повинні бути багато в’юшок, на приклад, для відображення товару, історії, сторінки юзера.
Наскільки я бачив діаграму класів, то контролер має вказівник на в’ю і в’ю має вказівник на контролер. В мене має бути основний контролер який буде займатись обробленням команд. Основний котнтролер по свої суті реалізовує паттерн State. Тобто матиме в собі вказівники на різні контролери. Я бачив таку архітектуру і я не розумію як мають мінятись в’юшки. От ми засетали всі класи. Обробкою подій займається той основний контролер? І він просить контролер, який представляє стан, намалювати відповідну йому в’юшку. А та в’юшка потім буде слідкувати за змінами в моделі чи як. Ну я хочу перейти з екрану одного юзера на екран іншого. В нас контролер не помінявся. То як мені обновити в’юшку.

Представление не должно отслеживать изменения модели. Советую Вам про/пере-читать про MVC с примерами на Вашем языке.

Ой я тут помилився. Я знаю, що ви мали на увазі. В’юшка реєструється в моделі на інформацію про зміни(Observer). Коли вони відбуваються зміни, то нотифікайшен до неї приходить

Контроллер регистрируется на изменения, а потом решает нужно ли менять параметры у представления.

Давайте сделаем все ему курсовой.

це не курсува
таск на 25 балів зі 100
Очікувана мною відповідь приблизно така
о я така шось кліпав, тут MVC заходить найкраще
ось силка на пояснення(це так гіпотетично)
Максимум це коли людина ше напише чому цей солушен вибрати треба і накине бігле представлення, я ж не кажу мені робити.
Я сам хочу зробити цей таск!

таск на 25 балів зі 100
Як я люблю нашу пародію на болонську систему:)

Я сам такого не робив, але друзі кажуть що замість MVC реальні революціонери юзають MVVM. Головне не напхати зайвих патернів.

а це важко початківцю)

дякую, почитаю про

MVVM

Юра, не стесняйтесь говорить о том, какую архитектуру видите Вы, потому как из этого хотя бы будет понятно, что Вы сами прочли ТЗ.

дякую
я доповнив запитання

вибачте, що таке

ТЗ

Помочь или сделать за вас? Стек технологий хоть какой? потому что архитектура хочешь или нет, а привязывается.

зараз зміню текст завдання, критика умісна
Звісно не зробити програму, це безумство таке просити)
Я звертався тут до досвідчених програмістів. Я думаю вони стикались з чимось подібним на вигляд. Порадять можливо набір паттернів проектування,якими вони це вирішували.

Без проблем, вечером гляну. Если найду в чем набросать диаграмму классов, то тряхну стариной, когда-то лет 6 назад делал такие типовые курсовые на С++ за 8-10 часов.

я буду дуже вдячний.
На мою думку, взагалі придумування архітектури є найважливішим у розробці програмного забезпечення. Програмісти якісніше працюють, тести класно проходять.
До речі не підкажете де можна про це прочитати, я маю ,на увазі , придумування архітектур програм, з поясненнями, чому саме такий солушен вибирають.

ну якщо чесно, то багато де буває наступна ситуація — masterden.livejournal.com/65760.html, а потім фіксять баги)
А взагалі можна (і треба) глянути dou.ua/...ums/topic/5369

Почитать:
www.ozon.ru/...ail/id/1616782 про Enterprise
habrahabr.ru/post/189094 и сама книга (не совсем об архитектуре, но отучает от плохих привычек).
Две великолепные книги по требованиям и проектированию:
www.ozon.ru/...ail/id/8747662
www.ozon.ru/...il/id/20095359
С пояснениями сложнее, вкратце перенос проблем предметной области в код. Чем лучше программист врубается в происходящее, тем лучше. Не будет отмашек друг на друга, десятков уровней ненужной абстракции и такого кода: www.govnokod.ru/17253

На мою думку, взагалі придумування архітектури є найважливішим у розробці програмного забезпечення.
Это годится для маленьких проектов write-only, сам так думал в универе. Простейшая аналогия — густые джунгли vs сады бонсай, которые подстригаются десятками лет. Также и архитектура, наиболее удачная вырастает постепенно и в ней нет ничего лишнего. Эволюционное проектирование. Опять же если система не на выброс, а переживет много релизов и поколений разработчиков.

P.S. имейте ввиду, что я еще не senior, мои советы не эталонны, и мне самому еще нужно расти.

дякую за інформацію. Обов’язково прочитаю ці книги.(зараз ше 4 перед ними є :) )
Завжди приємно говорити з більш досвідченішою людиною.

Это годится для маленьких проектов write-only, сам так думал в универе. Простейшая аналогия — густые джунгли vs сады бонсай, которые подстригаются десятками лет. Также и архитектура, наиболее удачная вырастает постепенно и в ней нет ничего лишнего. Эволюционное проектирование. Опять же если система не на выброс, а переживет много релизов и поколений разработчиков.

И получается полная индусятина. Как раз таки архитектор первым делом кроме моделирования предментной области — составляет ( а в особо сложных случаях даже моделирует ) reference architecture и код стайл которых должны придерживаться все члены команды. Таким образом архитектура остается прежней, ориентироваться и менять ее легко. И прежде всего с ростом требований меняется приложении будет доменная модель.
Могу расписать подробнее, завтра.

Я не спорю, потому что

маленьких проектов write-only
===
полная индусятина.

Підписатись на коментарі