Чечако_newПишу игру Сапер, пока разбил классы так:
Информация к размышлению: своим студентам я давал задание написать ее за один час.

Чечако_newВнимание вопрос! :)
Ответ: Вы описали на три класса больше, нежели нужно для разумного решения этой задачи.

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

kZ25А Вы бы не могли представить какой-нибуть вариант решения ваших студентов, который Вы считаете лучшим.
Нет, не могу, я их не сохранял. Сходу могу дать следующую картинку



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

1111111111111111111Молодой на уровне здесь и сейчас решит быстро все это путем создания кучи малы.
Безусловно. И первое сообщение темы это хорошо показывает.

1111111111111111111но думать чисто, чтобы не было в голове кучи малы не научит.
"Думать чисто" и "куча мала" не имеет ни малейшего отношения к выбору между процедурным и объектным стилем.

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

1111111111111111111то таки да, простой процедурный подход к игре, на основе классов и объеков выдаст решение в течении часа
(Допустим, я угадал смысл этой фразы)

Видите ли в чем дело, конечная цель нашей профессии - эффективное решение задач. Если в случае подхода А задача может быть решена в течение часа (мое время для картинки выше - 42 минуты), а потом доработана в течение пятнадцати минут, а подход Б требует четырех часов и тридцати минут соответственно - значит, выбор подхода Б для этой задачи будет непрофессиональным решением.

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

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

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

kZ25Так моя задача и заключается не в достижении результата, а в самом процессе.
Это неудачная постановка вопроса. Очень неудачная. Не стоит привыкать к неправильным целям/методам, даже если Вы осознаете исключительность случая. "Учиться правильно" - гораздо эффективнее, нежели "учиться неправильно и потом переучиваться".

kZ25Я хочу спроектировать структуру, чтобы ее потом можно было разширять
Расширять - понятие довольно нечеткое. Если Вы хотите спроектировать структуру классов для Сапера так, чтобы из нее потом легко получились Шахматы и Пасьянс, то довольно неудачна мысль начинать с Сапера - тут стоит сразу думать о более глобальных концепциях, таких как ИгровоеПоле, Стороны, ИгровыеОбъекты, Правила...

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

- Если в приложении предполагается выбор между несколькими версиями игры и/или несколькими вариантами интерфейса (скажем, gui- и web-), нужны два класса (Движок и Интерфейс).

- Если вышеописанные условия не выполняются, достаточно "одного класса на все", хотя два будет не особо хуже.

kZ25Может, как и в случае с подавившемся человеком, я не совсем удачно выбрал пример,
Именно так. Если хотите отрабатывать сложные объектные взаимодействия - сделайте какой-нибудь простенький военный симулятор (игровое поле и несколько типов солдат). И приписывайте им групповое взаимодействие и прочее до одури - поверьте, работы хватит :)

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

kZ25Потом эти приемы я смогу использовать и на более сложных задачах, где они будут уже необходимы.
Потом - поверьте, это уже статистическое наблюдение, проблема довольно многих известных мне людей - Вы привыкнете использовать неподходящие средства для решения неподходящих задач, и отучиться от этого будет не так просто. На этом форуме легко найти сотни примеров постов примерно следующего содержания: "Вот я освоил вот такую замечательную кувалду, как бы мне применить ее чтобы вытереть пыль с хрусталя?"