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

>Чем это объясняется?

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

>Вот смотрю сейчас на Qt и ужасаюсь. Куча функций состоит буквально из одной строчки

Одно не понятно, что вас так в этом ужасает? В чем проблема-то? Ну написано куча функций из одной строчки. И что? Зато весь код выглядит единообразно.

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

Ну например для Java SUN сам рекомендует дклать сеттеры/геттеры для все снаружи используемых переменных. Или Java тоже убогая? А что тогда не убогое?

>А что тогда не убогое?

D, например.

> > А поменять тип переменной не судьба?

Никак не судьба. Потому что в одном случае возвращалась статическая строка, в другом - результат работы другого класса.

А, строка в первом случае взялась из астрала? Ну понятно тогда. Да, инициализировать строку при создании класса нельзя.

> P.S. всех веб-программистов нужно в обязательном порядке учить писать на хаскеле

Сразу после того, как Хаскелл станет доминировать в web'е.

Русскому языку тебя обучили, а он не доминирует в web'e. Уверен, что в универе (если ты учился на матфаке) тебя учили не яве и не php.

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

Многие считают, что глобальные переменные в Си - это зло. И что нужно заворачивать их отдельно в структурки/етц, и дальше пропихивать стейт всюду, где нужно. И делать так нужно - всегда, чтоб было красиво и »на будущее« было »удобно«. Хотя это далеко не так — во многих случаях такой подход раздует код, усложнит поддержку. Да и предсказанное будущее редко сбывается.

Или ООП и забавная идея »всё есть объект«. Глупости всё это. Как и с обязательными геттерами/сеттерами. Особенно в случае QPoint'a.

C# и VB.NET

>А, строка в первом случае взялась из астрала?

Я же писал выше - грузилась из БД при инициализации объекта через ORM.

Однобокие подходы, особенно заученные по наветам авторитетов — это не истина в последней инстанции.

Безусловно. Но не стоит рассчитывать на свой либастрал, когда он даёт подобные проколы в отношении некоторых твоих собеседников. Когда я осваивал ООП, доступных «авторитетных книг» просто не существовало. Так что - всё только личным многолетним опытом, методом проб и ошибок, на широком спектре задач и языков.

> Когда я осваивал ООП, доступных «авторитетных книг» просто не существовало.

Не завирайся. Ещё скажи, что про ООП ты узнал во сне.

> во многих случаях такой подход раздует код, усложнит поддержку.

Примеры «таких случаев» можно в студию?

> Когда я осваивал ООП, доступных «авторитетных книг» просто не существовало.

Что, до начала 70х ООП осваивал? А зачем?!?

>Не завирайся.

Ну, опровергни меня, выдай хотя бы штук пять «авторитетных книг» по ООП в Москве в 1990..1992гг.

Ещё скажи, что про ООП ты узнал во сне.

Нет. Я по Страуструпу учил его. Но Страуструп не делал никакой акцентуации на геттерах/сеттерах. Ещё была книжка женщины какой-то, запамятовал уже. Всё. Других книг по ООП тогда в продаже не было. Интернета тоже ещё не было, кстати. Вот по Лиспу, например - были :) Или Форту. Навалом было литературы по Бейсику, Фортрану, PL/M, программируемым калькуляторам.

>Что, до начала 70х ООП осваивал?

Повторю вопрос как и своему оппоненту - назови список книг по ООП в продаже в Москве в 1990..1992 гг.

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

Вы что, ООП появилось с приходом C# и php5:)

Будешь давить на жалость и ссылаться на бедность?

>D, например.

May be конечно, я на D не писал, и только слышал о нем в пол уха... Но если D так идеален, то почему до сих пор основная масса проектов пишется на С++ и Java, ну и иногда на всяких решетках?

В жабе позволяют сохранить binary compatibility, это единственное ощутимое преимущество. В С++ не уверен, но думаю тоже.

А вообще ООП головного мозга, удваиваю.

Сокрытие данных дает больше гибкости (неизменный интерфейс, изменяемая реализация), а так же предотвращает неконтролируемое нарушение инварианта класса. Хотя конечно в самых простых случаях (QPoint) закрывать данные совсем не обязательно, так как совершенно лишено смысла.

Ну раз для общения с тобой бессмысленно ссылаться на доводы разума и давить на зравый смысл... :3

>Но если D так идеален, то почему до сих пор основная масса проектов пишется на С++ и Java, ну и иногда на всяких решетках?

Он пока в разработке и только-только набирает обороты.

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

1). простота изменения внутренней структуры объекта (?).

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

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

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

