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

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

В качестве решения например можно
- помещать в секцию public только константные методы, а состояние класса задавать в конструкторе
- писать классы без переменных-членов (но тогда нарушается положение ООП о наличии в классе данных)

Какие еще есть решения у этой проблемы? Есть ли какие-то общепринятые подходы? 

В качестве примера можно привести такие классы



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

Это сообщение отредактировал(а) iipetrov - 21.5.2013, 10:56

Жизнь создает проблему - необходимо ее поддерживать, иначе умрешь...

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

Это не проблема - это аксиома.   

  Суть функции члена это изменение состояния объекта. Иначе функциональщина получается какая-то.

Этот ответ добавлен с нового Винграда - http://vingrad.com

Этот аргумент скрыт от программиста, если он и есть... Программисту С++ не важно как реализуется на низком уровне.

Статический метод не зависит от данных класса. 
Константный метод зависит от данных класса, но не меняет их.
Не константный метод делает с данными класса что угодно.

Поэтому гарантирует одинаковый выход при одинаковом входе только статический метод. Исключение - случай когда все методы константные, или когда вообще нет данных.

Где конкретно у меня написана глупость?

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

Еще как отличаю. Я ничего еще про экземпляры не говорил. Это отдельная проблема.
Не надо цепляться к словам. Имелись в виду именно данные экземпляра класса.

Это сообщение отредактировал(а) iipetrov - 21.5.2013, 13:38

iipetrov, код у тебя не C++, а  C# или Java.
Не статический метод может делать с полями класса что угодно, но это не значит что он должен это делать.
Обычно перед объявлением метода описывается, что он делает - и он должен делать именно это.
При оформлении этих комментариев по специальным правилам из файла исходников можно создать файл документации.
Пользователю твоего класса прочитавшему твою документацию, должно быть ясно что метод делает. А про private-поля он не должен думать.

Юзеру надо постоянно помнить в каком же состоянии находится экземпляр класса. А состояние именно в private-полях (то есть юзер фактически не знает его). Это рано или поздно приведет к ошибкам.
К тому же сплошь и рядом классы плохо документируются, и даже исходник класса отсутствует.


Это сообщение отредактировал(а) iipetrov - 21.5.2013, 13:43

Если не цепляться, то не понятно о чем Вы говорите.

Какая?

В программе есть множество экземпляров, которые вроде бы представляют одно и то же, а на самом деле совершенно различны. Это тоже может привести к ошибкам.

Это сообщение отредактировал(а) iipetrov - 21.5.2013, 13:48

Вы всетаки разберитесь, что такое класс, а что такое его экземпляр. И чем они отличаются. Хотя бы на интуитивно понятном примере класса User, у которого, к примеру, есть атрибуты login и pswd.
Или если Вы это понимаете, то я не понимаю про какие ошибки Вы говорите. Приведите пример.

Паттерн Singleton не зря же придумали. Это попытка решить описанную проблему ООП.

Это сообщение отредактировал(а) iipetrov - 21.5.2013, 14:01

Классы без полей - это экзотический случай, у нормальных классов есть хотя бы одно поле, и это никак не нарушает парадигму ООП - где-то состояние объеков же надо хранить, без этого никак.
А вот если ты не пишешь документацию (хотя бы давая говорящие имена методам), а тем более изменяя метод, и не отражаешь это в документации - это действительно нарушение принципов ООП.
Относительно лишних полей:



Это сообщение отредактировал(а) math64 - 21.5.2013, 14:06

math64, 
private-поля никогда не отражаются в документации. 
public-метод может выполнить свою функциональность, описанную в документацию, и поменять private-поля. 
Это может отразится на работе всех остальных методов класса.

Это сообщение отредактировал(а) iipetrov - 21.5.2013, 14:13

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

Добавлено через 1 минуту и 23 секунды

Вот это и должно быть отражено в документации.

То что экзепляры класса разные? Это не проблема - это свойство любого объекта. Сложно в мире найти хотя бы 2 одинаковых объекта.
Singleton придумывали для того, чтобы в системе гарантированно был один экземпляр данного класса. Вопрос его использования в проектах - отдельная тема для обсуждения.

Так что ТС не нравиться, что плохо документируют классы и он не знает, когда что поменяется?
Или тут что-то другое?)

Обычно такие методы имеют определенные правила именования. Они, чаще всего, будут начинаться с open, set, add, del, close или любого друго глагола, который явно будет указывать, что внутреннее состояние указанного объекта поменяется.

