1) Каждый элемент интерфейса класса (будь то открытая функция-член, друг, или открытое поле) накладывает некоторые ограничения на свое использование -- preconditions.
Например, не передавать отрицательных чисел в качестве аргумента, не передавать указатели на удаленную память, передавать в качестве параметра шаблона CopyConstructable и т.п.
2) При использовании интерфейса с требуемыми preconditions, объект всегда должен оставаться в согласованном валидном состоянии -- invariants.
3) При изменении preconditions задача разработчика интерфейса -- пересмотреть всех клиентов и оповестить их о том, что контракт изменился.
4) В изначальном примере с сеттерами/геттерами, preconditions сеттера гласят: "передавай любое значение". Т.е. совпадают с "preconditions" которые имеет открытое поле класса.
Из (4) следует, что никакой разницы с точки зрения корректности геттеры/сеттеры не добавляют.
Из (3) следует, что если вдруг диапазон допустимых значений придется ограничить, нам все равно придется перелопатить клиентский код -- убедиться в том, что он не нарушает новых preconditions, или поменять его, чтоб не нарушал. Сделать это несложно, как здесь уже говорили выше -- делаем поле класса закрытым, и компилятор находит нам все места, которые надо поправить.
Я считаю, что лучший future-proof вообще -- реализовать минимально-простое решение, удовлетворяющее сегодняшним требованиям, ну может еще завтрашним, если мы уже знаем, куда идем.
Как говорится, магистр Йода учит нас думать о будущем, но не в ущерб настоящему.
Re[2]: доступ к мемберам класса(getter'ы и setter'ы)
Здравствуйте, Alexander Poluektov, Вы писали:
AP>Из (4) следует, что никакой разницы с точки зрения корректности геттеры/сеттеры не добавляют.
А ты сам придумал прекондишн сетера и гетера? страно, и предумал же в свою пользу, молодец — толсто троллишь!
AP>Из (3) следует, что если вдруг диапазон допустимых значений придется ограничить, нам все равно придется перелопатить клиентский код -- убедиться в том, что он не нарушает новых preconditions, или поменять его, чтоб не нарушал. Сделать это несложно, как здесь уже говорили выше -- делаем поле класса закрытым, и компилятор находит нам все места, которые надо поправить.
Ухты, а я нажму в VA кнопочку и мне покажет все места использования за 5 секунд, а ты будешь час перекомпиливать и то не 1 раз. Да и ты представляешь что будет если ты пишешь миделваре, или кода тонны, и твоим модулем пользуються 10-20 программистов? Думаю врядли ты это представляешь.
— круты пацаны напишут асерт/варнинг/ексепшн + добавят к мануалу инфу, и получат профит, в виде делегирования своей работы на 10-20 человек.
AP>Я считаю, что лучший future-proof вообще -- реализовать минимально-простое решение, удовлетворяющее сегодняшним требованиям, ну может еще завтрашним, если мы уже знаем, куда идем.
это значит, что ты часто пишешь код не зная что получиться в результате
Тогда да оправдывает, скорость переписывания кода, без get|set гораздо быстрее
AP>Как говорится, магистр Йода учит нас думать о будущем, но не в ущерб настоящему.
Заставь дурака богу молиться он и лоб себе расшибет!
Когда я был студентом, я сдавал право одной очень милой женщине. Она была практикующим юристом, и я ожидал, что такой специалист меня сейчас будет гонять от и до по всему конспекту.
Она посмотрела на меня и, ничего не спрашивая, поинтересовалась:
— Оценку вам какую ставить?
— Э... Пять хотелось бы
— Отлично, — сказала она, и стала писать в зачётке
— А вы что, даже ничего спрашивать не будете? — удивился я.
Она оторвалась от заполнения зачётки, внимательно посмотрела на меня и сказала:
— Запомните, молодой человек, чем меньше вы знаете, тем более ценна я как специалист.
Эта фраза мне запомнилась на всю жизнь и больше я не страдал фигнёй во время занятий.
И сейчас самое время мне, уже доценту и одновременно практикующему проектировщику зданий, повторить то же самое:
Господа студенты, не учитесь, пожалуйста! Старайтесь как можно больше получить на халяву! Чем меньше вы знаете по окончании института, тем более ценен я как специалист и тем большую зарплату я могу потребовать за свои услуги!
я не волшебник, я только учусь!
Re[3]: доступ к мемберам класса(getter'ы и setter'ы)
Здравствуйте, IROV.., Вы много писали.
При сохранении выбранного Вами тона, это будет последний ответ Вам.
Постараюсь вытянуть из Вашего потока хамства технические вопросы.
Напомню изначальный пример:
class Class1
{
int value;
public:
void SetValue(const int v) { value = v; }
const int GetValue(void) const { return value;}
};
AP>>Из (4) следует, что никакой разницы с точки зрения корректности геттеры/сеттеры не добавляют. IRO>А ты сам придумал прекондишн сетера и гетера?
Нет, они следуют из приведенного фрагмента кода -- документированной спецификации нет, реализация доступна в месте объявления, следовательно либо реализация сама является спецификацией, либо код писал программист, не понимающий базовых механизмов, обеспечивающих корректность кода и его клиентов. Я предположил первое.
AP>>Из (3) следует, что если вдруг диапазон допустимых значений придется ограничить, нам все равно придется перелопатить клиентский код -- убедиться в том, что он не нарушает новых preconditions, или поменять его, чтоб не нарушал. Сделать это несложно, как здесь уже говорили выше -- делаем поле класса закрытым, и компилятор находит нам все места, которые надо поправить.
IRO>Ухты, а я нажму в VA кнопочку и мне покажет все места использования за 5 секунд, а ты будешь час перекомпиливать и то не 1 раз.
Не думаю, что у Вас есть технические аргументы в пользу приведенных цифр ("5 секунд" против "час и то не 1 раз"), а эмоциональные здесь не работают, игнорируем.
IRO>Да и ты представляешь что будет если ты пишешь миделваре, или кода тонны, и твоим модулем пользуються 10-20 программистов?
Да, представляю. Бываю по обе стороны баррикад.
В случае опубликованного middleware изменения контрактов должны решаться на уровне версионности. Почитайте, например, это: http://semver.org/
В случае внутреннего модуля, изменение клиентов для соответствия новой спецификации (или хотя бы явное оповещение об этом) считаю необходимой практикой: если я делаю изменение в открытом интерфейсе, и ломаю этим существующий код, то я и должен чинить поломанный код.
Если у меня есть SetValue, которая сегодня принимает любые целые значения, а завтра только четные числа, и у нее это 10-20 клиентов, то это моя проблема, когда завтра 10-20 программистов начнут приходить ко мне и спрашивать, что за ассерты/предупреждения/исключения они получают в существующем коде.
IRO>- круты пацаны напишут асерт/варнинг/ексепшн + добавят к мануалу инфу, и получат профит, в виде делегирования своей работы на 10-20 человек.
Привет крутым пацанам.
Re[4]: доступ к мемберам класса(getter'ы и setter'ы)
Здравствуйте, Alexander Poluektov, Вы писали:
AP>Здравствуйте, IROV.., Вы много писали. AP>При сохранении выбранного Вами тона, это будет последний ответ Вам.
AP>Постараюсь вытянуть из Вашего потока хамства технические вопросы.
AP>Напомню изначальный пример: AP>
AP>class Class1
AP>{
AP> int value;
AP> public:
AP> void SetValue(const int v) { value = v; }
AP> const int GetValue(void) const { return value;}
AP>};
AP>
Тебе дать определение троллинга??? или цепляние к словам? может это все такие простейший пример элюстрирующию проблематику?
а не реальный код, понятием которым ты и подменил сущьность.
AP>Нет, они следуют из приведенного фрагмента кода -- документированной спецификации нет, реализация доступна в месте объявления, следовательно либо реализация сама является спецификацией, либо код писал программист, не понимающий базовых механизмов, обеспечивающих корректность кода и его клиентов. Я предположил первое.
Ты всегда принимаешь все за чистую монету? Может это не код, а пример?
Что по твоему делает этот класс — с эпическим названием Class1? инкапсулирует value? возможно.
Но чаще это класический троллинг.
IRO>>Ухты, а я нажму в VA кнопочку и мне покажет все места использования за 5 секунд, а ты будешь час перекомпиливать и то не 1 раз. AP>Не думаю, что у Вас есть технические аргументы в пользу приведенных цифр ("5 секунд" против "час и то не 1 раз"), а эмоциональные здесь не работают, игнорируем.
Ололо, вперед качать VA, и просить руководство купить лицензию! ну или сделать как всегда
IRO>>Да и ты представляешь что будет если ты пишешь миделваре, или кода тонны, и твоим модулем пользуються 10-20 программистов?
AP>Да, представляю. Бываю по обе стороны баррикад. AP>В случае опубликованного middleware изменения контрактов должны решаться на уровне версионности. Почитайте, например, это: http://semver.org/
Это както относиться к вопросу? ты говоришь как оповестить _читающего_ юзера, а я говорю как оповестить _глупого_ юзера, глупый >>>> читающих
AP>В случае внутреннего модуля, изменение клиентов для соответствия новой спецификации (или хотя бы явное оповещение об этом) считаю необходимой практикой: если я делаю изменение в открытом интерфейсе, и ломаю этим существующий код, то я и должен чинить поломанный код.
Ололо, ты настолько грамотный что являешся специалистом во всех областях программирования, и конечно же знаешь как правильно собираються, и как они работают все модули проекта? — огорчу, чаще всего в таких грамотных системах на этапе Девелопинга, используют практику Интерфейсы плюс DLL(грубо говоря тебе даже не всегда дадут реализацию этого модуля), обяснять почему?
AP>Если у меня есть SetValue, которая сегодня принимает любые целые значения, а завтра только четные числа, и у нее это 10-20 клиентов, то это моя проблема, когда завтра 10-20 программистов начнут приходить ко мне и спрашивать, что за ассерты/предупреждения/исключения они получают в существующем коде.
Правильно прийдут, ты же ведь не напишешь в этом ассерте/предупреждении/исключении — краткую анотацию что не так, и ссылку на описание интерфейся в мануале, а зря.
И даже если и прийдут, это гораздо проще обьяснить новую политику партии чем сидеть и писать за них, как ты предложил выше.
И опять же в компаниях принято пользоваться(если это возможно) политикой depricated и рядом писать новый интерфейс — даже пусть он будет называться SetValue2.
А если это внутрение вопросы, то на очередном заседании решаються изменения к интерфейсу и все к этому готовы
IRO>>- круты пацаны напишут асерт/варнинг/ексепшн + добавят к мануалу инфу, и получат профит, в виде делегирования своей работы на 10-20 человек. AP>Привет крутым пацанам.
Передам, жаль редко встречаються в жизни )))
я не волшебник, я только учусь!
Re[5]: доступ к мемберам класса(getter'ы и setter'ы)
Здравствуйте, IROV.., Вы писали:
IRO>Здравствуйте, Alexander Poluektov, Вы писали:
AP>>Здравствуйте, IROV.., Вы много писали. AP>>При сохранении выбранного Вами тона, это будет последний ответ Вам.
AP>>Постараюсь вытянуть из Вашего потока хамства технические вопросы.
AP>>Напомню изначальный пример: AP>>
AP>>class Class1
AP>>{
AP>> int value;
AP>> public:
AP>> void SetValue(const int v) { value = v; }
AP>> const int GetValue(void) const { return value;}
AP>>};
AP>>
IRO>Тебе дать определение троллинга??? или цепляние к словам? может это все такие простейший пример элюстрирующию проблематику? IRO>а не реальный код, понятием которым ты и подменил сущьность.
ну итд, ваших примеров на sf.net хватает
так что, увыжаемый IROV aka yuriy_levchenko задумайтесь о том что вам люди сказали выше > AP>>Постараюсь вытянуть из Вашего потока хамства технические вопросы.
Re[2]: доступ к мемберам класса(getter'ы и setter'ы)
IRO>И сейчас самое время мне, уже доценту и одновременно практикующему проектировщику зданий, повторить то же самое:
Казалось бы при чем тут геттеры и сеттеры.
Но видимо с высоты практически спроектированных зданий(заметьте не кем попало спроектированных, а целым доцентом) оно виднее.
Шутка конечно, но с точки зрения программирования, для подтверждения высокого класса больше подходит обнародование размера детородного органа. Сразу понятно. А то — доцент.
Проектирование велосипедов для слепых жирафов
Re[6]: доступ к мемберам класса(getter'ы и setter'ы)
Здравствуйте, disasm, Вы писали:
IRO>>Тебе дать определение троллинга??? или цепляние к словам? может это все такие простейший пример элюстрирующию проблематику? IRO>>а не реальный код, понятием которым ты и подменил сущьность.
D>чувствуется рука уверенного в себе человека D>тогда далеко ходит не будем уважаемый yuriy_levchenko D>и что бы остудить ваш пыл D>вы всем постараетесь обьяснить вот этот код D>http://axe-engine.svn.sourceforge.net/viewvc/axe-engine/src/Lib/PropertySystem/String.cpp?revision=86&view=markup
Код нужен для симуляции ORM между сервером и клиентом, также есть мапинг этого в различные скрипты (Python, Lua)
D>
Ты об этом? По подробней, что тебя смущает.
D>ну итд, ваших примеров на sf.net хватает
Хватает.
D>так что, увыжаемый IROV aka yuriy_levchenko задумайтесь о том что вам люди сказали выше
Извини, поищи еще.
я не волшебник, я только учусь!
Re[3]: доступ к мемберам класса(getter'ы и setter'ы)
Здравствуйте, robin_of_the_wood, Вы писали:
___>Казалось бы при чем тут геттеры и сеттеры. ___>Но видимо с высоты практически спроектированных зданий(заметьте не кем попало спроектированных, а целым доцентом) оно виднее. ___>Шутка конечно, но с точки зрения программирования, для подтверждения высокого класса больше подходит обнародование размера детородного органа. Сразу понятно. А то — доцент.
Толсто
Спасибо всем за интересное эмоциональное обсуждение.
Мне лично больше всего понравилась позиция Desert Dragon. Геттеры и сеттеры писать неприятно, а потому и нужно придерживаться данного стиля (геттеры/сеттеры для открытых полей класса (не структуры)), чтобы каждый раз, когда приходится их писать, задумываться о том, как можно было бы организовать интерфейс класса более изящно.
Геттеры/сеттеры могут оказаться полезными, когда мы захотим адаптировать под наши нужды другой класс, у которого мемберы называются по-другому, хотя по сути интерфейса он не очень отличается от нашего.
Кстати, по поводу читабельности. Как известно, любая функция (без throw()) потенциально может быть источником исключений. Потому, если поле имеет встроенный тип, то прямое обращение к нему может несколько выиграть в читабельности за счёт этого. Но, правда, мы должны при точно знать, что имеем дело со встроенными типами
To be is to be the value of a variable
Re[3]: доступ к мемберам класса(getter'ы и setter'ы)
Здравствуйте, DesertDragon, Вы писали: DD>Какие-то внутренние вспомогательные классы относящиеся к внутренней реализации модуля могут иметь методы get/set, если у них это явная основная функция. Поэтому я и писал про "большинство", а не "все".
Если какой-нибудь интерфейсный метод принимает 20 штук параметров, их естественно поместить в структуру. А отсюда уже недалеко и до простого класса с геттерами и сеттерами. И почему класс Account не может быть параметром или результатом интерфейсных методов?
DD>Да и то, указанные данные по-хорошему должны хранится в реляционной базе данных, а не в классе Account.
Храниться — да, а оперировать в памяти удобнее структурой. К тому же бизнес-логика сейчас редко работает с БД напрямую, как правило через ORM.
Кроме БД есть экранные формы, шаблоны отчётов, различные экспортные представления. Логично, что все они будут оперировать с одной и той же структурой — класом Account, а не друг с другом или с БД. Другими словами, не всегда класс Account может быть чисто внутренним делом модуля.
Re[4]: доступ к мемберам класса(getter'ы и setter'ы)
Здравствуйте, andrey_nado, Вы писали:
_>Если какой-нибудь интерфейсный метод принимает 20 штук параметров, их естественно поместить в структуру. А отсюда уже недалеко и до простого класса с геттерами и сеттерами.
20 параметров — это уже получается загрузка данных из БД. Значит идем дальше.
DD>>Да и то, указанные данные по-хорошему должны хранится в реляционной базе данных, а не в классе Account. _>Храниться — да, а оперировать в памяти удобнее структурой. К тому же бизнес-логика сейчас редко работает с БД напрямую, как правило через ORM.
Вот мы и подошли к новому руслу дискуссии
То что обсуждаемый анти-паттерн является одной из основ ORM, не о нем хорошо говорит, а об ORM плохо. Еще одно доказательство что ORM, это болото современного программирования, к кошерному ООП отношения не имеет так же как и гет/сет.
_>Кроме БД есть экранные формы, шаблоны отчётов, различные экспортные представления.
GUI для ввода данных и отчетов — это как раз тот самый случай, когда гет/сет в классе это основная функция класса.
А экспортные представления, это разве уже не БД ?
Re[5]: доступ к мемберам класса(getter'ы и setter'ы)
DD>То что обсуждаемый анти-паттерн является одной из основ ORM, не о нем хорошо говорит, а об ORM плохо. Еще одно доказательство что ORM, это болото современного программирования, к кошерному ООП отношения не имеет так же как и гет/сет.
А что за анти-патерн?
ORM — болото? если с точки зрения asm то да, да и если так судить то все фреймворки, миддлваре это болото.
что такое кошерное ООП?
ORM (англ. Object-relational mapping, русск. Объектно-реляционное отображение) — технология программирования, которая связывает базы данных с концепциями объектно-ориентированных языков программирования, создавая «виртуальную объектную базу данных».
я не волшебник, я только учусь!
Re[6]: доступ к мемберам класса(getter'ы и setter'ы)
Кстати похожие на на нашу дискуссию доводы с обеих сторон.
IRO>что такое кошерное ООП?
То, которое приводит к упрощению, а не усложнению архитектуры. И которое не вводит заблуждение, скрывая существенную сложность.
Можно даже попробовать определить какой-нибудь простой тест на кошерность, например:
Если после применения ООП, кода не стало меньше или какая-либо его часть стала менее понятна или производительность упала — значит это не кошерный ООП.
Re[7]: доступ к мемберам класса(getter'ы и setter'ы)
DD>Кстати похожие на на нашу дискуссию доводы с обеих сторон.
Значит не все так плохо
IRO>>что такое кошерное ООП?
DD>То, которое приводит к упрощению, а не усложнению архитектуры. И которое не вводит заблуждение, скрывая существенную сложность.
ORM разве не делает это?
Просто понимаешь, многие люди которые повидали на своем свете, начинают гнать на языки/техники/решения высокого уровня, только потому что они не могут туда воткнуть "asm"(или еще чтото), но они никогда не задумываються а оно надо?
Конечно бывают кривые реализации, на которые обычно и аппелируют.
И естествено что этим "фламастером" нельзя разрисовать весь мир, тут нужно всегда смотреть, на 100% ли процентов удовлетворяет это решение, твоим запросам? И если нет, то лучше не связываться.
DD>Можно даже попробовать определить какой-нибудь простой тест на кошерность, например: DD>Если после применения ООП, кода не стало меньше или какая-либо его часть стала менее понятна или производительность упала — значит это не кошерный ООП.
"Производительность упала", это не критерий ООП, почти все Патерны вводять упрощение кода, за счет потери в производительности.
И это нормально.
я не волшебник, я только учусь!
Re[5]: доступ к мемберам класса(getter'ы и setter'ы)
Здравствуйте, Desert Dragon, Вы писали:
DD>GUI для ввода данных и отчетов — это как раз тот самый случай, когда гет/сет в классе это основная функция класса.
Ну то есть вы согласны с тем, что существуют классы — публичные! — у которых основная функция — хранить данные и предоставлять интерфейс гет/сет? Я только про это и говорил.
Re[6]: доступ к мемберам класса(getter'ы и setter'ы)
Здравствуйте, andrey_nado, Вы писали:
DD>>GUI для ввода данных и отчетов — это как раз тот самый случай, когда гет/сет в классе это основная функция класса.
_>Ну то есть вы согласны с тем, что существуют классы — публичные! — у которых основная функция — хранить данные и предоставлять интерфейс гет/сет? Я только про это и говорил.
Отнюдь
Это будут внутренние классы. Публичный класса максимум может предоставлять базовый интерефейс, с методами вида GetData/SetData. А не доступ к конкретным полям.
Re[7]: доступ к мемберам класса(getter'ы и setter'ы)
Здравствуйте, Desert Dragon, Вы писали:
DD>Отнюдь DD>Это будут внутренние классы. Публичный класса максимум может предоставлять базовый интерефейс, с методами вида GetData/SetData. А не доступ к конкретным полям.
А как GUI достучиться до внутрених классов?
Гдето ты подменил понятие.
В бизнес логике, и всяких адаптерах, get|set это нормальная практика