Структура vs класс

>Потому что в 90-92 интернет был. У тебя не было? Сам виноват.
То что не свалил за кардон? У меня например инет только два года назад появился, а живу я делеко не в глубинке.

>То что не свалил за кардон?

Так самое смешное, что и сваливание за кордон не помогло бы :) Интернет в современном виде стал формироваться только с ~1994-го. А литература в нём стала появляться во второй половине 1990-х. Я, как бы, застал эти времена (где-то с конца 1996-го или начала 1997-го). Поисковая система хоть как-то работающая - одна. Никаких Гуглей нет даже в проекте. Единственный способ как-то связывать сайты - это взаимный обмен ссылками. На каждом новом сайте в первую очередь лезешь в раздел «Ссылки» и ищешь, нет ли там чего-то новенького. Русскоязычных сайтов почти - нет, все чуть не наперечёт записаны...

Авиабаза летом 1997-го начала создаваться именно как коллекция Интернет-ссылок авиационной тематики. Всемирных! :D

Я даже для истории оставил, как это выглядело :)

http://airbase.ru/misc/first-step/index.htm

Вполне возможно, что это был первый русскоязычный сайт авиационной тематики :)

И только через пол-года, в декабре 1997-го он начал наполняться контентом - http://airbase.ru/update/97-12.htm

...

Эх, ностальгия...

Кстати, ну чем не блог? :) - http://airbase.ru/update/98-01.htm Хотя термина такого тогда ещё не было...

Да я смотрю ты причастен к созданию интернета. ^)

>Web design =KRoN= 07.01.98

<table width=«100%» border=«8»

У меня были 12 px на хоумпэйдже, и это было круто, 3д таблицы...

>Да я смотрю ты причастен к созданию интернета

Я, конечно, человек скромный, но не могу не отметить то, что первым начал связывать воедино русские авиационные ресурсы :D http://web.archive.org/web/20000930062201/airbase.uka.ru/rusar/

Хотя авиасайты вообще к тому времени в России уже были ( http://web.archive.org/web/19980521125212/http://www.aviation.ru/ - кстати, именно его автор меня с Linux в своё время и познакомил), но созданием сайтов на русском почти никто не занимался. Считалось напрасной тратой времени. Я же английского не знал, так что решил делать свой вариант, с подкидным дураком и женщинами лёгкого поведения :)

суслик был в начале 90-x (и по-моему где-то года с 1991), но не тут. ну и usenet, разумеется. а так первый внешний канал (только для почты и nntp) - 1990 год.

>3д таблицы...

Да... Долго они были :) Зато каким откровением стало создание однопиксельных рамок у таблиц! Увидел впервые где-то на буржуйском сайте и стал использовать этот хитрый метод (таблица с чёрным бэкграундом, внутрь которой вписана другая таблица, уже без бордюра, но с однопиксельным cellspacing) во всех таблицах, пока не появилась возможность сделать то же самое через CSS :)

...

Самое забавное, что книг по HTML тоже не было. Список тэгов я отлавливал, копаясь в бинарнике Mosaic'а, поведение их изучал методом тыка. Ни о каких стандартах тогда вообще даже никто краем уха не слышал. Романтика, блин! :)

>ну и usenet, разумеется

Именно. И каналы того времени очень негативно сказывались на распространении литературы :) Помню, сколько мучений стоило качать ночами книги с BBS...

> Угу. В Европе.

А для блатных и в России.

И без браузера (Mosiac вышел в 1993-м) :)

И на кой тебе www? Есть ftp, gopher.

Ну и вообще охрененный источник информации - Usenet.

Ну-ка мне пример Интернет-провайдера в Москве (СССР, однако!) в 1990-м.

Ишь чего захотел. Я же говорю - для блатных. В НИИ всяческих.

>А для блатных и в России.

Угу. И я сам виноват, что не был блатным :D Короче, ты фееричен.

Не помню год, но потом пошла мода на картинки для кнопок, всевозможные текстуры, а по ним идиотичной и несглаженой гельветикой «домой, ссылки, контакты», тоже был дурацкий момент, но наверное уже скорости выросли, я вообще первый интернет подключал 2400бод

