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

[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] (все буквы в названии тегов должны быть латинские), чтоб другие тоже могли подумать самостоятельно, не видя вашего ответа...

[volvo]

Могу ли я переопределить поле х в потомке

unit unit_a;
interface

type
  ta = object
  private
    X: integer;
  end;

implementation
end.

uses unit_a;
type
  tb = object(ta)
    X: real;
  end;
begin
end.

, т.е., ты можешь воспользоваться тем, что private-члены класса, описанного в другом модуле, не видны в наследнике...

[Archon]

Могу ли я переопределить поле х в потомке

Давай представим, что это возможно:

type
	TA = object
		X: Integer;
		procedure SaveX(Value: Integer);
	end;
	
	TB = object(TA)
		X: String;
	end;
	
procedure TA.SaveX(Value: Integer);
begin
	X := Value;
end;

begin
	TB.SaveX(10); { <- Вызов разрешен, так как метод наследуется, но    }
	              { он (метод) не рассчитан на работу с полем X: String }
end.

В итоге метод SaveX (а он наследуется) оказывается неработоспособным, так как в нем содержатся инструкции поместить значение типа Integer в поле типа Integer, а мы изменили тип поля на String.

Вот хорошая причина, почему это нельзя делать.

[volvo]

Вот хорошая причина, почему это нельзя делать.

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

P.S. Проблема решается добавлением метода, заполняющего строку в класс TB.

[Client]

перегрузку функций

А что это такое?

Добавлено через 3 мин.

private-члены класса, описанного в другом модуле, не видны в наследнике...

А в одном модуле они наследуются? (видимо да...)

[volvo]

А в одном модуле они наследуются?

В одном модуле директивы private/protected не работают, они работают только для попыток обращения из другого модуля. То есть, если я сделаю так:

type
  TA = object
    procedure SetX(value: integer);
  protected
    X: integer;
  end;

  TB = object(TA)
    procedure PrintX;
  end;

procedure TA.SetX(value: integer);
begin X := value; end;
procedure TB.PrintX;
begin writeln(X); end;

var obj: TB;
begin
  obj.setX(10);
  obj.X := 2; // <--- Нельзя !!! Но ошибки нет...
  obj.printX;
end.

, то вроде бы незаконное (по меркам других языков программирования) обращение к полю Х (оно защищенное, то есть, недоступное ниоткуда, кроме методов класса и его потомков) проходит без ошибки. А вот если то же самое попробовать сделать из другого модуля (нижние 6 строк) - все будет работать, как полагается, в строке obj.X := 2; компилятор выдаст ошибку... Это, конечно, не то, к чему привыкаешь, программируя на С++, но вот в Паскале/Дельфи - так...

А что это такое?

Перегрузка функций - это из Object Pascal-я, описание функций/процедур с одинаковыми именами, но разными списками параметров. И пусть компилятор сам разбирается, какую процедуру с заданными мной параметрами надо вызывать...

[Archon]

P.S. Проблема решается добавлением метода, заполняющего строку в класс TB.

А если метод без параметров? Тогда надо уже не добавлять, а перекрывать существующий. Можно, конечно, заставлять программиста перегружать или перекрывать каждый метод, ставший неработоспособным, это как-то не по-Паскалевски. Вот в С++ я могу такое представить.

[Client]

Проблема решается добавлением метода, заполняющего строку в класс TB.

Добавим новый метод, назовем по другому и все? Или что-то тут не так?
И можно новую задачку попроще, для чайника

P.S. Экзамен сдал на 5