Обновить
19
0
Вячеслав Stac Мацнев@Stac

Пользователь

Отправить сообщение
А… в таком случае, в моем примере это есть.

$STATE["db"] = get_db_object();

Я понимаю, что для вас такой синтаксис не привычен. Здесь в свойство db объекта «Приложение» записывается объект «База данных», реализация которого может быть любой.

Ушел читать Мартина.
Вы как делаете в своих проектах?
Ожидал услышать что-то типа «text-indent».
Когда писал вопрос, вдруг вспомнил об этом свойстве, но также и то, что не применял его уже несколько лет.
Хорошо, «глобальный словарь» и «реестр» это разные слова. Но означают они что-то близкое, если не одно и то же. И туда и сюда можно положить данные и извлечь, и можно сделать это из любого места программы.

Метод, читающий что-то откуда-то, в норме не относят к порождающим паттернам


Что тут имеется в виду? Данные в программу вводятся извне, в любом случае, что-то откуда-то прочитается: от пользователя, из конфига, из хранилища. Да и и get_page_by_uri_from_somewhat_storage() сам не читает ничего, а вызывает другие функции.
Это далеко от моих реальных задач. Когда я читаю подобное, мне сложно представить, где я могу это применить в своих проектам. От того и не воспринимается информация…

Хочется увидеть живые примеры живых людей, которые в настоящих проектах что-то делали и могут еще объяснить, что они сделали и зачем.

Потому и пытаю всех вопросами.
Вы, похоже, говорите тут о суперглобальных переменных.
Вот отличии от суперглобальной $_GET, имеющей тип массива, обычная глобальная переменная может быть экземпляром какого-то (любого) класса со своим сеттером.
Не очень.

Понятно в той части, что конкретные классы должны наследоваться от абстрактных классов или интерфейсов.
И что нужно это для того, чтобы методы, принимающие объекты в качестве параметров могли принимать объекты не одного конкретного класса, а всех классов какой-то ветви иерархии.
А это, в свою очередь, нужно нужно чтобы упростить методы из предыдущего предложения и избежать их дублирования.

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

Этих великих деятелей, упомянутых вами, не читал. Не мой уровень, не дорос.
Но я пробовал читать Мэта Зандстру «PHP. Объекты, шаблоны и методики программирования» (не смог оценить шедевра) и сейчас начал читать Sanders W. — Learning PHP Design Patterns. Успел узнать о порождающих шаблонах фабрика и прототип. Но примеры там тоже не очень ясные.
Понятнее не стало :) Видимо, я дальше от тему, чем мне казалось. Буду гуглить.
Вообще есть такие задачи:
— ввод данных от пользователя
— вычисления (реализация бизнес-логики)
— хранения входных данных
— хранение промежуточных и окончательных результатов вычислений
— генерация HTML- (XML-, JSON-, ...) представления окончательных результатов вычислений
— вывод данных пользователю.

Какие паттерны подходит для их решения? Если несколько, то каким отдавать предпочтение и в каких случаях?

Ссылки можно не давать, интересует ваше (или тех, кто найдет смелость ответить на коммент) мнение и опыт.
Там реализация… а мне не понятно, зачем это вообще.
Тут нет сарказма. Насколько я в курсе в PHP конструктор класса вызывается с помощью оператора new и никак иначе его вызвать нельзя. И оператор new для других целей не применяется.

Но вообще, я не силен в ООП, могу и ошибаться.

Я ниже привел фрагмент кода. Давайте его обсудим, помогите разобраться.
Мы изучаем паттерны, поэтому задача обратная — понять, какие прикладные задачи с помощью какого паттерна решаются и как.
Покажите DI на простом реалистичном примере, пожалуйста.
Да неужели :)?

<?php
var_dump(new StdClass()); //returns: object(stdClass)#1 (0) { }
Я знаю две проблемы с глобальными переменными:
1) конфликт имен
2) условно неопределенное поведение при импортировании ключей суперглобальных массивов в глобальную таблицу имен.

Первую проблему решают префиксы и пространства имен.
Вторая проблема решена отказом от директивы register_globals в PHP 5.4.

Отказываться от глобальных переменных я бы пока не стал.
Признаю, в данном примере мало смысла. Здесь использование этого шаблона не оправдано. Я просто хотел показать его смысл.


