Как оптимальнее спроектировать большой калькулятор на JAVASCTIPT?

Question

[coderisimo]

Доводилось делать относительно небольшие проекты, но даже они постепенно превращались в не слишком понятное сосредоточие кода. Суть : исходные данные, много вычислений, возможны изменения в части расчета. Сам расчет однотипный. Но довольно большой, возможны итерации с изменением исходных значений с определенным шагом итд.
Как лучше организовать сие? может придумать классы, с методами, инкапсуляцией и прочими плюшками? Или все равно через пару месяцев там в любом случае будет клубок, который непросто понять? Буду благодарен, как всегда за любые КОНСТРУКТИВНЫЕ идеи. Может есть статьи на данную тему?

Спасибо

Answer 1

[Сергей Протько]

может придумать классы

1) в JS нет классов.
2) нет не лучше, вы должны оперировать объектами.

Или все равно через пару месяцев там в любом случае будет клубок, который непросто понять?

Инкапсуляция ради инкапсуляции вам ничего не даст.

Вообще проблемы у вас из-за такой штуки как smartui. Проблему эту решили еще в конце 70-х введя такую штуку как MVC. Сегодня MVC (на самом деле сегодня почти все используют MVA но это не суть) любят использовать вместе с MVVM.

Конструктивные идеи: реализуйте модель на JS для начала. Никакого интерфейса пользователя, тупо логика, объектики хранящие данные и логику обработки этих данных, объектики которые могут общаться друг с дружкой и менять состояния друг друга (не напрямую, инкапсуляция же).

Если логика реально сложная - напишите для модельки этой тесты, покрывающие самые сложные кейсы (что бы руками не тестить).

затем вводим контроллеры. Самый примитивный контроллер:

$('#someInput').on('change', function () {
    // я контроллер
    // я обрабатываю действия пользователя 
    // и прошу модель поменять состояние в соответствии с этими действиями
    model.updateValue(this.value);
});

с вью намного интереснее. Тут лучше применить ViewModel как посредника между View и Model (что бы не писать тучу кода со стороны view которая будет отслеживать состояние модели). Для этого есть кучи клевых библиотек предоставляющих нам ту самюу viewmodel с биндингами.

Ну и последнее - все должно быть явно, в модели лучше не пользоваться событиями и явно дергать методы других моделей. Кроме моделей их методы могут дергать ТОЛЬКО контроллеры, предварительно подготовив данные из формата view в формат приложения.

Ну и как-то так.

Comments

[vasIvas]

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

[Сергей Протько]

vasIvas: калькуляторы разные бывают. Обратная польская запись это конечно хорошо и правильно (я надеюсь автор вкурсе о ней, но упоминуть буде все же не лишним), но бывают так же зависимости по данным и куча других мелочей. Иначе у автора думаю не возникло бы проблем с поиском готового решения.

[coderisimo]

Спасибо. Я хоть и сильно начинающий, но работал и с YII и backbone где тоже есть модели и прочее. Кто-то считает толстые модели нормальным явлением, кто-то смертным грехом. Я пока присматриваюсь Про польскую нотацию , кстати, не слышал. Спасибо за ответы. Тесты это отдельная тема :(. Я их мозгами еще не понимаю. То что надо тестирую руками, а механизм тестирования для моих мозгов лежит в параллельной вселенной. Слышал, но как использовать в своих задачах не знаю )