Простой код

[Igors]

Добрый день

Всякий раз когда я захожу в "стили" - мое сердце радуется. Вот напр сегодня пришлось рисовать делегатом, вот структура (немного подрезал чтобы легче читать)

Код

C++ (Qt)
class Q_WIDGETS_EXPORT QStyleOptionViewItem : public QStyleOption
{
public:
...
    Qt::Alignment displayAlignment;
    Qt::Alignment decorationAlignment;
    Qt::TextElideMode textElideMode;
    Position decorationPosition;
    QSize decorationSize;
    QFont font;
    bool showDecorationSelected;
...
    ViewItemFeatures features;
 
    QLocale locale;
    const QWidget *widget;
...
    QModelIndex index;
    Qt::CheckState checkState;
    QIcon icon;
    QString text;
    ViewItemPosition viewItemPosition;
    QBrush backgroundBrush;
...
};

Отак от! Позвольте, но почему все public? Где геттеры/сеттеры, это же "азы грамотности"! А какие там замечательные свитчи!! Цитировать здесь не выйдет, так они велики! И с поддержкой новых версий "option" - тоже интересно.

"Простое" объяснение - ну это, мол, редкое исключение, а может и просто не доделано, скоро исправят. Не лезет ни в какие ворота. Такого кода немало - одни стили чего стоят. И никаких шагов к переделке не наблюдается, даже намеков.

А может это нормально, и ООП вовсе не везде рулит? Как Вы считаете?

[Bepec]

Вариант 3 выбрал.
Использовать или не использовать рекомендации и стили это решение каждого. При поддержке кода с разными библиотеками, платформозависимыми решениями ООП часто невозможно использовать - те библиотеки о нём не знают

Сеттеры и геттеры это конечно прекрасно, но только в приведённом вами коде, класс представляет собой скорее контейнер для данных, нежели самостоятельный объект.

PS зачем делать сотни геттеров и сеттеров, если всё и всегда должно быть доступно? Геттеры и сеттеры позволяют настраивать доступ, а в данном случае это не нужно.

[_Bers]

Позвольте, но почему все public? Где геттеры/сеттеры, это же "азы грамотности"!

Нет, это не азы грамотности.
Азы грамотности - понимать смысл действий.

Сеттеры ради сеттеров не нужны.

А какие там замечательные свитчи!! Цитировать здесь не выйдет, так они велики!

Если речь о бизнес коде, то чем он проще, тем лучше.

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

А может это нормально, и ООП вовсе не везде рулит? Как Вы считаете?

ООП рулит и педалит.

[Igors]

Нет, это не азы грамотности.
Азы грамотности - понимать смысл действий.

Бесспорно, но расплывчато 

Не раз замечал, что набор удачных классов получается когда... есть какая-то "низкоуровневая основа". Хоть тоже Вындоуз: есть базовый набор С ф-ций API - и пожалуйста, из них можно налепить массу "ООП-оболочек". 

[Old]

Не раз замечал, что набор удачных классов получается когда... есть какая-то "низкоуровневая основа". Хоть тоже Вындоуз: есть базовый набор С ф-ций API - и пожалуйста, из них можно налепить массу "ООП-оболочек". 

Не думаю, что дело в низкоуровневой основе.
На одной и той же основе можно написать как удобный набор классов, так и сильно наоборот.
Для "Вындоуз" есть хороший пример плохой реализации под названием MFC.

[_Bers]

Бесспорно, но расплывчато 

Все очень просто: у каждого действия есть конкретный смысл.
Каждое действие обладает обоснованной необходимостью.

Если вы решили написать сеттер, значит вы точно понимаете, зачем вам это нужно.
А не просто "потому что так пишут в книжках для новичков".

Не раз замечал, что набор удачных классов получается когда... есть какая-то "низкоуровневая основа". Хоть тоже Вындоуз: есть базовый набор С ф-ций API - и пожалуйста, из них можно налепить массу "ООП-оболочек". 

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

Дизайн winapi не зависит от языков программирования,
а сама библиотека имеет порты на большинство из них.

Если бы winapi было оопнутым, тогда с ним невозможно было бы работать программистам,
которые пишут на процедурных языках, например.

А так оно без проблем портируется на большинство ЯП.

[Igors]

Если вы решили написать сеттер, значит вы точно понимаете, зачем вам это нужно.
А не просто "потому что так пишут в книжках для новичков".

И для "не новичков" тоже.

Пример: QPoint (QPointF, QVector3D и.т.п). Я считаю что его геттеры/сеттеры (x(), setX() и.т.п.) только путаются под ногами. Вот ответы которые я получал в прошлом. Дословно конечно не помню но смысл такой

1) "x" может быть чем-то другим.
Не может т.к. есть метод rx() возвращающий ссылку на int

2) Вот посмотрел вызовы setX и сразу видишь все изменения этой переменной.
Неправда, подавляющее большинство изменений QPoint (если не все) выполнятся оператором =

3) Ой, ну что тебе, трудно написать те скобки, что ли? Разводишь тут... (недовольсво) .
Да, трудно, если плотно работать. Вот простенькая формула в "нормальной" записи

Код

C++ (Qt)
c.x = a.y * b.z - a.z * b.y;
c.y = a.z * b.x - a.x * b.z;
c.z = a.x * b.y - a.y * b.x;
 

С геттерами/сеттерами это раздувается вдвое, а если текст еще и "несимметричный"...

4) Лучше всегда (сразу) писать правильно, это придумали люди "не нам чета"....
Это я не могу прокомментировать  

А что по этому поводу думают академики?  

[_Bers]

Пример: QPoint (QPointF, QVector3D и.т.п). Я считаю что его геттеры/сеттеры (x(), setX() и.т.п.) только путаются под ногами. Вот ответы которые я получал в прошлом. Дословно конечно не помню но смысл такой
С геттерами/сеттерами это раздувается вдвое, а если текст еще и "несимметричный"...

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

4) Лучше всегда (сразу) писать правильно, это придумали люди "не нам чета"....
Это я не могу прокомментировать  

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