А-аа--аа-аа! (крик души).

Я, кстати, целевая аудитория статьи. Кучу всего уже читал про паттерны, но до сих пор с трудом понимаю приводимые в статьях примеры и как они связаны с, например, вебсайтами (много процентов из которых на PHP).

Взять хотя реестр и пул объектов, вроде бы понятные сущности.
Я использую их для хранения состояния приложения.

Чтобы отстраниться от стереотипов, назовем его $STATE.

Подскажите, Благородные Доны, правильно ли я вижу паттерны в нижеследующем примитивном, но более приближенном к земле, как мне кажется, примере:

1) $STATE = array() — «реестр», он же «пул объектов» (db, page), он же «синглтон» (ибо глобальная переменная).
2) get_page_by_uri_from_somewhat_storage() — «фабрика» (или абстрактная?). Или это вообще «Строитель»?

<?php
require_once "classes/DB_Fabric.php";
require_once "classes/Renderer_Fabric.php";

$STATE = array();

$STATE["config"] = include "path/to/config.php";
$STATE["uri"]    = $_SERVER["REQUEST_URI"];
$STATE["db"]     = get_db_object();
$STATE["page"]   = get_page_by_uri_from_somewhat_storage();
$STATE["output"] = render_page();

echo $STATE["output"];
exit();

function get_db_object(){  // Возвращает объект "База данных" для текущего uri согласно конфигурации.
    global $STATE;
    
    return new DB_Fabric($STATE["config"]["db"], $STATE["uri"] );
}
function get_page_by_uri_from_somewhat_storage(){  // возвращает объект "Текущая страница" 
    global $STATE;

    if ( is_page_on_filesystem() ){
        return load_page_from_filesystem();
    } elseif( is_page_in_db() ) {
        return get_page_from_db();
    } else {
        return get_404_page();
    };
};
function is_page_on_filesystem(){
    global $STATE;
    
    $page_filename = $S["state"]["config"]["path_to_pages"] . $STATE["uri"];
    
    return is_readable($page_filename);
};
function load_page_from_filesystem(){
    global $STATE;
    
    return file_get_contents( $S["state"]["config"]["path_to_pages"] . $STATE["uri"] );
};
function is_page_in_db(){
    global $STATE;
    
    if ( $STATE["db"]->find("page", "by_uri", $STATE["uri"]) ) return true;
    else return false; 
};
function get_page_from_db(){
    global $STATE;
    
    return $STATE["db"]->find("page", "by_uri", $STATE["uri"]);
}
function render_page(){  //Возвращает представление страницы для User-Agent, используя подходящий renderer для текущего uri согласно конфигурации
    global $STATE;
    
    $renderer = new Renderer_Fabric( $STATE["config"], $STATE["uri"] );
    return $render->render( $STATE["page"]->data );
}


Покритикуйте мой пример.

Как его можно доработать, чтобы продемонстрировать другие порождающие шаблоны? Или другие тут не нужны?

А поподробнее?
Я просто активно использую sqlite. Разве может быть что-то удобнее? Наверное. Но уж никак не MySQL.
Готов признать свою ошибку, если вы что-то интересное расскажете.
article и section сурово ломают мозг.
Каждая вторая статья на эту тему утверждает, что section объединяет article и другие элементы в нечто цельное, а каждая первая утверждает обратное, мол, section делит article или другие элементы на части.

Отдельные авторы говорят о правомерности использования обоих подходов.

Хуже всего, что этот плюрализм мнений как-бы намекает, что сами авторы этих элементов не вполне понимают их сути.

Пример кода в wiki статье про article показывает несколько article вложенных в section.
А пример кода в статье про section показывает… та-дам!… несколько section вложенных article.

Мы видим использование обоих подходов, но не ясно, допускается (рекомендуется) ли их одновременное использование в одном документе.

Зато ясно следующее:
The <article> element represents an independent item section of content.

The <section> element represents a generic section of a document or application.

Выделения в цитатах из wiki W3C мои.
Странно, я думал сами разработчики и делают версии для PortableApps. Лучше бы им тогда повысить корректность своей программы.
Просто PortableApps это какая-никакая, но инфраструктура и весьма удобная.

Информация

В рейтинге
Не участвует
Откуда
Москва и Московская обл., Россия
Дата рождения
Зарегистрирован
Активность