Как приблизиться к проблемам проектирования как “дизайн торговый автомат”

Я полагаю, вы уже видели эту ссылку

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

Затем, в зависимости от того, для какого типа проекта class он предназначен, подумайте о нефункциональных требованиях. Что самое важное: скорость, надежность, простота обслуживания, адаптируемость к новым ситуациям, безопасность, ...? Есть и другие возможности. Это не бинарные ответы, ответы «да / нет», больше думайте о диапазонах и минимальных стандартах по сравнению с оптимальными целями. Обратите внимание, «оптимальный» зависит от точки зрения заинтересованной стороны. Простота использования и безопасность часто противоречат друг другу, поэтому вам нужно выяснить, что важнее.

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

Затем вы можете приступить к проектированию машины.

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

Эти мысли могут помочь:

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

Решите, насколько хорошо он должен выглядеть.

Сколько времени займет он должен работать (срок службы).

Как часто его нужно пополнять?

начнем с определения «машины поставщика»:

Машина продавца - это машина, которая .....

presto! вот ваши требования.

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

1. Начните с основных действий (вложение денег, нажатие на выбор, получение напитка)
2. Продолжайте разбивать каждое действие на более мелкие действия и ответы, пока оно не станет почти тривиальным. Таким образом, чтобы внести деньги, вы должны знать, сколько было вложено, сколько было вложено, сколько отображалось и т. Д.
3. Подумайте о любых сценариях, в которых ваши действия больше не будут действительными ( вы нажимаете выбор, а машина пуста), и как вы с этим справитесь. (вернуть их деньги, предложить другой вариант и т. д.)
4. Назначить действия и ответы участникам и системе. Кто вкладывает деньги,

Ну, торговый автомат - это, по сути, конечный автомат .

Я бы решил, какие входные данные будут допустимыми (монеты и купюры?) И какие будут выходы быть.

Каковы вероятные результаты, если пользователь подойдет к машине. Какие проблемы могут возникнуть? (слишком много денег, слишком мало денег) Как бы с ними поступить? (выдача сдачи, выдача возмещения)

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

Не существует единственного правильного способа разрабатывать все программное обеспечение с нуля!

Вероятно, существуют десятки различных подходов, начиная от очень небольшого начального дизайна, такого как в Evolutionary Design , до Big Up Front Design, который был описан в августе 2005 года на JoelOnSoftware . Вероятно, есть более чем несколько промежуточных методов, которые имеют свое место, поэтому это зависит от того, какую методологию разработки вы хотите использовать, поскольку для некоторых может потребоваться более предварительный дизайн, как в подходе Waterfall, по сравнению с чем-то более Agile, где требования могут регулярно меняться, а это не Это вызывает много проблем, по крайней мере, такова теория.

В общем, подумайте, какие объекты задействованы в торговом автомате:

• VendingMachine - возможно, абстрактный класс
• DrinkMachine , SnackMachine , и классы, расширяющие VendingMachine
• VendingProduct - абстрактный класс?
• Drink , другие классы, расширяющие VendingProduct
• Coke , другие классы, расширяющие Drink
• и т. Д. И т. Д.

Но я уверен, что вы легко это поймете. Гайки и болты машины будут относиться к некоему вспомогательному классу с методами приема банкнот и монет, расчета сдачи и т. Д.

Дополнительная литература:

• Здесь хорошая статья для начала Дизайн ООП, автор Аллен Голуб.
• Здесь - начало проектирования торгового автомата с использованием ООП.