Конечно сам виноват. Кому надо было информацию добывать - те находили способы у знакомых знакомых через пень-колоду знакомых натырить, а не занимались хернёй с самодрочерским самообразованием.

> Вы не имеете понятия о том, реализованны ли данные как float x, y, z, хранить ли класс эти элементы как double, преобразую их в float, или же он хранит их на Луне и получает через спутник."

Это всё прекрасно, но нафиг надо? Всё равно, что вместо легковушки купить себе танк - а чо, вдруг гражданская война будет.

>Всё равно, что вместо легковушки купить себе танк - а чо, вдруг гражданская война будет.

И снова повторю тезис. Тем, кто пишет write-only-and-forget - оно не нужно. Оно нужно тем, кто пишет код, с которым ему работать и через год, и через пять лет.

>Тем, что убогий с++ не умеет свойства.

свойства не нужны, т.к. нарушают инкапсуляцию точно так же, как и геттеры/сеттеры

>имхо геттеры/сеттеры имеют смысл в следующих случаях

...

2). наличие внутренних связей между полями у объекта

3). верификация поступающих данных.

4). наличие внешних связей. в т.ч. оповещение через события.

В таком случае — будет ли правильно называть эти методы геттерами/сеттерами? Потому как обычно под этим понимают const T& GetSomeShit const { return m_Shit; } + void SetSomeShit (const T& shit) { m_Shit = shit; }.

>В таком случае — будет ли правильно называть эти методы геттерами/сеттерами?

Вопрос уже сугубо терминологический. А если по факту, то просто сокрытие внутренней структуры данных объекта многократно повышает гибкость и модифицируемость оного.

> Тем, кто пишет write-only-and-forget - оно не нужно.

Бездумная генерация геттеров и сеттеров есть глупость. Если в сеттере нет хотя бы одной проверки, он нафиг не нужен, и неважно, что говорят об этом учебники по Яве.

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

Ты имеешь в виду «Мы с тобой пофессионалы - давай достанем и померяемся»? :)

>>В любом случае публичных данных надо стараться избегать.

Громоздкий способ получается. Вон даже тролли этому правилу не следуют. Если к каждому Private-классу приделать get/set то Qt распухнет в несколько раз точно.

«Избегать публичных данных» != «использовать сеттеры/геттеры». Ибо, как уже сказано было выше, у объекта должен быть удобный, простой и понятный интерфейс, позволяющий любому представителю интеллектуального большинства его использовать — без необходимости понимать, «что там внутри». Собственно, это и есть инкапсуляция. А get/set на каждый метод — это культ карго в ООП: когда человек использует возможности объектного программирования просто ради того, чтобы их использовать, потому что «все так делают».

>Если в сеттере нет хотя бы одной проверки, он нафиг не нужен, и неважно, что говорят об этом учебники по Яве.

То есть, когда тебе через полгода придётся вводить проверку или менять внутреннее представление, ты будешь переписывать весь использующий данный объект код? Нет уж, я лучше геттер/сеттер организую :)

Ты имеешь в виду «Мы с тобой пофессионалы - давай достанем и померяемся»? :)

Зачем? Я не доказываю тебе что-то, ибо себе давно уже практикой всё доказал :) Просто делюсь мнением.

...

Опять же, выше уже звучал не раз вопрос унификации работы с объектами. Если в одном объекте title - это статическое поле, а во втором - сложная функция, то если ты хочешь унифицированно работать со всеми видами объектов - придётся писать геттер.

>get/set на каждый метод

следует читать: get/set на каждое поле

Геттеры и сеттеры не нарушают инкапсуляции, поскольку скрывают внутреннее представление объекта. Точка.

Они позволяют получать часть информации о его внутреннем состоянии, и изменять его, передавая ту информацию, что нужна для его изменения. Но это не то же самое, что дать доступ к открытым членам класса.

Однако, если речь идет о структуре, полностью согласен, нужно сохранить ее структурой. И если Qt разработчики сделали это объектом с геттерами и сеттерами, значит преследовали определенные цели, о которых мы можем только догадываться.

Среди них-единообразие интерфейсов, возможность изменения внутреннего представления этой структуры, но наверняка сказать нельзя.

