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

S>Непонятно, при чём тут ООП. Всё, чего вы попросили, выражается при помощи замены "простейшей функцией" её шаблонным аналогом:
S>

S>(T, T) resolveSqEq<T>(T a, T b, T c);
S>

S>Потому, что алгоритму неважно, какая там точность. Ему важно, чтобы для T были определены операции умножения, сложения, возведения в степени -1 и 1/2, и получения обратного элемента. Всё. А, ещё пригодится константа 0.
S>Кормите алгоритм хоть октонионами, хоть матрицами — дайте определения операций, и дело в шляпе.

Допустим, я хочу посчитать a — длинноцелое, b — строка на входе (неизвестное число знаков), c — бинарное представление вещественного числа (формат IEEE-666, 50 знаков). i = 100. Результат, в зависимости от сиюминутных потребностей, требуется использовать при форматировании строк (пугать комиссии, ага), и отдавать в бинарях для хранения в базе DB-3000. Как будет выглядеть (хотя бы примерно) код вашего проекта?

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

SV.>>Про бухгалтерию я не знаю, что ответить. Я ее знаю на уровне ведения ООО и у меня идея класса Account отторжения не вызывает.
S>У этого класса нет никакого поведения, поэтому совершенно непонятно, что именно инкапсулировать. "Состояние" объекта Account полностью прозрачно. Еще есть такая проблема, что в принципе понятие "состояние" у счёта штука очень условная. Грубо говоря, бухгалтерия — это набор проводок.
S>Исходя из этого набора мы можем высчитать всякие виртуальные вещи — типа "каков у нас остаток дебиторской задолженности на 1 августа 2012".

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

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

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

>Есть ещё куча показателей, которые совсем никак не похожи на "объекты", существующие объективно и независимо от наблюдателя — к примеру, тот же "оборот дебиторской задолженности за период".

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

S>Решение, в котором счета — это объекты, а проводки — сообщения, которыми они обмениваются, потребует гонять эти проводки туда-сюда каждый раз, как мне захочется заглянуть в прошлое. Внезапно обнаруженный первичный документ, датированный прошлым сентябрём, сломает нафиг эту модель, т.к. его не "вставишь" между уже отправленными сообщениями.

Это плохое решение, но оно результат плохой декомпозиции, а не подхода.

S>Поэтому в бухгалтерии гораздо полезнее модель, в которой счёт — это просто номер; даже не число, а идентификатор. Проводка — это тоже не объект, а просто запись некоторого факта. Поверх этого рисуются всякие расчётные операции, которые тоже нифига не объекты, а просто формулы (уровня пятого класса). Сведение баланса = проведение примитивного расчёта.

Немного позже покажу, как такую задачу решал я.