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

[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 экземпляра Стека - уже наводит на некоторые размышления. Их не должно быть, потому что все, что я хотел - это сменить реализацию, а это достигается с помощью "pImpl idiom" - того способа, который я тебе показал... Все делается внутри одного экземпляра.

Однако внутри экземпляра происходит тоже самое - удаление старого экземпляра PImpl и создание нового. Хотя то, что это происходит внутри - уже плюс.

Кстати, еще один минус твоего кода: если тебе понадобится сменить "реализацию" с TImplementation2 на TImplementation1 - будешь добавлять еще один метод? А если реализаций не 2, а 4? В моем случае - хоть заизменяйся, как только появилась единственная реализация change_impl, можно менять все что угодно, в любую сторону...

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