Объекты... Объекты? Объекты !, (для начинающих) Опции

[volvo]

Итак, в этой теме я бы хотел поговорить об объектах, то есть об ООП (Объектно-Ориентированном Программировании). Я не буду опять описывать всю теорию, называть 3 основных принципа ООП, и т.д., это все можно прочитать вот тут: ООП. Объектно-ориентированное программирование , да и в любой книжке по языку программирования. Любому языку программирования.

Здесь я бы хотел поговорить о другом. О решении конкретной задачи с использованием объектов. Причем хотелось бы, чтобы это был не монолог, а диалог. Если вам (а я обращаюсь не только к тем, кто начинает программировать вообще, как выяснилось, даже люди, программирующие достаточно давно, не считают ООП "своей стезёй", эта тема и для них тоже) интересно - я буду продолжать. Если неинтересно - скажите, я продолжать не буду. Я уже когда-то начинал подобную тему, но особого отклика это не получило. Задавайте вопросы, не бойтесь, что они покажутся странными, простыми и т.д. Здесь важно разобраться во всех мелочах.

Для начала я бы хотел взять вот такую задачу (это - реальное условие, в которое я внес небольшие изменения): "Написать программу (работающую в диалоговом режиме), которая осуществляет взаимодействие пользователя с одной из трех ДСД - динамических структур данных - Список, Стек, Бинарное дерево, и позволяет:
1) добавлять элементы в структуру
2) удалять элементы из структуры
3) отображать текущее содержимое выбранной структуры данных на экране".

Ну, для начала, "а почему именно ООП?" спросите вы. И отчасти будете правы, поскольку эту программу (как и все остальные, впрочем) можно написать, используя процедурное программирование. Отвечаю :
1) Если б я хотел, чтоб это было написано без ООП, я бы не начинал эту тему (или не включил бы сюда эту задачу), в оригинальном задании так и было сказано: "... объектно-ориентированную программу..."
2) решить задачу с использованием только процедур/функций, конечно, можно, но такое решение будет а) более объемным, чем с использованием объектов; б) менее расширяемым

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

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

type
  TList = object
    { тут реализация списка }
  end;
  TStack = object
    { тут реализация стека }
  end;
  TTree = object
    { тут реализация дерева }
  end;
  
Var
  myList: TList;
  myStack: TStack;
  myTree: TTree;
  
{ ... }
WriteLn('С какой структурой будете работать? 1) List 2) Stack 3) Tree');
ReadLn(ch);
Case ch of
  '1':
  begin
    { работа со списком через myList }
  end;

  '2':
  begin
    { работа со стеком через myStack }
  end;

  '3':
  begin
    { работа с деревом через myTree }
  end;
end;

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

P.S. Если это задание вам кажется неподходящим, предлагайте свои варианты, можете взять любое реальное задание с форума со ссылкой на него (только не надо давать здесь свое задание, в надежде, что вам тут его решат полностью. Может, и решат, но времени это займет достаточно много )

P.P.S. Свои ответы скрывайте тегами [SPОILER][/SPОILER] (все буквы в названии тегов должны быть латинские), чтоб другие тоже могли подумать самостоятельно, не видя вашего ответа...

[Archon]

О, хорошая тема. Советы от гуру =)

Спойлер (Показать/Скрыть)

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

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

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

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

Хотелось бы знать, существует ли такая проблема, или это мне чудится на пустом месте?