А паттерн 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) с точки зрения ООП некорректен? Обязательно делать массив и число элементов членами класса?

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

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

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


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

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