Вас имхо тролят, господа
  

  На самом деле в словах ТС есть доля правды. Сложные объекты как правило это плохие объекты. Документирование это, конечно, хорошо, но речь не о том, чтобы код писать аккуратно, а чтобы масштабирование приводило хотя бы к линейному росту числа ошибок. Классический подход основанный на наследовании и большой иерархии классов приводит таки к тому, что число ошибок начинает расти заметно быстрее чем количество строк кода. Как раз по той причине, что забывается где и что меняется.
  Я сам склоняюсь к тому, чтобы масштабирование делать за счет агрегации. Хотя кучу небольших классов сложнее увязывать между собой, но их проверка и тестирование многократно проще. Класс без полей это уже не ООП вовсе, но при небольшом количестве полей работа класса становиться достаточно прозрачной.

Этот ответ добавлен с нового Винграда - http://vingrad.com

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

iipetrov, все Ваши аргументы — это аргументы простого кодера. Вы берете свойства самого языка, паттерны и концепции, варите это все в собственном соку и выставляете претензии. Это бред, не имеющий практического применения.
Если бы хоть один нормальный проект в качестве примера создали/разобрали, то этой темы бы просто не возникло.

Математика исходит от природы, а не природа от математики. Программирование идет от практики, а не практика от программирования. Если бы Вы смогли это понять, то решили бы и все свои разногласия.

Это же отлично. Это же потрясающе! Можно создавать динамические и даже самообучающиеся программы!
Или Вы кроме конечных автоматов больше других структур вообразить не можете?

А какие это "непредсказуемые"? Программа выдаст мне строку вместо числа? Выключит компьютер вместо сохранения файла? Это уже точно бред. 
Если программа непредсказуема — то это фейл ее создателя. Если на вход ожидают данные с конкретными требованиями, то ничто не мешает эти данные по этим требованиям проверить. 
Программа будет настолько предсказуемой, насколько таковой Вы ее сделаете. 

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

Добавлено @ 15:16

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

Это сообщение отредактировал(а) iipetrov - 21.5.2013, 15:24

Автор, как ты видишь класс, являющийся абстракцией буфера, заполняемого пользователем с клавиатуры?
Какой метод ты бы использовал, чтобы программист "мог положиться" на результат работы метода GetAverage(), возвращающего среднее арифметическое всех значений находящихся в буфере. Кстати размер буфера тоже задаётся пользователем и не известен на момент компиляции.

Это сообщение отредактировал(а) NoviceF - 21.5.2013, 20:42

Вот смотри, в примере вызывается один метод add, а результат интерпретируется как вызов другого getA. Т.е. результат метода add всегда на одинаковых входных данных одинаков, значение будет увеличиваться на входной параметр. 
Как можно еще понимать результат вызова метода "прибавить" ? ИМХО, значением на которое увеличится (уменьшится при отрицательном).

Как бы ты стал тестировать работу метода add ?

ну что вы накинулись, господа. человек озвучил реальную (впрочем, избитую) проблему. проблему не только ООП, а императивного программирования вообще.

  


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

здесь проблема лишь в сложности контроля состояния. в ООП определенность поведения объекта это семантика его класса. в не ООП - это тоже семантика, но не класса, а фрагмента программы. например, псевдослучайного генератора rand()


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


есть такое.
это шаг в сторону функционального программирования. ФП считается более надежным именно из-за отсутствия побочных эффектов.
везде, где можно использовать функциональный подход, его полезно использовать. stl и boost - хорошие образцы такого подхода в С++

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

Добавлено через 7 минут и 46 секунд
ЗЫ: для контроля непротиворечивости фрагмента программы (класса, функции, библиотеки) используют контроль части состояния, которая должна оставаться неизменной в процессе или после выполнения операций (т.е. логических выражений относительно текущего значения переменных). это называется проверкой инваранта (класса, функции, цикла). во всяких assertах и внешних тестах фактически проверяются инварианты. 

iipetrov, да Вы просто некачественную книжечку почитали на эту тематику...
Скажу Вам так. Ваши проблемы связанны с Вашим личным непониманием и не имеют связи с реальным миром.
Аргументы Ваши логически правильные, но они не доказывают существование оспариваемой проблемы, это самодостаточные утверждения, даже не являющееся аргументами.

Верно.

Плохой программист.

Плохая программа.

Вот и все.  Все, что вы пишите — это ошибки, которые может допустить программист. Но важно заметить, что ошибки программиста — не часть ООП. И он не обязан их совершать.

