В этой статье описывается шаблон проектирования PHP. Для вашей справки приведем следующие сведения:
1. Шаблон дизайна
Шаблон проектирования-это набор многократного использования, как известно большинству людей, после классификации, каталогизации, обобщения опыта разработки кода. Шаблоны проектирования используются для повторного использования кода, облегчения понимания его другими и обеспечения надежности кода. Без сомнения, способ разработки программного обеспечения больше, чем у других. Классическое определение шаблонов: каждый шаблон описывает проблему, которая постоянно возникает в нашей среде, а затем описывает суть решения проблемы. Таким образом, мы можем повторно использовать существующие решения бесчисленное количество раз, не повторяя одну и ту же работу. Шаблон-это решение проблемы в конкретной среде
2. Назначение шаблона проектирования
Цель состоит в том, чтобы научить вас использовать аутентичный и надежный дизайн для организации шаблонов кода. Короче говоря, это общий превосходный опыт, обобщенный и обобщенный предшественниками в процессе программирования. Основная цель состоит в том, чтобы повысить гибкость и возможность повторного использования программы. С другой стороны, это также помогает стандартизировать разработку программы и улучшить ход разработки системы.
Некоторые люди также советуют: не обращайте слишком много внимания на “шаблон дизайна” программы. Иногда проще написать простой алгоритм, чем ввести шаблон. В большинстве случаев программный код должен быть простым для понимания, даже уборщики могут его понять. Однако в крупных проектах или фреймворках нет шаблона проектирования для организации кода, который трудно понять другим.
Модель разработки программного обеспечения-это всего лишь руководство. Он должен быть специально разработан в соответствии с характеристиками и требованиями языка программирования и вашего приложения.
3. История шаблонов проектирования
Термин “шаблон дизайна” изначально был разработан для использования в области архитектуры. В своей книге 1977 года “Язык шаблонов: города/строительство/строительство” Кристофер Александер описывает некоторые общие проблемы архитектурного проектирования и объясняет, как использовать эти существующие известные наборы шаблонов для создания нового и эффективного дизайна. Точка зрения Александра была хорошо воплощена в разработке программного обеспечения, и он уже давно готов использовать оригинальные компоненты для создания новых решений.
4. Четыре основных элемента шаблона дизайна
Шаблоны проектирования облегчают людям повторное использование успешных проектов и архитектур. Выражение проверенных технологий в виде шаблонов проектирования также облегчит разработчикам новых систем понимание их дизайнерских идей.
Все шаблоны проектирования имеют некоторые общие черты: идентификация (имя шаблона), Постановка проблемы (постановка проблемы) и Решение (решение), эффект (последствия)
Имя шаблона: описывает проблему, решение и эффект шаблона.
Идентификатор шаблона дизайна (имя шаблона) важен, потому что он позволяет другим программистам сразу понять назначение вашего кода, не изучая слишком много (по крайней мере, благодаря этому логотипу программисты будут знакомы с шаблоном). Без этого названия модели мы не можем передавать дизайнерские идеи и результаты дизайна другим.
Описание проблемы используется для иллюстрации области применения этого шаблона.
Описывает, когда следует использовать шаблоны. В нем объясняются проблемы проектирования, а также причины и последствия этих проблем. В нем могут быть описаны конкретные проблемы проектирования, такие как способ выражения алгоритмов с помощью объектов. Он также может описывать структуру класса или объекта, которая приводит к негибкому дизайну. Иногда раздел “Проблема” включает набор предварительных условий, которым должен удовлетворять шаблон использования.
Решение Описывает реализацию этой модели. В этом документе описываются компоненты проекта, взаимосвязь между ними, их соответствующие обязанности и методы сотрудничества. Поскольку шаблон подобен шаблону, который может быть применен во многих различных ситуациях, решение не описывает конкретный и конкретный проект или реализацию, а предоставляет абстрактное описание проблемы проектирования и того, как решить проблему с помощью общей комбинации элементов (класса или комбинации объектов).
Эффекты (последовательности)
В этой статье описывается эффект применения шаблона и проблемы, которые следует учитывать при использовании шаблона. Хотя мы не всегда упоминаем влияние шаблонов при описании проектных решений, они важны для оценки выбора дизайна и понимания затрат и преимуществ использования шаблонов. Программные эффекты в основном сосредоточены на измерении времени и пространства, а также выражают проблемы языка и реализации. Поскольку повторное использование является одним из элементов объектно-ориентированного проектирования, эффекты шаблонов включают его влияние на гибкость, расширяемость или переносимость системы. Полезно понять и оценить эти закономерности, чтобы четко перечислить эти эффекты. Хорошее обсуждение шаблона проектирования должно охватывать преимущества и недостатки использования этой модели.
Шаблон-это эффективный способ решения конкретных проблем. Шаблон проектирования-это не библиотека (кодовая база, которая может быть непосредственно включена и использована в вашем проекте), а шаблон (компонент java), используемый для организации вашего кода. На самом деле, существует много различий между базой кода и шаблоном проектирования в приложении.
Например, рубашка, которую вы покупаете в магазине, является кодовой базой. Его цвет, стиль и размер определяются дизайнером и производителем, но он отвечает вашим потребностям. Однако, если в магазине нет ничего подходящего для вас, вы можете создать свою собственную рубашку (спроектировать ее форму, выбрать ткань, а затем сшить ее вместе). Но если вы не портной, вам может быть легко найти правильный узор и создать свою собственную рубашку в соответствии с этим рисунком. С помощью модели вы можете получить искусно разработанную рубашку за меньшее время.
Возвращаясь к программному обеспечению для обсуждения, уровень извлечения данных или CMS (система управления контентом) – это библиотека, она была разработана и закодирована ранее. Если он может точно удовлетворить ваши потребности, это хороший выбор. Но если вы читаете шаблоны проектирования, вы можете обнаружить, что решения по инвентаризации не всегда работают для вас. Пока вы знаете, чего хотите, и можете это реализовать, вам просто нужна модель, которая будет направлять вас.
И последняя мысль: как и модель портного, дизайн сам по себе бесполезен. В конце концов, вы не можете носить модель платья – она просто сделана из очень тонкой бумаги. Аналогично, модель разработки программного обеспечения-это всего лишь руководство. Он должен быть специально разработан в соответствии с характеристиками и требованиями языка программирования и вашего приложения.
3. Классификация шаблонов проектирования
1) В зависимости от цели (для чего используется шаблон) его можно разделить на три типа: творческий, структурный и поведенческий • Создайте шаблон В основном он используется для создания объектов. • Структурная модель Он в основном используется для обработки комбинации классов или объектов. • Поведенческая модель Он в основном используется для описания того, как взаимодействовать с классами или объектами и как распределять обязанности.
2) В соответствии с областью действия, т. Е. Независимо от того, используется ли схема в основном для обработки отношений между классами или объектами, ее можно разделить на шаблон класса и шаблон объекта
• Шаблон класса : имеет дело с отношениями между классами и подклассами. Эти отношения устанавливаются путем наследования и определяются во время компиляции. Они статичны. • Шаблон объекта : имеет дело с отношениями между объектами, которые изменяются во время выполнения и являются более динамичными.
4. Некоторые основные шаблоны проектирования (Энциклопедия Baidu)
Абстрактная фабрика: предоставляет интерфейс для создания ряда связанных или взаимозависимых объектов без указания их конкретных классов.
Адаптер: преобразует интерфейс одного класса в другой, который нужен клиенту. Шаблон адаптера позволяет классам, которые в противном случае не работали бы вместе из-за несовместимости интерфейса, работать вместе.
Мост: отделяет абстрактную часть от ее части реализации, чтобы их можно было изменять независимо.
Конструктор (шаблон построения): отделите построение сложного объекта от его представления, чтобы в одном и том же процессе построения можно было создавать различные представления.
Цепочка ответственности: для того, чтобы отделить отправителя и получателя запроса, несколько объектов имеют возможность обработать запрос. Соедините эти объекты в цепочку и передайте запрос по цепочке, пока объект не обработает его.
Команда (командный режим): инкапсулирует запрос в объект, чтобы вы могли параметризовать клиентов с различными запросами, запросами в очереди или журнале и поддерживать отменяемые операции.
Шаблон композитной композиции: объекты объединяются в древовидную структуру для представления иерархии “часть целого”. Это делает использование одного объекта и составного объекта согласованным.
Декоратор декоратор: динамически добавляет дополнительные обязанности к объекту. С точки зрения функции расширения, она более гибкая, чем генерация подклассов.
Фасад (шаблон фасада): обеспечивает согласованный интерфейс для набора интерфейсов в подсистеме. Шаблон фасада определяет интерфейс высокого уровня, что упрощает использование подсистемы.
Метод фабрики метод фабрики: определите интерфейс для создания объектов и позвольте подклассам решать, какой класс создавать. Фабричный метод задерживает создание экземпляра класса до его подклассов.
Flyweight: использование технологии совместного использования для поддержки большого количества мелкозернистых объектов.
Переводчик: для данного языка определите представление его грамматики и определите интерпретатора, который использует это представление для интерпретации предложений на языке.
Итератор итератор: предоставляет способ последовательного доступа к элементам агрегированного объекта без раскрытия внутреннего представления объекта.
Посредник: объект посредничества используется для инкапсуляции ряда взаимодействий объектов. Посредники делают так, что объектам не нужно явно ссылаться друг на друга, чтобы они были слабо связаны и могли независимо изменять свои взаимодействия.
Памятка (режим памятки): захват внутреннего состояния объекта и сохранение состояния вне объекта без нарушения инкапсуляции. Это приведет к восстановлению объекта в сохраненное состояние позже.
Режим наблюдателя: определяет отношение зависимости “один ко многим” между объектами, чтобы при изменении состояния объекта все зависящие от него объекты уведомлялись и автоматически обновлялись.
Прототип: используйте экземпляр прототипа, чтобы указать тип создаваемого объекта, и создайте новый объект, скопировав прототип.
Прокси-сервер: предоставляет прокси-сервер для других объектов для управления доступом к этому объекту.
Одноэлементный: гарантирует, что класс имеет только один экземпляр и предоставляет глобальную точку доступа для доступа к нему.
Состояние: позволяет объекту изменять свое поведение при изменении его внутреннего состояния. Объект, по-видимому, изменил класс, к которому он принадлежит.
Стратегия: определите серию алгоритмов, инкапсулируйте их один за другим и сделайте их заменяемыми. Этот шаблон делает изменение алгоритма независимым от клиентов, которые его используют.
Метод шаблона: определяет структуру алгоритма в операции и откладывает некоторые шаги до подклассов. Метод шаблона позволяет подклассам переопределять некоторые конкретные шаги алгоритма без изменения его структуры.
Шаблон посетителя: представляет операцию, которая воздействует на элементы в структуре объекта. Это позволяет определять новые операции над элементами без изменения их классов.
5. Шесть принципов режима проектирования
1) Основной принцип шаблона проектирования: Принцип “Открыто – закрыто” (OCP): открыт для расширения и близок к модификации
Это означает, что в системе расширение открыто, а модификация закрыта. Хорошая система может расширить ваши функции без изменения исходного кода. Ключом к реализации принципа открытости и закрытости является абстракция
Расширяя существующую программную систему, можно обеспечить новое поведение в соответствии с новыми требованиями программного обеспечения, а изменяющееся программное обеспечение обладает определенной адаптивностью и гибкостью. Существующий программный модуль, особенно наиболее важный модуль абстрактного уровня, не может быть изменен, что обеспечивает определенную стабильность и непрерывность изменяющейся программной системы. В соответствии с принципом “открыть-закрыть”, абстрактный класс или интерфейс не разрешается изменять, в то время как конкретный класс реализации разрешается расширять. Абстрактные классы и интерфейсы играют чрезвычайно важную роль в принципе “открыть-закрыть”.. то есть предсказать возможные изменяющиеся требования и предусмотреть все возможные известные расширения.. так что “абстракция” здесь является ключевым моментом!!!
Закрытый принцип изменчивости: найдите переменные системы и инкапсулируйте их. Это лучшая реализация принципа “открыть-закрыть”. Не помещайте свои переменные в несколько классов или не разбрасывайте их по всем углам программы. Вы должны огибать переменные факторы. И не оборачивайте используемые переменные вместе. Лучшее решение-это, блокируя конверт, ваши переменные факторы! Избегайте появления супер-класса, супер-длинного класса и супер-длинного метода! Добавьте художественный колорит в вашу программу, и наша цель-сделать программу художественной!!
2) Принцип подстановки Рихтера: может появиться любой базовый класс, также может появиться подкласс
Принцип подстановки Лискова: подкласс должен иметь возможность заменить базовый класс с того места, где он появился. Подклассы также могут добавлять поведение в базовый класс. Этот параметр относится к взаимосвязи между базовым классом и подклассом. Только когда эта взаимосвязь существует, может существовать принцип замещения Рихтера. Квадрат-это прямоугольник, который является классическим примером понимания принципа римановой подстановки.
3) Принцип инверсии зависимостей: полагайтесь на абстракцию, а не на конкретную реализацию
Принцип инверсии зависимостей заключается в том, чтобы полагаться на абстракцию, а не на конкретное. Короче говоря, принцип инверсии зависимостей требует, чтобы клиент полагался на абстрактную связь. Изложение принципа:
(1) Аннотация не должна зависеть от деталей; детали должны зависеть от абстракции; (2) Программа для интерфейса, а не для реализации.
Если принцип открытия и закрытия является целью, принцип опоры на инверсию является средством для достижения принципа открытия и закрытия. если вы хотите достичь наилучшего принципа “открытия и закрытия”, вы должны, насколько это возможно, соблюдать принцип обращения зависимости. Можно сказать, что принцип обращения зависимости является лучшим критерием для “абстракции”! Я чувствую, что принцип разворота зависимости также является дополнением к принципу замещения Рихтера, должно быть легко понять принцип разворота зависимости
4) Принцип повторного использования композиции/агрегации (crp): попробуйте использовать принцип композиции/агрегации вместо отношений наследования для достижения цели повторного использования программного обеспечения
Принцип повторного использования композитов/агрегатов (crp) часто называют принципом повторного использования композитов (CRP). Это означает использование некоторых существующих объектов в новом объекте, чтобы сделать его частью нового объекта. Новые объекты повторно используют существующие функции путем делегирования этим объектам. Короче говоря, используйте композицию/агрегацию как можно больше и избегайте наследования, насколько это возможно.
Мы должны попытаться использовать принцип композиции/агрегации вместо отношений наследования для достижения цели повторного использования программного обеспечения. Этот принцип и принцип замещения Рихтера дополняют друг друга. Оба они являются нормами для реализации принципа “открыто-закрыто”. Если мы нарушим этот принцип, мы не сможем реализовать принцип “открыть-закрыть”. Давайте сначала посмотрим, что такое синтез и что такое полимеризация
Что такое синтез? Например, его мебель не имеет ничего общего с его собственным домом, она такая же, как черная курица и высококачественные лекарственные материалы. Например, оружие и снаряжение в онлайн-играх синтезируются, и многие вещи объединяются в супер сильную вещь
Что такое агрегация? Агрегация: агрегация является более сильной зависимостью, чем синтетическая связь. Агрегация является частью целого для отдельного человека, например, отношения между автомобилем Mercedes Benz S360, двигателем Mercedes Benz S360 и шиной Mercedes Benz S360. Эти отношения имеют характер агрегации. Поскольку двигатель Mercedes Benz S360 и шина Mercedes Benz S360 могут использоваться только Mercedes Benz S360, оставляя Mercedes Benz S360, В нашем дизайне такие отношения не должны появляться часто. Это повысит степень связи дизайна Понимание взаимосвязи между композицией и агрегацией, а затем понимание принципа композиции/агрегации. Чтобы избежать появления при проектировании системы, уровень наследования класса увеличивается более чем в три раза. Если это так, вы можете рассмотреть возможность рефакторинга своего кода или изменения структуры. Конечно, лучший способ сделать это-рассмотреть возможность использования принципа композиции/агрегации
5) Закон Димитара: классы в системе не должны взаимодействовать с другими классами, насколько это возможно, чтобы уменьшить связь между классами
Закон Деметры (LOD) также называют принципом наименьшего знания (LKP), то есть объект должен знать как можно меньше о других объектах.
Другие выражения: общайтесь только со своими прямыми друзьями, не разговаривайте с “незнакомыми людьми”. Класс должен знать меньше всего о классах, которые ему нужно соединить или позвонить. Не мое дело знать, насколько сложна ваша внутренняя структура (связанный или называемый класс). Это твое дело. Я знаю, что вы предоставляете общедоступные методы. Я звоню так многим, и меня больше ничего не волнует.
Закон Димитара и шаблон дизайна фасад и посредник делают людей невежественными
Классы в системе не должны взаимодействовать с другими классами, насколько это возможно, чтобы уменьшить связь между классами. В вашей системе при расширении вам может потребоваться изменить эти классы. Взаимосвязь между классами определяет сложность модификации. Чем больше взаимодействий, тем сложнее их модифицировать. Напротив, если взаимодействие меньше, сложность модификации будет меньше. Например, класс a зависит от класса B, затем класс B зависит от класса C. когда вы изменяете класс A, вы должны рассмотреть, будет ли затронут класс B, и повлияет ли влияние класса B на класс c.. Если класс C снова зависит от класса D в это время, ха-ха, я думаю, что некоторые из таких изменений затронуты
6) Закон об изоляции интерфейса: Этот Закон аналогичен закону Димитара
Принцип разделения интерфейсов заключается в том, что лучше использовать несколько специализированных интерфейсов, чем использовать один общий интерфейс. Другими словами, с точки зрения клиентского класса, зависимость одного класса от другого должна основываться на минимальном интерфейсе.
Слишком раздутый интерфейс является загрязнением интерфейса. Клиенты не должны быть вынуждены полагаться на методы, которые они не используют.
Чтобы добиться как можно меньшего сцепления, нам нужно использовать интерфейс для стандартизации класса и использовать интерфейс для ограничения класса. Чтобы выполнить требования правила dimit, лучше всего реализовать закон об изоляции интерфейса и реализовать закон об изоляции интерфейса, и вы будете соответствовать закону Димитара
6. Краткое изложение
Шаблон проектирования-это успешная схема проектирования, которая может обеспечить повторное использование ремонтопригодности многих превосходных программных систем. Использование этих схем избавит нас от необходимости выполнять некоторую повторяющуюся работу и позволит разработать высококачественную программную систему.
Основные преимущества шаблона дизайна заключаются в следующем:
1) Шаблон дизайна объединяет опыт многих экспертов и используется разработчиками в стандартной форме. Он предоставляет набор общей лексики дизайна и общий язык для облегчения общения и общения между разработчиками, делая схему дизайна более понятной. Для разработчиков и дизайнеров, использующих различные языки программирования, шаблоны проектирования могут связывать схемы проектирования систем. Каждый шаблон соответствует стандартному решению. Шаблоны проектирования могут снизить сложность понимания разработчиками системы.
2) Шаблоны проектирования облегчают людям повторное использование успешных проектов и архитектур. Выражение проверенных технологий в виде шаблонов проектирования также облегчит разработчикам новых систем понимание их дизайнерских идей. Шаблоны проектирования облегчают повторное использование успешных проектов и позволяют избежать тех, которые приводят к не используемым проектам.
3) Шаблоны проектирования делают дизайн более гибким и простым в изменении.
4) Использование шаблонов проектирования повысит эффективность разработки и качество программной системы, а также в определенной степени сэкономит затраты на проектирование.
5) Шаблоны проектирования могут помочь новичкам глубже понять объектно-ориентированную идею. С одной стороны, это может помочь новичкам легче читать и изучать исходный код существующих библиотек классов и других систем, с другой стороны, это также может повысить уровень проектирования и качество кода программного обеспечения.
Шаблоны проектирования не изучаются, они используются. Обучение с целью изучения шаблонов проектирования может оказаться неэффективным. Общие рамки используют шаблоны проектирования. Например, ZF PHP используется для многих шаблонов проектирования. Имя класса или имя каталога в структуре названо в соответствии с определенным шаблоном проектирования. Как только вы увидите имя или имя файла класса, вы узнаете его структуру организации кода. Если вы хорошо владеете языком, остальная часть кода, естественно, очень проста. С накоплением опыта кодирования понимание шаблонов и принципов проектирования станет более глубоким. Процесс заключается в том, что сомневаться невозможно, и в результате получается деревня, полная скрытых цветов.
Кроме того, следует отметить, что после того, как вы освоитесь в режиме, не переходите в режим из-за режима 2. Если это выглядит как Хуа Луогэн, известный математик, сказал, что “чтение-это процесс от тонкого к толстому, а затем от толстого к тонкому”. Это значит, что он у тебя есть.
18 принципов отличного программирования
Хорошие принципы программирования тесно связаны с хорошими принципами проектирования. В этой статье кратко излагаются эти принципы проектирования, чтобы помочь разработчикам более эффективно писать код и помочь им стать хорошими программистами. Диггинс-канадский старший техник с 25-летним опытом программирования. Он работал в Microsoft и Autodesk и основал две прибыльные интернет-компании.
1. Сухо – не повторяйтесь
Основной принцип программирования состоит в том, чтобы избегать повторения. В программном коде всегда есть много структур, таких как циклы, функции, классы и так далее. Как только вы повторяете утверждение или концепцию, легко сформировать абстракцию.
2. Абстрактный принцип
Связано с сухим принципом. Помните, что каждая важная функция в программном коде может отображаться только в одном месте исходного кода.
3. Сделайте все просто и запутанно
Простота-это цель разработки программного обеспечения. Простой код занимает меньше времени, имеет меньше уязвимостей и его легко модифицировать.
Избегайте создания YAGNI (он вам не понадобится).
Не создавайте новые функции, если вам это не нужно.
5. Сделайте самую простую вещь, которая может сработать
Сделайте самую простую вещь, которая работает. В программировании обязательно соблюдайте принцип простоты. Как программист, постоянно размышляю над вопросом “как упростить работу?” поможет сохранить простой путь в дизайне.
Не заставляй меня думать
Это название книги Стива Круга, и она также посвящена программированию. Код должен быть легким для чтения и понимания, чтобы другие оценили его и дали вам разумные предложения. Напротив, если программа сложна и трудна для понимания, другие всегда будут избегать ее.
7. Принцип открытия/закрытия
Программные объекты, которые вы пишете (классы, модули, функции и т.д.), Должны быть с открытым исходным кодом, чтобы другие могли разрабатывать. Однако для вашего кода вы должны ограничить, чтобы другие не изменяли его. Другими словами, другие люди могут писать на основе вашего кода, но они не могут изменять ваш код.
8. Напишите код для сопровождающего
Хороший код должен позволить мне или другим продолжать писать или поддерживать его в будущем. Обслуживание кода, возможно, мне будет проще, но для других это более хлопотно. Поэтому убедитесь, что ваш код максимально прост в обслуживании. “Если сопровождающий не будет продолжать поддерживать ваш код, вполне вероятно, что у него возникнет желание убить вас.”
9. Принцип наименьшего удивления
Принцип наименьшего удивления обычно упоминается в пользовательском интерфейсе, но он также применим к написанному коду. Код должен быть как можно меньше, чтобы удивить читателей. Другими словами, код, который вы пишете, должен быть написан только в соответствии с требованиями проекта. Другие великолепные функции не нужны, чтобы не быть обреченным на провал.
10. Принцип единой ответственности
Функция кода должна гарантировать, что существует только одна и определенная задача выполнения.
11. Сведите к минимуму сцепление
Любая часть кода должна в меньшей степени зависеть от кода другого региона. Старайтесь не использовать общие параметры. Низкое сцепление часто является символом совершенной конструктивной системы и превосходного дизайна.
Принцип максимальной сплоченности
Аналогичный код функции должен быть помещен в одну часть, насколько это возможно.
13. Скрыть детали реализации
Принцип сокрытия деталей реализации может свести к минимуму влияние на другие компоненты при изменении других функциональных частей.
14. Закон Димитрия также называют законом Деметры
Код связан только с частями, которые непосредственно связаны с ним. (например: класс, унаследованный от этой части, содержащийся объект, объект, переданный параметром, и т.д.).
15. Избегайте преждевременной оптимизации
Не оптимизируйте, если ваш код не работает медленнее, чем вы думаете. Если вы действительно хотите оптимизировать, вам нужно выяснить, как использовать данные, чтобы доказать, что это быстрее.
“Преждевременная оптимизация — корень всех зол” – Дональд Кнут
16. Повторное использование кода-это хорошо
Повторное использование кода может улучшить читаемость кода и сократить время разработки.
17. Разделение интересов
Функции в разных областях должны состоять из разных кодов и модулей с минимальным перекрытием.
18. Примите перемены
Это название книги Кента Бека, которая также считается принципом экстремального программирования и гибких методов.
Многие другие принципы основаны на концепции, согласно которой вы должны позитивно относиться к переменам. На самом деле некоторые старые принципы программирования, такие как принцип минимальной связи, разработаны для того, чтобы код было легко изменять. Независимо от того, являетесь ли вы экстремальным программистом или нет, написание кода на основе этого принципа сделает вашу работу более значимой.
PHP, PHP, PHP, PHP, PHP, PHP, PHP, PHP, PHP, PHP, PHP, PHP, PHP, PHP, PHP, PHP, PHP, PHP, PHP, PHP, PHP, PHP, PHP, PHP, PHP, PHP, PHP, PHP, PHP, PHP, PHP, PHP, PHP, PHP, PHP Резюме навыков написания
Я надеюсь, что эта статья поможет вам в программировании на PHP.