объектно-ориентированное программирование

[Oleg_SK]

Помогите, плиз, разобраться с сабжем. Для начала хотелось бы уточнить один вопрос и разобраться: как решить с помощью сабжа интересную мне задачу. Вопрос следующий: что представляет собой объектно-ориентированная программа? Как я понимаю, есть следующие варианты ответа:
1) Программа представляет собой множество классов, и ее выполнение полностью состоит из взаимодействия этих классов между собой и операционной системой;
2) Программа как и раньше представляет собой в основном набор процедур и функций. Классы при этом используются для реализации новых типов данных, используемых в обычных процедурах и функциях. То есть объектно-ориентированное и процедурное программирование используются совместно, дополняя друг друга.
3) Что-то другое.

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

З.Ы: Учусь программировать на C++.

[ozo]

Есть задачи, которые лучше решать процедурно, а есть, которые лучше решать с помощью ООП, эта не из них.

[MaTBeu]

Начнем разбирать задачу снизу. То есть, с самых мелких частей.

Клетка

стоит ли клетки доски делать отдельным классом и включить двухмерный массив объектов этого класса в состав класса доски?

Задайте себе вопрос - что хранит клетка?
Если она хранит в себе только координаты - делать класс не нужно. Но если она хранит еще и метку, был здесь конь или не был - лучше сделать отдельный класс. Потому что без класса, вам прийдется хранить в объекте доски еще один массив/стек - посещенных вершин. А так можно узнать посещалась ли эта вершина прямо у вершины.

Game
Стоит делать отдельным классом, потому что лучше собрать управление программой в одном месте.

Отношения между классами
Класс Game
Хранит в себе указатель на доску (агрегация)
Хранит в себе указатель на объект-коня (агрегация)
Хранит в себе указатель на стек сделанных ходов, если он нужен (агрегация)

Класс Доска
Хранит в себе массив объектов-клеток (агрегация)
Использует указатель на родителя-Game, для отправки сообщения о добавлении вершины в стек пройденных (ассоциация)

Класс-Конь
Использует указатель на объект-доску, чтобы посылать ему сообщения о сделанном ходе (ассоциация)

Это предварительный вариант. Посмотрите и определитесь, что вас устраивает по задаче, а что нет. Вдруг я что-то не так понял.

[pu4koff]

ООП - это такая свободная штука, которую нельзя использовать правильно на 100%. У ООП куча подходов к проектированию. Смотря от чего отталкиваться и к чему идти.
С досками, конями,.. - это проектирование предметной области получается, т.е. в классах выражаем реальный мир. Только вот нужно ли это всё при решении данной задачи?
Класс - это структура данных, которая имеет состояние и может его изменять через выполнение соответствующих методов. Теперь рассмотрим классы:
Игра - какое у неё состояние? Доска? Но доска будет разная для каждого хода конём. Допустим, мы добавили состояния: новая игра и законченная игра. Что они нам дадут? А ничего, т.к. новая игра нам не нужна, а когда игра будет закончена и так известно (после вызова метода "найти все ходы конем"). Ну добавим мы в состояние еще и доску. Она будет либо пустой в начале игры, либо заполненной по её завершению. Смысл? Я его не вижу.
Класс доски в принципе можно еще выделить, чтобы упростить доступ к ячейкам и организовать проверку на возможность хода в эту ячейку. Но над этим я бы тоже подумал, т.к. это вряд ли задача доски, скорее это к игре относится, но т.к. у игры нет состояния, то это выливается в функцию типа:

bool сделать_ход(доска, клетка)
{
  if (доска[клетка.колонка][клетка.столбик])
  {
    return false; // Ход сделать нельзя. В клетке уже был конь
  }
  доска[клетка.колонка][клетка.столбик] = true;
  return true;
}

Я бы в данном случае организовал хранение доски в виде куска памяти в 64 бита и написал простенькую обертку для удобного доступа к клеткам (1 клетка = 1 бит. true - конь в клетке уже был, false - конь сюда еще не заходил).
Теперь класс конь: я вижу только возможным состоянием позицию коня на доске. Из методов только генерацию нового хода. Из-за одного метода создавать класс? Считаю, что за этим все же к функциям опять, а не к ООП.
В общем, считаю задачу неудачной для изучения ООП, равно как не вижу веских оснований для использования данной штукенции. Можно выстроить иерархию классов как написал MaTBeu и это даже будет с одной стороны правильным, но я бы этого не делал. ООП - это как философия, можно доказать правильность любой иерархии классов и это будет так, но и кучу "ошибок" всегда можно найти.