C++ getters & setters

на тот что могут попытаться списать отрицательную массу. а еще могут переместить отрицательную массу.

так вот оно чё, Михалыч, а я то думал что списывают и перемещают товары, а не масссы

> защиты от дурака всё равно не существует

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

ответ - никак

Во-первых, твоя структура уже и не структура в обычном понимании (т.е. не POD-тип). Во-вторых, ты по-умолчанию предполагаешь, что никаких ограничений на тип не наложено. А если для программы корректны лишь точки с положительными координатами? point( -1, -1 ) - вот и испортили точку.

> ну и нафиг тут аксессоры?

Нафиг тут вообще проверка? goods сам должен не допускать отрицательного веса.

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

перемести мне 20 объектов манной каши, уважаемый

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

Как же будешь реализовывать инвариант класса без сеттеров или изменяемые объекты - еще худшее зло, чем аксессоры?)

>В свою очередь реализация класса Point может использовать для представления, например, радиус и угол, а методы int x(), void set_x(int) останутся.

Хороший, убедительный анонимус.

Во-первых, твоя структура уже и не структура в обычном понимании (т.е. не POD-тип)

а структура может является POD?

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

кто Вам сказал что (-1, -1) не валидная точка? :)

перемести мне 20 объектов манной каши, уважаемый

а в чём проблема?

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

Как же будешь реализовывать инвариант класса без сеттеров или изменяемые объекты - еще худшее зло, чем аксессоры?)

давайте к конкретным вещам переходить, приведите кусочк кода иллюстрирующий Вашу мысль

товар весовой ибо

ога :)

у Вас так принято - берёте и на складе потрошите товары? или всё же сначала списываете со склада, а там уже вивисекцию производите?

или, ОМГ, у Вас манная каша лежит большой кучей посреди/в углу склада?

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

уймись

аргументы кончились? :)

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

по-моему кое-кто путает продажи и склад

даже развес приезжает в мешках, или у Вас таки манная каша лежит большой кучей посреди/в углу склада?

То, что имеет состояние и поведение.

> аргументы кончились? :)

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

даже развес приезжает в мешках

развес приезжает в килограммах - поэтому мешки на приходе всегда взвешивают.

>То, что имеет состояние и поведение.

Почему же точка на декартовой плоскости не подходит?

Так. А можно коротким русским языков: в чем проблема то геторов и сетеров? И чем они от property отличаются?

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

Делать проверку в конструктор товара, либо в методе добавитьТовар контейнера товаров.

Зачем тебе загонять _все_ свои точки в один квадрант? Особенно в середине разработки проекта. Точка на плоскости - это точка на плоскости и ей должно быть всё равно, в какой части плоскости она находится. Проверками должна заниматься вышележащая сущность.

Какое поведение обеспечивает твоя точка? Кстати, я упомянул состояние и поведение, но забыл ещё, что очень важное свойство объектов - идентичность.

>а структура может является POD?

Как раз под структурой обычно понимают POD, потому что между struct и class особых различий нет. Можно объявить struct с конструкторами, деструкторами, отнаследоваться от кучи интерфейсов и т.д. Но это как-то это уже не похоже на структуру, которая пришла из C, а больше смахивает на класс. Ты вот посоветовал голую структуру, а потом сам же повесил конструктор нетривиальный.

кто Вам сказал что (-1, -1) не валидная точка? :)

Жизнь. Представь, что на вход поступает массив точек из первого квадранта и ты хитроумным методом их обсчитываешь в программе. И тут на определенном наборе данных выясняется, что алгоритм не работает. Какой-то явный бред на выходе. Начинаешь дебажить, видишь, что иногда прилетают точки с отрицательными координатами, которые все портят. Как так? Откуда? Ты же контролируешь входные данные. Приходится отыскивать все места, где идет какая-либо работа с точками и вставлять проверки. В итоге ты конечно баг локализуешь, но бухнешь времени. А простейший сеттер на две строки избавил бы тебя от мучений. Тут у тебя мелькает мысль: «надо было слушать анонимусов, а не дрочить на ту статью». И проверки нельзя убирать - вдруг на других данных еще что-нибудь выскочит - не расставлять же заново. Зато сеттер не использовал, следовательно, с дизайном все в порядке.

> Так. А можно коротким русским языков: в чем проблема то геторов и сетеров?

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

В C++ появится (в gcc есть) auto, что несколько упростит ситуацию с локальными переменными.

> В C++ появится (в gcc есть) auto

заодно есть еще в icc, msvc

>В плюсах у структур есть конструкторы, в общем-то

Структуры - те же классы, просто с дефолтным public. Так что есть ли они там это ещё вопрос.

