Считаю, что большинство учебников по ООП врут.

 

Доступ к переменным объекта должен быть всегда!

За исключением случаев когда доступ не ограничен просто доступом, а предваряется процедурами и/или процедуры следуют после доступа.

Господа, писать две функции GetVariable() и SetVariable() для private переменной c одной строчкой - это дебилизм!

 

Кто что думает?

QUOTE (Nox Metus @ Aug 16 2006, 18:40)

QUOTE (AmbassadorKosh @ Aug 16 2006, 18:09) Удобно только то, что красиво. Пачиму? А пачиму бы и нет? ;) Вы не согласны? ИМХО Если код красив, значит он удобен. Для меня это равноценные понятия. Элегантность, красота, легкость поддержки --- все одного поля ягода. Просто все это для меня включено в понятие красота. Так что мое верхнее рассуждение, лишь констатация цикла.

QUOTE (AmbassadorKosh @ Aug 16 2006, 21:17)

А пачиму бы и нет? ;) Вы не согласны? ИМХО Если код красив, значит он удобен. Для меня это равноценные понятия. Элегантность, красота, легкость поддержки --- все одного поля ягода.  Просто все это для меня включено в понятие красота. Так что мое верхнее рассуждение, лишь констатация цикла.

Несогласный я. На этом направлении постоянно кипят войны "Красота/Элегантность против Удобства/Быстроты". И любители длинных ассоциативных имен вечно ругаются с поклонниками коротких.

А чем инкапсуляция-то плоха? Что-то автора не совсем понимаю. Громоздкость, если она и есть, будет всего один раз - при описании класса, но зато сколько плюсов потом(уже перечислили и логируемость доступа и отслеживание диапозона). А если вопрос стоит о времени доступа к переменной, то есть конструкция типа ifdef/ifndef/endif, и че-нить типа #define debug_mode, в случае чего все доступы к полям могут идти через методы или вообще все простейшие типы объявлены, как классы (типа #define _myint class{...}, а во всех классах программы используется не int, а _myint, который в случае release_mode просто int, а в случае debug_mode - класс), а оператор присваивания им перегружен(как указывал gutterboy) и сами эти классы ведут логи. Частенько такая конструкция очень удобна на стадии отладки, если программа большая. Короче, инкапсуляция спасает от кучи возможных ошибок.

З.Ы.

Жизненный пример: водителю автомобиля, к счастью, не требуется управлять системой зажигания и координировать работу цилиндров. У него есть педали, рычаг и руль. А ведь если бы было не так, какие безграничные возможности бы открывались, например, один цилиндр в одну сторону, другой в другую.. прямой доступ к конструкции, красота https://academ.club/html/emoticons/biggrin.gif

QUOTE (AmbassadorKosh @ Aug 16 2006, 21:17)

ИМХО Если код красив, значит он удобен. Для меня это равноценные понятия. Элегантность, красота, легкость поддержки --- все одного поля ягода. Просто все это для меня включено в понятие красота. Так что мое верхнее рассуждение, лишь констатация цикла.

Это, я тоже несогласный.

 

Чем дальше, те больше я считаю наиболее важным требование читабельности и понятности кода.

 

Другое дело, что коду очень много требований, причем требования к коду достаточно сильно связаны с требованиями и стилем дизайна. Которые вытекают из требований к проекту.

Поэтом в каждой конкретной ситуации - свои компромиссы.

 

 

Насчет элегантность, красота ~ легкость поддержки, категорически несогласен.

Ладно-ладно. Был неправ. Исправлюсь.

Ну просто для меня это почти синонимы.

Красоту можно видеть как в лаконичном, так и в длинном и развернутом изложении. И удобство тоже.

Красоту можно видеть изящных и ажурных конструкциях, а можно в мощных цементных балках.

Все зависит от ситуации и от цели. Но при этом для меня важно, что бы в данном конкретном контексте задачи ее решение выглядело красиво.

 

"Elegance is not a dispensable luxury but a quality that decides between success and failure." Edsger Wybe Dijkstra

 

PS. Еще раз извиняюсь поторопился с изначальными формулировками.

QUOTE (Timotheus @ Aug 17 2006, 00:14)

А чем инкапсуляция-то плоха? Что-то автора не совсем понимаю. Громоздкость, если она и есть, будет всего один раз - при описании класса, но зато сколько плюсов потом(уже перечислили и логируемость доступа и отслеживание диапозона).

Я так понимаю ситуацию: есть переменная, доступ к которой логировать не надо, которую просто надо сделать public.

Из перечисленных перимуществ подходит только одно - возможность сделать их virtual'ами и перегрузить в детях. Добавлю: возможность расширить видимость в детях. Но, поскольку изначальная видимость - public, актуально только для Delphi - там есть еще published).

QUOTE (GrayFace @ Aug 17 2006, 18:37)

Я так понимаю ситуацию: есть переменная, доступ к которой логировать не надо, которую просто надо сделать public.

