#c -cli #encapsulation #oop
#c -cli #инкапсуляция #ооп
Вопрос:
Учитывая приведенный ниже пример класса на C , как вы можете видеть, можно получить доступ ко всем свойствам / методам для pic1 из вызывающего модуля. Но доступ к pic2 возможен только через эти объявления в разделе public. Помимо только что упомянутого пункта, как новичку в объектно-ориентированном программировании, мне просто интересно, какой метод предпочитает профессионал для реализации в реальной жизни?
using namespace System::Drawing;
using namespace System::Windows::Forms;
using namespace System;
ref class myClass
{
PictureBox^ pic2;
public:
PictureBox^ pic1;
void setPic2() {pic2 = gcnew PictureBox;}
void addPic2ToControl(System::Windows::Forms::Form^ x) {x->Controls->Add(pic2);}
void setPic2Image(String^ filePath) {pic2->Image = dynamic_cast<Image^>(gcnew Bitmap(filePath));}
//more functions for to access pic2...
};
Ответ №1:
Инкапсуляция в C обычно выполняется путем пометки полей в вашем классе как private
или protected
. Однако вы не должны полностью полагаться на это как на способ сохранить вещи по-настоящему приватными сами по себе — например, если это действительно проблема безопасности, это вообще не поможет (помните friend
функции.) Это больше предназначено для того, чтобы «разделять и властвовать» над сложностью программы и поддерживать чистоту кода. Это извечная проблема в компьютерном программировании, и инкапсуляция — всего лишь один из многих действенных методов, разработанных программистами за эти годы.
Как следует использовать инкапсуляцию в вашем исходном коде? Ну, например, многие люди будут настаивать на том, что у вас никогда не должно быть открытых переменных в ваших классах, только общедоступных методов, и что общедоступные переменные должны эмулироваться с использованием функций «getter / setter». Я не обязательно согласен с этим, но я думаю, будет справедливо сказать, что ваши классы должны рассматривать то, что он делает, как общедоступную информацию, а то, как он это делает (и его внутреннее состояние), как личную информацию. В любом случае, это просто здравый смысл, даже если вы не используете ООП. Среди программистов на C static
(постоянная) переменная внутри функции считается лучшей практикой, чем переменная с глобальной областью видимости, если вам это сойдет с рук.
Комментарии:
1. На данный момент я получил 3 ответа. И все три ответа подтвердили то, что я узнал и понял. Поскольку ваш является первым. Я буду отмечен как ответ.
Ответ №2:
Что такое инкапсуляция?
Encapsulation
означает объединение данных и методов, которые работают с этими данными, в единое целое.
Как вы реализуете инкапсуляцию?
Путем создания type
подобного structure
или class
Обычно переменные-члены данных внутри класса хранятся в спецификаторах доступа private
или protected
, и доступ к ним предоставляется через public
функции-члены. Это защищает честные ошибки программиста от случайного изменения данных участника, если они доступны публично. Он предоставляет средства доступа и изменения данных элемента посредством явных общедоступных вызовов функций и, следовательно, более продуман и менее подвержен ошибкам.
Учитывая вышесказанное, я считаю, что сохранение pic2
конфиденциальности и предоставление доступа к ней через member functions
представляется подходящим способом
Комментарии:
1. На данный момент я получил 3 ответа. И все три ответа подтвердили то, что я узнал и понял.
2. @user523234: Это лучшее в SO. Множество ответов, которые помогают узнать что-то новое 🙂
Ответ №3:
Одним из преимуществ ограничения доступа к элементам с помощью методов является то, что теперь вы контролируете управление переменной в центральном расположении (внутри самого класса). Если позже вы решите выполнить некоторую обработку в pic2, прежде чем предоставлять его вызывающей стороне, вы можете сделать это в своих методах доступа без необходимости изменять его в нескольких местах
Позже, если производительность вызывает беспокойство, вы можете рассмотреть возможность встраивания методов
Комментарии:
1. На данный момент я получил 3 ответа. И все три ответа подтвердили то, что я узнал и понял.