>без необходимости понимать, «что там внутри». Собственно, это и есть инкапсуляция. А get/set на каждый метод — это культ карго в ООП

Ничего не понимаю. Где-то тут противоречие :)

get/set - это и есть способ работы с объектом без понимания «что там у него внутри».

>следует читать: get/set на каждое поле

А, понятно. Но это, вроде бы, очевидно. Зачем get/set на каждое поле, если оно не нужно «снаружи»? Речь идёт именно о внешнем доступе к нужным внутренним данным объекта.

> Да не нужны никому хорошие языки! Нужны хорошие библиотеки, хорошие програмы, хорошее сообщество, хорошая документация. А языки всё равно все одинаковые.

Если бы это было правдой, то писали бы все сейчас на асме, Фортране, или Лиспе, т.к. когда появлялись все остальные языки у этих уже давным давно было и сообщество и библиотеки и программы и документация. Очевидно, хорошие языки никому не нужны по другой причине.

>простой и понятный интерфейс, позволяющий любому представителю интеллектуального большинства его использовать — без необходимости понимать
То есть метод - «сделать пи...то»?

>> Если в сеттере нет хотя бы одной проверки, он нафиг не нужен, и неважно, что говорят об этом учебники по Яве.

То есть, когда тебе через полгода придётся вводить проверку или менять внутреннее представление,

*shrug* То есть, когда и через полгода проверку вводить не придется, ты оставишь в коде ненужные геттеры и сеттеры?

ты будешь переписывать весь использующий данный объект код?

О да, просто неподъёмный труд. Поставил private: и компилятор укажет тебе все места, в которых надо сделать replace.

> Очевидно, хорошие языки никому не нужны по другой причине.

Если тебе это очевидно - поведай и нам.

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

Дело в том, что его целесообразно сделать классом, хотя бы для того, чтоб иметь возможность переопределить + для него. Это очевидный случай, когда может потребоваться изменение реализации класса, даже такого простого.

Но мы хотим изменять его реализацию так, чтоб каково бы ни было это изменение, на использовании оно не отразилось бы.

Конечно, скажут многие, реализовать + так просто, что если бы были открытые поля x и y, все равно их убирать бы не пришлось. Это слишком ограниченный взгляд на происходящее, поскольку вам может понадобится добавить метод инвертирования точки относительно еденичной окружности-тогда полярные координаты рулят для внутреннего представления. Но пользователям ничего не нужно об этом знать.

>Поставил private: и компилятор укажет тебе все места, в которых надо сделать replace.

no comments :)

> no comments :)

Да ладно, не сдерживай себя.

> no comments :)

а что не так-то? или рефакторинг - это что-то очень-очень плохое? ;)

Фунциональность имеет свойство наращиваться, и если сегодня ты думаешь, что get() не нужен потому что там будет только один return, то через полгода у тебя появится новая функциональность, которая будет влиять на возвращаемые данные, и тебе уже придётся переностиь переменную в private: и писать для неё get(). Как результат сломанное ABI снизу вверх, за что пользователи твоей библиотеки с удовольствием тебя повесят :)

С get() всё проще: сегодня

int C::point() const
{
    return p;
}

Завтра

int C::point() const
{
    return p * scaling;
}

.

Если ты ГАРАНТИРУЕШЬ, что во всех версиях библиотеки достаточно public атрибутов вместо get/set, то можно get/set и не делать. Но я думаю что сколь-нибудь серьёзная библиотека не сможет такого гарантировать, и во вторых поддержания консистентности доступа к атрибутам во многих классах тоже важная деталь.

Естественно, я говорил о классах, которые имеют логику, и созданы ради какой-то функциональности, а не ради хранения переменных. Для переменно-помоек всегда использовались структуры с доступом по-умолчанию.

мы спорим ни о чем - я никогда поля классов не делаю public, а что касается структур - то тут не обойтись без изменений, но такое говорит прежде всего о неправильном проектировании - и без рефакторинга тогда не обойтись

>а что не так-то?

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

или рефакторинг - это что-то очень-очень плохое? ;)

