Программа "Кубик-рубик"

[Olegator]

Программа "Кубик-рубик"

В общем, решил я все-таки вывесить свою идею на всеобщее обозрение. Пускай Билли Гейтс у меня, её украдёт.
Во первых условие:

Как-то на форуме я задавал вопрос про кубик-рубик. Это было не просто так . Я хочу написать обучающую программу, которая бы помогала человеку пытающемуся научится собирать кубик-рубик.
1. Т.е. должен быть представлен текст по сбору кубика-рубика, а программа должна визуально показывать правильно или не правильно человек понял принцип сборки.
2. Программа должна позволять добавлять ещё какие-нибудь головоломки. Т.е. слева будет дерево с головоломками и их разновидности ( кубик-рубик 3x3, 5x5, 7x7, пятнашки и т.д.). А справа они должны визуально отображаться. Наподобие SolidWorks.
3. Должна быть возможность добавления других алгоритмов решения головоломок. Для того, чтобы человек мог по разному решать.
4. Должна быть возможность проверки собственных мыслей и идей. Т.е. возможность экспериментировать.

Писать я буду на С++.

2. С помощью, каких средств мне сделать 3х мерную модель кубика. Он должен вращаться и всё делать как настоящий. Если кто-нибудь видел SolidWorks, Компас, T-Flex и т.д, то это то, что наиболее близко к идеалу. Наверное, надо какой-нибудь 3dmax взять или вроде того?
3. Интерфейс с помощью, каких средств?
4. Конешно Alf будет против, но я думаю, что всё-таки надо применить ICONIX, хотя бы для тренировки.

[Alf]

...
2. Программа должна позволять добавлять ещё какие-нибудь головоломки. Т.е. слева будет дерево с головоломками и их разновидности ( кубик-рубик 3x3, 5x5, 7x7, пятнашки и т.д.). А справа они должны визуально отображаться. Наподобие SolidWorks.
3. Должна быть возможность добавления других алгоритмов решения головоломок. Для того, чтобы человек мог по разному решать.
4. Должна быть возможность проверки собственных мыслей и идей. Т.е. возможность экспериментировать.

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

По поводу графики - извиняй, не помогу ничем. Не мой это конек.

4. Конешно Alf будет против, но я думаю, что всё-таки надо применить ICONIX, хотя бы для тренировки.

Если бы ты меня заставил провести разработку - был бы против. Я и для проектов посложнее ICONIX не использую. А так - вольному воля.

[rimmer]

С помощью, каких средств мне сделать 3х мерную модель кубика

MiS DirectX SDK httpL//msdn.microsoft.com
Работал я немного с ДиректХ, довольно непросто и желательно знать высшую математику

[Olegator]

Как я понял мне надо начать с создания кубика.

[Alf]

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

[Olegator]

Каркас приложения это только интерфейс программы или ещё то, что ты тыписал до этого?

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

[Alf]

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

Интерфейс - это некий модуль, посредством которого ты общаешься с программой либо устройством. Например, для телевизора интерфейс - это пульт ДУ. Если бы тебе поручили разработать навороченный телевизор, неужели ты бы начал с пульта?

[Olegator]

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

И для этого, как я понял, и нужно воспользоваться всякими паттернами.
Как я понял паттерны включают в себя - фасады, фабрики классов, стратегии?

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

Это, что сложнее?

Каркас программы - это структура основных классов

Если бы программа была бы большой, то, как я понял, для этого и потребовался бы ICONIX? Но у меня программа маленькая, и поэтому не надо. Так? Но всё-таки для практики хотелось бы попробовать.

[Alf]

Как я понял паттерны включают в себя - фасады, фабрики классов, стратегии?

Это я привел навскидку названия нескольких паттернов, которые наверняка пригодятся в программе. Конечно, он неполон. Помимо них, наверняка тебе понадобятся паттерны "контроллер", "команда" и масса других.

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

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

Это, что сложнее?

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

Если бы программа была бы большой, то, как я понял, для этого и потребовался бы ICONIX? Но у меня программа маленькая, и поэтому не надо. Так? Но всё-таки для практики хотелось бы попробовать.

Тут не только в размере программы дело. Обычно большие программы разрабатывают большие коллективы. А там, где толпа народу, появляется почва для непонимания и всяческих недоразумений. Отсюда необходмость в координации, а из нее неизбежно вытекает некоторая бюрократия и формализм. ICONIX - это не столько технология проектирования (в основе лежит все тот же объектный анализ Буча), сколько организационная поддержка процесса.

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

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

[Olegator]

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

Именно здесь должно быть проработано решение моей задачи - алгоритм сборки, обучение этому алгоритму, возможности добавления новых головоломок и новых алгоритмов их сборки? Если это так, то потом уже можно приспокойненько наслождаться деланьем интерфейса и 3d модели кубика?

[Alf]

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

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

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

[rimmer]

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

[Alf]

Хотелось бы также сказать, если Olegator будет делать под DirectX желательно сначала изучить этут технологию а потом строить карсас программы на основе его интерфейсов.

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

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

[rimmer]

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

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

Программа должна позволять добавлять ещё какие-нибудь головоломки

Тут хорошо бы подошел какой-то готовый парсер или можно написать свой.
Расширения были бы в виде скриптов, оперировали бы обьектами (например MElliple) а потом задавать им параметры.
Можно просто загружать модели с кодом обработки, но это ИМХО не так гибко

[npak]

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

Я присоединяюсь к отцам-основателям и предлагаю тебе начать с разработки законченного проекта по сборке кубика-рубика на одном из "правильных" языков (Java или C#).  После того, как проект будет сделан, можно будет перейти к фазе обобщения или инкрементально наращивать возможности.  Я предлагаю не пользоваться Си++ по ряду причин.  Во-первых, чтобы не терять время на проектирование управления памятью, лично меня это здорово отвлекает от собственно ООП.  Во-вторых, для Java и С# есть мощные средства по управляемому изменению кода (рефакторинг, refactoring), которые значительно облегчают модификацию и развитие уже существующего кода.

[Olegator]

Я начну делать как Alf сказал. Всё равно надо изучать эти паттерны.

[Alf]

И насчет выбора языка для реализации непременно прислушайся к словам npak'а. Я сам не отважился высказать столь еретическую мысль на форуме, где процентов этак 99 народу программирует на C++,  но втайне абсолютно согласен. 

[MOPO3]

И насчет выбора языка для реализации непременно прислушайся к словам npak'а. Я сам не отважился высказать столь еретическую мысль на форуме, где процентов этак 99 народу программирует на C++, но втайне абсолютно согласен.

Да и я в принципе также согласен

ЗЫ. Надеюсь что до "священной" войны за языки не дойдёт