Рефакторнуть код в ООП?

Question

[Zelyoniy]

Есть форма комментариев. Стоит задача превратить это всё в ООП, но как это сделать на jquery, я теряюсь.
Можете направить в нужное русло?

Answer 1

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

Стоит задача превратить это всё в ООП

давайте не так, не в ООП а просто в читабельный и поддерживаемый код.

- избавьтесь от дублирования кода. Вынесите для начала все действия в отдельные функции. Например:

$("#addComment").css("display", "block");

и подобные можно заменить как

// функции хэлперы для устранения дублирования
function hide(selector) {
   return function () {
        $(selector).css("display", "none");
   };
}
function show(selector) {
   return function () {
        $(selector).css("display", "block");
   };
}

// специализированные хэлперы с говорящими названиями
var showCommentsForm = show("#form");
var hideCommentsForm = hide("#form");
var showAddCommentButton = show("#addComent");
var hideAddCommentButton = hide("addComment");

идем дальше...

var counter = parseInt($("#counter span").html())+1;
          $("#counter span").html(counter);

Тут явно стоит использовать data-*. Или любой другой способ подсчета. Знать бы еще что считается, судя по всему вам надо посчитать количество сообщений. В этом случае вообще так себе идея так делать.

$(document).on("click", "input[name='send']", function (){

лучше случать сабмит формы. Обязательно устраните "глобальный поиск" по селекторам.

Ну и это не говоря о том что инлайн стили, селекторы на айдишках, шаблоны с дублированием - это путь к боли.

Comments

[AlikDex]

Почему селекторы на айдишниках это путь к боли? Разве они не быстрее работают, чем все остальные селекторы?

[Сергей delphinpro]

AlikDex: Потому что они глобальные, и рано или поздно возникнет попа-боль. 100%, проверено на практике. Код вообще не должен быть привязан к DOM. Обрабатываете форму? ok. Пусть будет грубо говоря функция processForm(elem) которая получает дом-элемент и работает с ним, а внутренние элементы она ищет именно внутри переданного элемента, а не глобально по странице. Ну тому подобное, в том же духе.

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

AlikDex: вам сейчас даже не стоит замарачиваться на эту тему. Врядли это станет узким местом в вашем приложении. Да и всегда результаты выборок можно закэшировать.

[AlikDex]

Сергей: Понял, спасибо.

[Zelyoniy]

Сергей Протько: спасибо за ответ.
"Знать бы еще что считается, судя по всему вам надо посчитать количество сообщений. " - на странице просто показывается кол-во комментариев. Дело в том, что "не в ООП" не получится - это требование задания. Если в пхп я бы это состряпал, то тут - нет.

[Zelyoniy]

Сергей Протько: цитирую: "поверхностно описать абстракции интерфейса - какие классы как называются и что примерно делают, как соотносятся с другими".

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

Zelyoniy: объясните тому кто давал задание что "ООП это не классы". Модуль вполне можно считать объектом. Любая хрень инкапсулирующая в себе данные и функции работающие с этими данными является объектом в широком понимании.

В целом же у вас тут классы можно выделить по компонентам. Компонент работы с формой, компонент счетчик... и все такое.

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

Zelyoniy: можно еще отдельно вынести обработку событий в отдельный класс-контроллер который будет дергать компонеты и говорить им что делать. Чтобы вся логика работы с DOM была отдельно, ивенты отдельно и т.д. Разделение ответственности и все такое.