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

SV.>Нашелся один Sinclair, который привел целых два. Первый — бухгалтерия, которая оперирует счетами, но класс Account заводить неправильно, второй — решение квадратных уравнений, где ООП не нужно. Извините, если кого пропустил. Читал по диагонали, потому, что про коров читать не могу. Заратустра не позволяет.

SV.>Sinclair'у про квадратные уравнения я ответил, что это — простейшая функция, которую проходят в средних классах школы и он бы еще 2 + 2 складывал в объектной парадигме. Если взять реальную (по сложности) инженерную задачу, типа, написать тот же решатель квадратных уравнений, НО! с любой заданной точностью, с реюзабельной арифметикой и хорошей интегративностью, ООП будет вне конкуренции по понятности кода такого проекта для новичков (а других свойств я ООПу и не приписывал).
Непонятно, при чём тут ООП. Всё, чего вы попросили, выражается при помощи замены "простейшей функцией" её шаблонным аналогом:

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

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

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

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