Рефакторинг - это следствие кривого изначального проектирования. Исправление ошибки в проработке архитектуры.

>>мы спорим ни о чем

я прочитал всю тему и так и не понял о чём тут спорят. Третья страница, и уже авиационная тематика пошла. Типичный лоровский флейм :))

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

и поэтому структуры не имеют права на существование?

Рефакторинг - это следствие кривого изначального проектирования. Исправление ошибки в проработке архитектуры.

это прежде всего улучшение, а идеальной «архитектуры» при разработке большого проекта с наскока не добиться, тот же отказ от «сырых» структур может стоить весомого проседания в скорости работы

>и поэтому структуры не имеют права на существование?

А я про структуры нигде не говорю :)

это прежде всего улучшение

Угу. Только при плохой архитектуре через какое-то время вся работа над проектом будет заключаться в этих «улучшениях».

> Я же английского не знал, так что решил делать свой вариант, с подкидным дураком и женщинами лёгкого поведения :)

Я же английского не знал

Теперь понятно, почему не было «доступных» (видимо, доступных для понимая?) книг в Москве в 1990-1992г.

> А я про структуры нигде не говорю :)

хоть топик называется «Структура vs класс», я наверное забыл, что нахожусь на ЛОР и предмет спора может меняться :) как я уже говорил - я лично никогда поля не делаю публичными, да и наружу структуры не отдаю, но для внутреннего хранения - вполне, более того - в некоторых случаях выношу часть полей в отдельную структуру, и даже храню с помощью урезанного варианта смарт поинтера, когда хочу избежать ненужного копирования

Угу. Только при плохой архитектуре через какое-то время вся работа над проектом будет заключаться в этих «улучшениях».

это имеет отношение к тому, что даже в хороших проектах рефакторинг бывает нужен?

>а что не так-то?

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

Вот очень много таких, которые сильно задумываются и у них выходит bloatware & feature bloat. Неработающее. Потому что они думают о будущем, а не о том, что действительно нужно.

http://en.wikipedia.org/wiki/Worse_is_better

The idea is that quality does not necessarily increase with functionality. There is a point where less functionality («worse») is a preferable option («better») in terms of practicality and usability.

Кстати, это проблема исключительно C-подобного синтаксиса.

Предоставляют. Как минимум удобство отладки — breakpoint поставить можно на изменении атрибутов.

кто мешает поставить breakpoint на изменение самой переменной (области памяти)? и gdb, и оффтопичный отладчик такое давно умеют

Макконнелл негодует

геттеры ничем существенным не отличаются от прямого досутпа к данным. и никакой инкапсуляцией тут и не пахнет

клиентский код может свободно делать с данными Point что угодно, при этом сам класс может даже не узнать об их изменении

интересно, придут когда-нибудь светлые времена, когда эту чушь перестанут переписывать из книги в книгу? инкапсуляция - это не спецификаторы доступа, а разделение интерфейса и реализации

Не спорю - глупость городить вместо структуры класс с геттерами и сеттерами

слава ЛММ!

Он между прочим развивается, сборщик мусора даже будет

не будет. отклонили его в C++0x

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

тем, кто пишет такой код, куда полезней грамотно проектировать интерфейсы ;)

свойства не нужны, т.к. нарушают инкапсуляцию точно так же, как и геттеры/сеттеры

вот именно поэтому

>Теперь понятно, почему не было «доступных» (видимо, доступных для понимая?) книг в Москве в 1990-1992г.

Список доступной англоязычной литературы по ООП в Москве в 1990..1992гг в студию.

...

Впрочем, я полагаю, что ты - тот же самый фееричный анонимус, что в эти годы в Москве Интернет знал где искать...

>Вот очень много таких, которые сильно задумываются и у них выходит bloatware & feature bloat. Неработающее. Потому что они думают о будущем, а не о том, что действительно нужно.

Возможно. Но с таковыми я не сталкивался. А вот за теми, кто не умеет заглянуть хотя бы на несколько месяцев вперёд, говно подчищать приходится регулярно. Иногда - совершенно феерическое говно.

...

И, глядя на массу народа в этом топике, я понимаю, почему дела с софтом на этой планете обстоят столь ужасающе.