по всем пунктам кроме первого рад буду услышать контраргументацию (по первому пофиг).

> Но если D так идеален, то почему до сих пор основная масса проектов пишется на С++ и Java, ну и иногда на всяких решетках?

Во-первых, никому не нужны хорошие языки.
Во-вторых, у D пока ещё очень глючные компиляторы.

>1). простота изменения внутренней структуры объекта (?).

В том то и прикол, что нету ни какой структуры. Только куча переменных.

2).3)

Согласен

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

Тоже палка о двух концах. Вот типичный случай с глобальными настройками. В первом случае создал структуру, забил данными и передал её объекту. Функция одна, сигнал тоже один. А вот с set get непонятно, как такое реализовать. На каждый set сигнал вешать?

>Во-первых, никому не нужны хорошие языки.

Извините конечно, но бред несете! Если язык дает преимущества перед другими, существенные преимущества(делает разработку программ удобнее, быстрее, надежнее и т.п.) то от него не откажутся. Если язык не используют, значит он не лучше остальных в лучшем случае.

Ну а про языки у которых даже пока нету нормальных компиляторов, давайте пока помолчим. Вот допилят до вменяемого состояния там и поговорим.

>используют класс с доступом к переменным через функции (set, get).

да потому что цепепе( и всё что с него списывали) - кусок говна. различие доступа и геттеров - это уже признак отсутствия ооп. ООП это так:

obj fn [args]

или вот так

fn [objs/args]

а в cpp какая-то х-ня неведомая.

