Я поддерживаю специально созданное приложение электронной коммерции с высоким уровнем объектно-ориентированного подхода. Первоначальный дизайнер сделал несколько предположений, таких как: - никогда не будет больше трех типов налога с продаж (государственного, национального и хамонизированного) - каждый тип налога с продаж может иметь только одну ставку. - каждому штату будет присвоен один из трех видов налогов.
Он должен был знать лучше, но я думаю, что в то время это казалось разумным ... Внезапно каждый штат устанавливает свою собственную «согласованную» налоговую ставку.
Проблема: на 3 уровня ниже по стеку объектов у меня есть метод расчета налога, который использует только сумму и тип налога. Теперь я столкнулся с задачей довольно большой реструктуризации приложения, которое у меня мало понимания или мало средств для изучения.
Я склонен вставлять код состояния в значение сеанса и выполнять на другом конце жестко запрограммированные вычисления. (1 день) вместо реструктуризации (1-2 недели ??)
Это мое воображение, или у объектно-ориентированных приложений более сложная кривая обучения, и их труднее поддерживать, когда бизнес-правила принимают неожиданный поворот?
