О, привет сообщество! Опять тупой вопрос задать хотел. Клиент шлет три десятка разных запросов из разных мест. Могу все запихнуть в один класс, могу сделать по классу на каждый запрос. Определение истины в этом вопросе подкреплено какими-то стандартами/рекомендациями/правилами хорошего тона?
имхо ващпе не оттудова танцуешь Если где требуется одинаковый код - можно в один не важно что. Если везде разный, и нужна инкапсуляция какая-нить, то в разные. Если ничего из этого не нужно, и запрос обрабатывается одной функцией, то хоть в один класс всё пихай, один хрен они независимы.
Воооот. Ну раз никаких стандартов хипстеры на этот счет не придумали, тогда пойду делать как читабельнее и логичнее.
а не лучше, для начало по изучать какой-нить уже существующий framework, а потом уже писать свой "велосипед" ?? (
Ключевое слово здесь "какой-нить"? Не, спасибо. Есть фундаментальные вещи, есть международные стандарты - вот этому я считаю верным следовать. Есть рекомендации разработчиков протоколов, языков программирования и прочих инструментов, к которым тоже стараюсь прислушиваться. А вот "какой-нить" фреймворк - это куда-нить на хабр. Там много любителей обмазаться модными фреймворками с ног до головы, обернуть все это в методологии, набрать команду человек в тридцать и получить на выходе тяжеленный неподдерживаемый непереносимый сайт не проходящий валидацию. Зато при чтении резюме любого из тридцати в глазах рябит от аббревиатур и модных слов. "Но никто так и не знает чем абстрактный класс отличается от интерфейса" (с) Честно говоря на форумах вопросы именно поэтому задаю. В гугле одни креативные статьи от знатоков, которые учат сразу фреймворки и библиотеки и не заглядывают под капот.
ну в пхп всё довольно зыбко. По сути из коробки подразумевалось, что пхп обрабатывает каждый запрос в своём файле. Фактически сейчас все запросы идут на один файл, и там распределяются по другим. Ничто не мешает раскидать обработчики по файлам, как я делаю. Ничто не мешает общий код собрать в классы или функции. Но это подходит для определённых задач. А для других - не подходит. Если у тебя жутко разные запросы и обработчики, то их не стоит пытаться упихать все в один файл в любом случае. Ещё пхп позволяет дёргать функции и методы по их названию. Таким образом можно сделать некий конфиг, где определить какому запросу какой метод какого класса соответствует. Пхп гибкий.
А JS гибче!11расраз!11 Гляди, суть подглядывания в другие проекты в том, чтобы посмотреть, а как делают другие. И делать выводы. И мб заимствовать какие-то архитектурные решения или подходы. Не код, а решения и подходы, чтобы не изобретать что-то, что давно изобретено. Или не делать эхто что-то наобум, чтобы оно потом страдало детскими болячками, а взять что-то, что этот период прошло и допилить до своих желаний. Не в коде, повторюсь, а на листочке, с карандашом в руках. Рисуя стрелочки и квадратики. И иногда человечков. Человечки все делают лучше и веселее.
не. у похапе есть ассоциативные массивы и кой-какие приватные методы в классах. В js своих плюшек куча, да. Но этих мне не хватает оченно. Хотя хешмапы ввели вроде, но это какой браузер ещё их поддерживать будет и когда - большой вопрос.
Ох, ушел разговор не в то русло, но можешь в личку постучаться, расскажу про JS интересное всякое. В том числе ассоциативные массивы там есть.
Говори тут. А тему завтра распилю на две и перенесу. Ща чета совсем лень думать как назвать и куда переносить =(
Все методы в одном классе должны быть взаимосвязаны какой-то задачей общей, вот это этого и стоит плясать. Когда класс разрастается - начинаются проблемы. У самого недавно в проекте получился мега-контроллер "Фирма", и всё никак теперь не соберусь отрефакторить нормально. Лучше бы сразу об этом задумался, и разбил на различные задачи по фирме
JS на 99% состоит из "reflection". Мы можем на лету переопределять свойства и методы объектов. Всех, включая "системные". Добавлять новые, изменять старые. Это единственный язык, из всего, что я видел, где такое возможно. При этом любая переменная - объект. Даже если эта переменная - функция. А любой объект - массив. И может быть прочесан как массив, в том числе ассоциативный. И редактироваться как массив. Но при этом никто не мешает обращаться потом к ячейкам как к свойствам объекта. А разные функции, например, могут обмениваться контекстами выполнения. Более того, можно бесшовно в рантайме склеивать функции между собой, внедряя паразитный код. А потом безболезненно убирать его. А ты мне говоришь, что PHP гибкий, потому что есть ассоциативные массивы. Добавлено спустя 5 минут 2 секунды: Хотя, нельзя не признать, что все вышеперечисленное никогда не открывается тем, кто не программирует на JS, а пользуется им, тягая из интернетов сниппеты, или юзая только деревянную как стекло JQuery.
Сравниваются не два языка, а степень гибкости оных. JS гибче PHP априори, потому что в PHP рефлекшена нет от слова совсем. А JS из него состоит на 99%. Остальные стороны языков, как и сферы применения при этом обсуждении не рассматриваются.
Это потому, что ты не знаешь, что гибкость JS позволяет делать почти все, что угодно, включая возможности языка, которые явно не указаны. Инкапсуляцию в том числе. Раз на то пошло, в JS вообще почти ничего нет. Ну вообще. Из синтаксических конструкций - иф, свитч, фор, вайл, нью, бинд, аппенд. Все, плюс минус. На этом JS кончился. Но, в связке с его безумной архитектурой, этого достаточно, чтобы сделать все, что угодно. Это эдакий пластилиновый язык. Другие языки - это лего. Есть кубики определенной формы, определенного размера, крапятся по определенным правилам. Строй из них замок. А JS - пластилин. Есть брусок пластилина, есть нож. Все. Делай что хочешь, все формы и размеры определяй сам, все правила определяй сам. Что как работает, определяй сам. В этом плане он просто сносит голову. Чтобы на нем реально кодить, а не дергать сниппеты, нужно буквально менять образ мышления.