Стоит ли преобразовывать мой функциональный код JavaScript в объектно-ориентированный дизайн?
в настоящее время я создаю небольшое веб-приложение, которое включает в себя достаточное количество JavaScript. Когда я прототипировал первоначальную идею, я просто взломал несколько функций, чтобы продемонстрировать, как приложение в конечном итоге будет вести себя, намереваясь продолжить переписывание JavaScript в объектно-ориентированном виде.
теперь, когда я вхожу в фазу реализации, я нахожу, что создание объектно-ориентированного JavaScript ради объектно-ориентированного кажется излишним - проект вряд ли потребует каких-либо серьезных изменений в будущем, которые оправдали бы и объектно-ориентированный дизайн. Вместо этого я нахожу, что набор сжатых, сплоченных функций работает хорошо.
Итак, с учетом сказанного и с попыткой придерживаться принципа KISS, когда набор функций обеспечивает подходящее решение проблемы, есть ли другие причины, которые стоит рассмотреть, чтобы преобразовать мой код в объектно-ориентированный дизайн?
8 ответов
нет, хотя лично я нахожу ООП более вкусным, это средство для достижения цели, а не самоцель. Есть много случаев, когда процедурное программирование имеет больше смысла, чем ООП, преобразование ради преобразования, может быть, как вы сказали, излишним.
Если ваш код хорошо структурирован, хорошо выложен и хорошо прокомментирован и выполняет работу, которая от него требуется, то возиться с ним по любой причине, кроме добавления функций, не рекомендуется.
хотя было бы неплохо сказать, что программа красиво ООП и т. д., Если ее не нужно менять на работу, я бы определенно оставил ее как есть.
Если он не сломался, не возитесь с ним:)
Если этот код уже реализован и не требует обслуживания или - еще лучше - обновления, придерживайтесь его. Если вы собираетесь реализовать его сейчас, и он может стать сложным, рассмотрите подход OO.
опыт показал мне, что довольно легко писать и поддерживать процедурный код, пока Сложность низкая, но после определенного порога становится экспоненциально сложнее увеличивать сложность при использовании процедурного программирования, тогда как ООП, хотя и сложнее для начала, сохраняет сложность гораздо более управляемым.
итог: если задача достаточно проста, или уже реализовано, сохранить его простым. Если это может стать более сложным, подумайте об ОП.
Я бы сказал, что все равно стоит пересмотреть свой код, прежде чем принимать решение. Очевидным недостатком "переписывания" кода является то, что существует стоимость тестирования, чтобы убедиться, что ваш код работает так же, как и раньше. У вас есть модульные тесты? Если нет, то стоимость тестирования еще выше. Поэтому в целом я против перезаписи рабочего кода, если он не служит другой цели, что позволяет вам легче писать новые функции, которые теперь требуются (т. е. рефакторинг общих функций, так далее.)
однако, каждый раз, когда человек говорит "я взломал вместе", я предлагаю всегда стоит второй взгляд на ваш код. Почему его вообще взломали? Я знаю, что многие люди говорят, что объектно-ориентированный код не является самоцелью, но это методология, о которой через некоторое время не нужно думать. Ты просто начинаешь делать это естественно.
возможно, ваш js относительно прост, и поэтому OO scafolding действительно дополнительные накладные расходы. Штраф. Но я по-прежнему предлагаю вам всегда просматривать код (и особенно кого-то другого) любой код, который вы называете "взломанным". Возможно, это была ошибка Фрейда... но он соскользнул.
отныне рассматривайте его как устаревший код. Когда вы хотите что-то изменить, переделать его так, что код становится легче на голове. Если вам нужно немного ООП, используйте его. Если нет, то не надо.--1-->
ООП молоток, пожалуйста не обрабатывает винт-проблему как ноготь.
Если он работает,и его легко поддерживать, я бы не стал его преобразовывать ради конверсии. Должны быть более интересные занятия.
просто голые в виду объекты довольно дороги для создания в javascript.
держите строительство объектов до минимума.