(Продолжение первой статьи)
Если продолжать объектно-ориентированное мышление, эта тема кажется слишком большой. То, что я только что сказал и упомянул здесь, на самом деле является лишь некоторыми незначительными проблемами, на которые следует обратить внимание при кодировании. Поэтому, возможно, было бы более уместно заменить термин «во всем» на «иметь в виду».
Некоторые комментарии к некоторым возможностям Delphi:
Интересно, заметили ли вы, что все компоненты (включая элементы управления), размещенные в форме Delphi, видны другим формам. Если быть точным, эти компоненты являются содержимым публичной части формы. С одной стороны, этот результат хорош, поскольку благодаря его гибкости другие классы могут легко ссылаться на эти компоненты в Форме, задавать их свойства, выполнять их методы, события и т. д., но с другой стороны, его недостатки также очевидны; Да, это приводит к потере инкапсуляции формы. По моему мнению, эти компоненты, размещенные в форме, по замыслу пользователя, должны существовать как частные свойства формы и не должны быть видимы другим классам или другим формам. Даже если вам необходимо получить к ним доступ, вам следует получить к ним доступ косвенно через ряд методов свойств, предоставляемых Form.
Приведите пример, чтобы дать каждому некоторое понимание:
PROcedure TForm1.Button1Click(Отправитель: TObject);
начинать
Form2.Edit1.Text := 'abc'; // <-- Я не согласен с тем, как написано это предложение.
конец;
Многие люди, возможно, не имеют в виду концепцию инкапсуляции при написании такого кода, но после прочтения этой статьи вы никогда больше не будете делать ничего подобного (пожалуйста, измените свой подход!). По моему мнению, TForm1 — это TForm1, а TForm2 — это TForm2. Все они существуют для выполнения определенных конкретных функций, поэтому предоставляют некоторые интерфейсы с внешним миром (некоторые атрибуты, методы и события. Строго говоря, события тоже являются атрибутами). выполнить обещанные функции. Что касается конкретной реализации этих интерфейсов, они должны поддерживаться сами по себе. Никакой необходимости или возможности вмешательства внешнего мира нет. Эта идея соответствует практическим приложениям, то есть вопросу о том, должен ли From1 иметь прямой доступ к Form2.Edit1. Лично я предпочитаю следующую реализацию:
//Ниже приведена часть содержимого TForm1 в Unit1
процедура TForm1.Button1Click(Отправитель: TObject);
начинать
TForm2(FAnotherForm).EditText := 'abc'; // <-- Эта реализация воплощает идею инкапсуляции
конец;
//Ниже приведено определение TForm2 в Unit2.
тип
TForm2 = класс (TForm)
Edit1: TEdit;
частный
функция GetEditText: строка;
процедура SetEditText(const Value: string);
общественный
свойство EditText: чтение строки GetEditText запись SetEditText;
// <-- Мои рекомендации по использованию;
конец;
…
функция TForm2.GetEditText: строка;
начинать
результат: = Edit1.Text;
конец;
процедура TForm2.SetEditText(const Value: string);
начинать
если Значение <> EditText, то
Edit1.Text := Значение;
конец;
FAnotherForm здесь — это частное свойство TForm1, которое является указателем на экземпляр TForm2 (это использование было подчеркнуто в первой статье). Доступ к свойству EditText TForm2 вместо безрассудного прямого доступа к Edit1.Text TForm2 воплощает идею, то есть идею разделения труда и сотрудничества, то есть идею независимости, то есть идею инкапсуляция.
(Незакончено, продолжение следует)
Еще статьи