Здравствуйте, SV., Вы писали:

SV.>Допустим, я хочу посчитать a — длинноцелое, b — строка на входе (неизвестное число знаков), c — бинарное представление вещественного числа X(формат IEEE-666, 50 знаков). i = 100.
Что такое i?
Результат, в зависимости от сиюминутных потребностей, требуется использовать при форматировании строк (пугать комиссии, ага), и отдавать в бинарях для хранения в базе DB-3000. Как будет выглядеть (хотя бы примерно) код вашего проекта?
Я не понимаю вашего вопроса.
SV.>Надо ли говорить, что первой моей мыслью при ознакомлении с подобным проектом будет поискать класс, инкапсулирующий число, который умеет хранить его с заданной точностью, и поддерживает вход и выход?
Надо. Потому что эта мысль совершенно неочевидна. Зачем вы собрались искать "класс" для штуки, которая не обладает идентичностью и поведением?
Почему вы не хотите найти АТД, т.е. штуку, которая принимает некоторые значения и имеет некоторое определённое поведение?
То, что вы ищете "класс", выдаёт наличие шрамов в сознании, оставленных С++.


SV.>Ну а кто должен считать баланс? "Мы" — это кто? Состояния у нас нет, а есть обработчик суммы проводок, но где он у вас сидит?
Там, где удобно с точки зрения архитектуры программы.

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

S>>Но сами эти вещи назвать "состоянием счёта" у меня мозг не поворачивается — просто потому, что через полчаса я попрошу посчитать тот же остаток на совершенно другую дату, и он будет ничуть не хуже, чем первый.
SV.>У кого попросите?
Я — попрошу у программы. Мне всё равно, я пользователь.
SV.>Да, забыл упомянуть. Если счет мультивалютный, то где и как мультивалютность будет обеспечиваться?
Ну, я не настолько хорошо разбираюсь в бухгалтерии, чтобы сходу написать архитектуру мультивалютности. Но, надо полагать, что она будет обеспечиваться там же, где и всё остальное.

SV.>Оборот за период не выглядит объектом для наблюдателя. Ну, разве что, если учесть валюту и какие-то иные атрибуты... Но тогда их и будет разумно инкапсулировать вместе с числом.
В том-то и дело, что не выглядит. И счёт тоже не выглядит объектом. В общем и целом, внезапно оказывается, что ООП-шных объектов в бухгалтерии нет.

SV.>Это плохое решение, но оно результат плохой декомпозиции, а не подхода.
Совершенно верно. Но именно такой способ декомпозиции навязывают обычные курсы ООП.
При ОО-анализе бухгалтерской программы мы будем спрашивать не "что делает счёт", а "что должна делать программа".
Допустим, у нас возникает ответ "должна рассчитывать оборотно-сальдовую ведомость". Дальнейшее движение мысли приводит нас к набору объектов, которые соответствуют "механизмам расчёта" этой оборотно-сальдовой ведомости. Но никаким объектам в предметной области они соответствовать, увы, не будут. Проводки так и останутся структурами, счета останутся идентификаторами.