Это сообщение отредактировал(а) Arantir - 21.5.2013, 22:06

  А вот и обязан. Особенно ООП ошибки при написании ООП кода. Хотя каждый программист и мнит себя Богом, но статистика вещь неумолимая. Если есть даже небольшой процент совершить логическую ошибку любой некоторой  строке, то с увеличением числа строк/классов/функций шанс совершить ошибку растет по формуле 1-(шанс не совершить ошибку)^n , где  n число единиц кода  для которых по статистике имеется такой шанс не совершить ошибку. Я думаю для больших проектов процент совершить хотя бы одну логическую ошибку порядка 99.99% если не выше. 
  

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

Добавлено через 6 минут и 37 секунд

А метод GetAverage(int* a, int n) с точки зрения ООП некорректен? Обязательно делать массив и число элементов членами класса?

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

Я же имел ввиду, что программу можно сделать предсказуемой. И оставлять ее непредсказуемой только потому, что это возможно в следствие принципов ООП — это неправильно.

ТС сказал что-то вроде "Можно потянуть связки, вставая с кровати. Какие есть методы решения этой проблемы?" Но миллионы людей как-то по утрам нормально встают с кровати не заморачиваясь этим вопросом, ибо он, как таковой, не имеет смысла. В этом контексте ТС просто не может понять, как люди с кровати встают.


Как можно приводить этот пример и при этом писать писать 
Такой человек или еще или вообще не программист. 
Не ООП делает программу непредсказуемой, а банальные или глупые ошибки. Неправильное преобразование типов, необдуманные инкременты, отсутствие проверок корректности данных и т.п. т.д.
ООП позволяет создавать полностью корректные программы любого размера и масштаба. Проблема ошибок — это проблема человеческого восприятия мира, а не принципов ООП.

Если чем-то можно совершить ошибку, то это еще не значит, что это его недостаток. И ножом можно порезаться, и самолет может упасть, и короткое замыкание в технике может быть... Но нож должен быть острым, чтобы хорошо резать; самолет должен быть над землей, чтобы быстро лететь; технике нужна электроэнергия, чтобы выполнять столь полезные функции.
То, что в ООП есть обсуждаемые в этой теме вещи, только дает больший размах, больше свободы для реализации своих идей на практике.

Я не отрицаю возможности ошибок. Я не отрицаю возможности непредсказуемого поведения программы.
Я лишь отрицаю верность утверждения, на котором основана эта тема. Утверждения о том, что это является проблемой, порожденной ООП.

В программах без ООП те же проблемы могут вызвать глобальные переменные. Но их как правило стараются избегать. 
В классах же данные есть почти всегда. Поэтому описанная проблема больше относится к именно ОО подходу.

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


  Не позволяет. ООП ничего не говорит о том как правильно писать программы. Не говорит о том как их проектировать. ООП лишь описывает проектирование определенной модели. Программы любого размера и масштаба создают опытные программисты с опытом проектирования программ. ООП не говорит сколько объектов должно быть в программе, какие сущности должны описываться объектами, не говорит какие отношения между ними. ООП это лишь совет программисту - строй дом (программу) из кирпичей в форме прямоугольного параллелепипеда. Это хороший совет, но дома из кирпича имеют свои плюсы и минусы именно потому, что они из кирпича, а не потому что стены клали криворукие каменщики. И кирпичные стены будут иметь дефекты типичные для кирпичных стен.

Вообще, ТС, конечно, троль. Чую он нарыл описалово преимущества ФП по отношению к императивным языкам и вборсил в форум ярых императивщиков. 

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

Добавлено через 9 минут и 43 секунды

То есть"говорит о том как" и "позволяет" — это одно и то же? Зачем просто придираться к словам?
Я перефразирую: с помощью (используя) ООП возможно создавать полностью корректные программы любого размера и масштаба. Большие программы без ошибок никаким принципам ООП не противоречат.
Дело в контроле и тестировании. При строительстве самолета уделяется огромное количество средств на контроль качества на всех уровнях производства. Если бы самолет строили столько же человек и с аналогичными возможностями, сколько в среднестатистической разработческой группе программистов, то ошибок в этом самолете было бы не меньше, чем в программах.

  Я не придираюсь к словам, я расставляю акценты. Ключевая мысль в том, что масштабируемые программы работают благодаря опыту проектирования и знаниям в первую очередь. При этом может использоваться кирпич (объект) как основной материал. Т.е. не объект панацея, а именно опыт и знания. Если, к примеру, вам дать n-е количество машин кирпичей и сказать стройте дом. Я не думаю, что получиться что-то хорошее. Хотя у вас неплохой инструмент кирпич, из которого построены много домов разной величины. 

Локальные переменные могут создавать те же проблемы:

Так что это проблема не ООП.