> Так что есть ли они там это ещё вопрос.

есть, POD никто не отменял

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

> они мешают рефакторить код, для тех, у кого рефакторинг занимают большую часть работы, - это важно

Хм. Это интересно. Почему?

> Хм. Это интересно. Почему?

все написано в статье, на которую тут часто ссылаются :) как по мне - бред, автору стоит поучится у писателей С-ых библиотек, вот там и стабильность, и скорость работы, и нет потерь времени на всякого рода фетешизмы, и нет раздувания кода во имя многочисленных паттернов

ЭЭЭ... Это статья - сексуальные страхи автора?

> ЭЭЭ... Это статья - сексуальные страхи автора?

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

>Зачем тебе загонять _все_ свои точки в один квадрант?

Если во всей программе, я только с ними (точками первого квадранта) работаю и выход за его пределы - ошибка, то это вполне нормально.

Особенно в середине разработки проекта.

Да можно и в начале. Разницы-то нет. Ты либо контролируешь инварианты в сеттерах, либо в конструкторе в случае иммутабельных объектов. Иммутабельные объекты часто неприемлемы. Середина проекта для жизненности, потому что разработка обычно не заканчивается сдачей первой версии, а только начинается. Новые фичи, уточнения уже умеющихся, баги. Вот где люди, не использующие аксессоры, порадуются. Впрочем, подозреваю, что таких людей нет.

Проверками должна заниматься вышележащая сущность.

А вот и нет. Корректность своего состояния должен отслеживать сам объект, а не все, кто его используют. Вместо модели «мы всегда работаем с валидными объектами» ты предлагаешь модель «никогда нельзя гарантировать, что используемый объект валиден» и каждый раз при его использовании, надо проверять, не косячный ли он. Такие люди проектируют MFC и вводят странные методы AssertValid.

в плюсах нативных property нет

> в плюсах нативных property нет

Нет. Только это синтаксический сахар. Методов вполне хватит.

Да, мне не нравится идеалогия плюсов всё называть методами. Мне больше нравится сигналы/действия/свойства.

Но так получилось, что тут все в одной каше. Причем хуже от этого сильно не стало, только голову надо больше нагружать

есть, но он для QObject. быть может я к этому приду, но пока решил воздержаться

Как не нарушать инкапсуляцию, не пользоваться геттерами/сеттерами и спасти котят?

радостно воспользоваться сеттерами и не беспокоиться о котятах - с ними всё будет хорошо

обрати внимание - я не возражаю против их использования: я возражаю против проектирования от реализации, а в данном случае интерфейс вполне себе предполагает у точки наличия проекций на x и y

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

>Суть же геттера именно в том, что он исходит от реализации => априорное зло.

Суть геттера в том, что он предоставляет свойство на чтение. Это часть интерфейса класса. Ты можешь спроектировать интерфейс, нарушая инкапсуляцию, а можешь, не нарушая. Это никак не связано с аксессорами.

Сеттеры же вобще часто можно упразднить сделав объекты иммутабельными.

А часто нельзя.

Для самого C++ qt property по барабану. это нужно для meta type, а это уже из области «динамических языков»

> хотя да, в данном случае я бы воспользовался структурой. исходя из принципа KISS, так сказать

И чем же структура лучше?

сахар не сахар - но писанины меньше

Не поспоришь. Такой сахор можно было бы и добавить, как сделали это в том же obj-c

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

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

стабильность? скорость работы? нет потерь времени? я завидую тебе, живущему в идеальном мире

И чем же структура лучше?

тем, что в данном случае её достаточно: архитектура должна быть гибкой, но не более необходимого

> тем, что в данном случае её достаточно: архитектура должна быть гибкой, но не более необходимого

Достаточно для чего? Для локального описания точки? Структуры достаточно только тогда, когда либо ее поведение произвольно, либо ее использование ограничено малым участком, где можно ввести соглашение, которое все прочитают (и то это оправдано либо для ускорения разработки, что не есть гуд, либо для оптимизации, что часто сомнительно)

что за либа, если не скерет?

> последняя сишная библиотека, с которой я работал

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

я завидую тебе, живущему в идеальном мире

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

А как к ним достучаться потом, ведь геттеры/сеттеры - зло?

а у тебя классы всегда - тупо агрегаторы своих полей? с доступом наружу через геттеры/сеттеры, и никак иначе? и про проектирование ты вообще сегодня в первый раз услышал - про абстракцию данных там, инкапсуляцию, слои абстракции, недопущение утечки абстракций между слоями?

как печально

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

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

Для вас программист гений, который помнит всегда и все?