Ога, тогда расскажите нам почему Ada до сих пор не мейнстрим(оборонку и прочее не берём сейчас в расчёт). Там многое было ещё появления Явы и тем более Си с решёткой. И что? Стал использоваться широко? И с реализациями проблем нет. Тот же гнат классная штука. Но не нужно!
И не нужна Ада по той же причине, по которой не нужен CL - потому что хорошие языки не нужны. Побеждают языки простые, понятные(C, python) и языки с большим багажом библиотек(Java, C#). Плевать индустрия хотела на гибкость языка, плевать! Иначе бы CL давно был бы использован везде где только можно. А perl6 бы спонсировали огого. А ещё, вместо изобретения C#, могли бы просто сделать на базе гната Аду, но с С-подобным синтаксисом и прикрутить в качестве бэкенда какую-нибудь vm.

>Будешь давить на жалость и ссылаться на бедность?

Нет, буду ссылаться на то, что ты вообще не имеешь понятия о чём говоришь.

>Если язык дает преимущества перед другими, существенные преимущества(делает разработку программ удобнее, быстрее, надежнее и т.п.) то от него не откажутся.

От D и не отказываются. А если речь о популярности, то

Если язык не используют, значит он не лучше остальных в лучшем случае.

То лучшими языками являются Java, Си/Си++, PHP, C#, VB. А Haskell, LISP или OCaml - отвратительны :)

Получается, что критерий «качества» языка, как бы, с популярностью и используемостью не очень коррелирует.

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

>Побеждают языки простые, понятные(C, python) и языки с большим багажом библиотек(Java, C#).

А почему вы противопоставляете простоту с багажем библиотек и качественность языка. Простота и количество сторонних библиотек это один из критериев качественного ЯП. А вы рассматриваете какое-то сферическое качество в вакууме.

Действительно индустрии плевать на то что какой-то язык гибче или еще что-то, если на нем не удобно, а значит не выгодно писать софт. Ну вот на кой мне сдался например CL если для тех же плюсов у меня команда разрабов с 10 летним опытом, и вагон изученных и удобных библиотек? Что мне до гибкости языка, если кроме этого ничего нет?

Возьмем те же функциональные ЯП(Lisp, Haskel и т.п.). Какова ниша этих языков? Научная сфера? Ну так они там используются. Задачи построения логических цепочек(ХЗ как назвать задачи, где по сотням параметров делаются некоторые выводы)? И опять же там используются функциональные языки программирования. Но не предназначены они для написания прикладных программ. Ну хоть убейте.

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

небольшая подборка для тех, кто считает что геттеры и сеттеры имеют какое-то отношение к инкапсуляции.

Макконнелл негодует:«Не делайте данные-члены класса открытыми. Предоставление доступа к данным-членам нарушает инкапсуляцию И ограничивает абстракцию. Класс Point, который предоставляет доступ к данным:

float x;
float y;
float z;

__нарушает инкапсуляцию__, потому что клиентский код может свободно делать с данными Point что угодно, при этом сам класс может даже не узнать об их изменении. В тоже время класс Point, включающий члены:

float getX();
float getY();
float getZ();

void setX();
void setY();
void setZ();

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

Читайте классику:)

>Вот смотрю сейчас на Qt и ужасаюсь. Куча функций состоит буквально из одной строчки.

Уже же писали, что это сделано для единообразия.

Писать библиотеки для CL - одно удовольствие (по слухам), для D - другое (сам писал), для C++ - кошмар (тоже по собственному опыту).

Кстати, внезапно наткнулся: http://atariarea.krap.pl/x-asm/ :)

In 2005 there were some minor enhancements and bug fixes, as well as the whole assembler was rewritten from the x86 assembly language it was initially written in to the D programming language.

>создал структуру, забил данными и передал её объекту. Функция одна, сигнал тоже один. А вот с set get непонятно, как такое реализовать. На каждый set сигнал вешать?

Ты же объекту через метод структуру будешь передавать? Вот этот метод и есть сеттер, от названия ничего не меняется.

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

Так мне этого и не надо. x,y,z - координаты, которые ничем не ограничены. Кстати, почти у каждого Qt-класса есть двойник Private с публичными переменными. Ай-ай, как нехорошо.

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

Почему?

>Ты же объекту через метод структуру будешь передавать? Вот этот метод и есть сеттер, от названия ничего не меняется.

Логично, но ты не забывай, что сеттер один и только там, где он нужен. А вот если эту структуру заменить классом с кучей «сеттеров» и «геттеров»... В общем, количество кода вырастит в несколько раз точно.

>x,y,z - координаты, которые ничем не ограничены

Автор писал про какойто абстрактный класс, а Point приведён как просто пример. В любом случае публичных данных надо стараться избегать.

Почему?

Я написал класс, ты пользователь моего класса и используешь его для своей программы. Накой фиг тебе забивать голову тем, как там у меня всё реализовано? Проблем со своей программой не хватает?

Интерфейс класс должен быть таким, чтобы тому кто его использует не приходилось думать о внутреннем устройстве класса. Инкапсуляция - http://ru.wikipedia.org/wiki/%D0%98%D0%BD%D0%BA%D0%B0%D0%BF%D1%81%D1%83%D0%BB...

>А вот если эту структуру заменить классом с кучей «сеттеров» и «геттеров»... В общем, количество кода вырастит в несколько раз точно.

Согласен полностью. Тут как раз правильно объеденить схожие данные в структуру, а проверить их корректность можно уже в классе которому они передаются.

> А что тогда не убогое?

Common Lisp же! гуглить по «CLOS»

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

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

Накой фиг тебе забивать голову тем, как там у меня всё реализовано? Проблем со своей программой не хватает?

А я сложные классы и не рассматриваю. Мне достаточно того, что заменяет структуру.

>Громоздкий способ получается.

Угу. В Си++.

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

Так что никакие D никогда никому не будут нужны, потому что это тот же C++, вид сбоку, только без библиотек, без сообщества и без приличных реализаций.

> Нет, буду ссылаться на то, что ты вообще не имеешь понятия о чём говоришь.

А я таки буду ссылаться на бедность. Потому что в 90-92 интернет был. У тебя не было? Сам виноват. Литература по Simula и Smalltalk в начале 90х была. У тебя не было? Сам виноват!

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

А я сложные классы и не рассматриваю. Мне достаточно того, что заменяет структуру.

Структура есть структура. Не спорю - глупость городить вместо структуры класс с геттерами и сеттерами. Если ты конечно уверен, что в будущем в этот класс не добавится логики.

>А я таки буду ссылаться на бедность. Потому что в 90-92 интернет был. У тебя не было? Сам виноват. Литература по Simula и Smalltalk в начале 90х была. У тебя не было? Сам виноват!

Тебе не кажется, что ты перегибаешь? Скажем у меня небыло никакой возможности получить доступ в инет даже в 98-2000-ом. Да и на нужен был этот Smalltalk, если его компилятора было не найти, да и книги по нему тоже.

Почему все обсирают С++? Он между прочим развивается, сборщик мусора даже будет. ^) Всякий синтаксический сахар это дело третье, на сам язык особо не влияющее. Язык и синтаксис это немного разные вещи.

>Тем, что убогий с++ не умеет свойства.
Ничего он не убогий, свойства это вода. С++ это язык общего назначения, который всегда будет проигрывать более узкоспециализированным языкам.

>Потому что в 90-92 интернет был.

Угу. В Европе. И без браузера (Mosiac вышел в 1993-м) :)

...

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

Ты фееричен :D