Ну и надо её публиком делать) Кто мешает-то?) Никто ж публик отменять не собирается. А в дельфи вообще пропертиз есть, где всё вполне изящно устроено=)

З.Ы.

А вообще насчет доступных полей не всё так просто: если кажется, что поле вполне можно делать общедоступным, то не факт, что это так на самом деле. Всевозможные ошибки всё равно предусмотреть нельзя. Лично я стараюсь как можно меньше допускать в своем коде полей с пометкой public, более того, стараюсь делать структуру программы такой, чтобы не требовалось доступа к полям напрямую, ведь ООП всё же так и задумывалось..

Изменено 17 августа, 200619 г. пользователем Гость

QUOTE ([vt]vitus @ Aug 15 2006, 13:29)

QUOTE (gutterboy @ Aug 15 2006, 13:12) Вроде как ничего не мешает перегрузить (т.е., определить для данного класса) операторы. Тут идёт речь про ООП. Далеко не везде можно перегружать операторы ... Если речь бы шла таки про объектно-, то подразумевалось б намерение ко всем потрохам доступаться через интерфейс, а не напрямую.   А умные книжки (толкующие про C++) как раз явно, открытым текстом советуют перегружать оператор присваивания для сохранения инкапс"ю"ляции на фоне приятночитаемости. ИМХО gutterboy дал точный вариант ответа на вопрос автора ветки. То есть в духе: "пользуйтесь C++ и будет вам щястье". Ведь вопрос "какой инструмент самый крутой" - из другой ветки?

QUOTE (ПалСемёныч @ Aug 17 2006, 23:50)

А умные книжки (толкующие про C++) как раз явно, открытым текстом советуют перегружать оператор присваивания для сохранения инкапс"ю"ляции на фоне приятночитаемости.

Я че-то не могу уловить, какое отношение имеет перегрузка опереатора присваивания к инкапсуляции?

А можно задачку для тех, кто говорит про перегрузку оператора присвавания ? (я, видимо, чего-то сильно не понимаю... вернее, я вижу один подход, но он, извиняюсь, через ж).

 

Пусть у нас есть класс Window (почти все книжки про ООП почему-то любят окошки, кнопочки и т.д....). У окна есть свойства: позиция левого верхнего угла: int x,y; ширина и высота: int w,h; и заголовок: string<wchar_t> caption. Вопрос: как с помошью перегрузки оператора присваивания реализовать инкапсуляцию данных так, чтобы при изменении параметров пользователь немедленно видел результат?

 

PS. И да, свойства (в том или ином виде) сильно повышают читабельность. Так что тут C++ не самый удобный язык.

Наверное они предложат вот такое решение.

#include <iostream>

class IntSetter {
 int value;
public:
 IntSetter(int val) : value(val) {};
 operator int() const { return value; }
};

class XSetter : public IntSetter {
public:
 XSetter(int x) : IntSetter(x) {}  
};
class YSetter : public IntSetter {
public:
 YSetter(int y) : IntSetter(y) {}
};

class Window {
 int x, y;
public:
 Window(int wx, int wy) : x(wx), y(wy) {}
 
 Window &operator =(const XSetter& sx) { x = sx; }
 Window &operator =(const YSetter& sy) { y = sy; }

 void dump () const {
   std::cout << '(' << x << ", " << y << ')' << std::endl;
 }
};

int main(int argc, char *argv[]) {
 Window w(1,2);

 w.dump();

 w = XSetter(3);
 w = YSetter(4);

 w.dump();
 
 return 0;
}

Только вот это читабельности ни разу не повышает... все-таки w.setPos(x, y) как-то понятнее...

QUOTE (busa @ Aug 18 2006, 12:55)

Только вот это читабельности ни разу не повышает... все-таки w.setPos(x, y) как-то понятнее...

Ну эт понятно. Все это чисто академические экзерцисы, чья задача показать что так можно сделать. Однако я не уверен, что какой-нибудь серьезный дядька, в какой-ниубдь серьезной книжке по С++ рекомендует так делать =)

 

А еще понятнее назвать этот метод не SetPos, а допустим moveTo, поскольку такое именование раскрывает так сказать суть side-affects этого метода.

Изменено 18 августа, 200619 г. пользователем Гость

QUOTE (AmbassadorKosh @ Aug 18 2006, 13:07)

QUOTE (busa @ Aug 18 2006, 12:55) Только вот это читабельности ни разу не повышает... все-таки w.setPos(x, y) как-то понятнее... Ну эт понятно. Все это чисто академические экзерцисы, чья задача показать что так можно сделать. Однако я не уверен, что какой-нибудь серьезный дядька, в какой-ниубдь серьезной книжке по С++ рекомендует так делать =) Почему бы и нет?.. Серьёзные дядки, серьёзный книги! В С#, есть и другие функции.

QUOTE (Длинные Руки @ Aug 18 2006, 13:09)

Почему бы и нет?.. Серьёзные дядки, серьёзный книги! В С#, есть и другие функции.

А почему бы и да? (с) Nox Metus

 

И причем тут "другие функции C#". Какие функции? Ничего не понял...