Мини-аналитика сайта ООП php

@web-junior · Регистрация: 11.08.2021

Студворк — интернет-сервис помощи студентам

Добрый день, осваиваю ООП php и любую новую задачу пытаюсь решить с его помощью.

Ранее использовала только функциональное программирования. Поэтому у меня есть сайт, личный кабинет которого написан на php, но основан на функциях. Работает и хорошо, но всё-таки хочется уже более профессионального уровня.

Задача в том, что в этом личном кабинете нужно вывести количество уникальных посетителей и визитов из базы данных по определенным параметрам (текущий день, неделя, месяц).

У меня была идея создать два класса, соответственно Посетители и Визиты. Эти два класса будут наследоваться от абстрактного класса Метрики и будут реализовывать метод получения количества.
Далее создать еще один класс Аналитика, который по-идее должен оперировать классами Посетители и Визиты.
Потом я думала, как решать вопрос с периодами с учётом добавления новых в будущем.
Тут классы ТекущийДень, ТекущаяНеделя и ТекущийМесяц. Все три класса реализуют метод, возвращающий период. И класс Период, в котором создаются экземпляры классов периодов и записываются в свойство класса (массив).
Понимаю, что не вижу дальнейшего решения, возможно моя абстракция в корне не верна. Дальше реализация только разрастается и становится уже нерасширяемая.

С функциями решала бы проще. Создала две функции, одна для формирования периодов. А вторая для запросов к базе и соответственно возврата значения. Но это решение опять же невозможно быстро расширить. Допустим нужно будет выводить количество посетителей за вчерашний день, прошлую неделю. Может даже добавится ещё одна метрика, например, количество покупок. Или потребуется не количество, а сумма покупок.

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

Как вообще оценивать задачи с точки зрения решения на ООП? Т.е. я сейчас изучаю основы, решаю задачи по ООП на подобие создать фабрику мебели. Здесь понятно, как решать, а когда неконкретная, а прикладная задача уже сложно.

@Para bellum · 12.08.2021, 06:41

Я считаю, что для вашей задачи использование такого уровня абстракции избыточно. Всю функциональность счётчиков можно заключить в один класс "Счётчики".

@tarasalk · 13.08.2021, 00:29

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

Сообщение от web-junior

Как вообще оценивать задачи с точки зрения решения на ООП? Т.е. я сейчас изучаю основы, решаю задачи по ООП на подобие создать фабрику мебели. Здесь понятно, как решать, а когда неконкретная, а прикладная задача уже сложно.

Суть в том чтобы создавать только те классы и методы, которые наиболее точно выражают бизнес логику. Не надо везде создавать классы просто потому что можешь. Многое можно выразить и через обычные типы такие как строка, число, массив.
Более того, стоит помнить что каждый объект это дополнительные накладные расходы.

@sad67man · 14.08.2021, 01:10

web-junior, В задачах изучают самые базовые механизмы ООП в виде полиморфизма, наследования и т.д. К сожалению зачастую их ставят не лучшим образом, впихивают их ради чтоб впихнуть, в тоже время могут нарушаться другие принципы, о которых начинающий программист еще не знает. Это вредит выработке правильного мышления в ООП парадигме.

Я заметил общую проблему новичков, которые изучая ООП кроме наследования ничего знают и воспринимают ООП как гребаный кроссворд. Знаете как в школе нам давали домашнее задания составить кроссворд - чем больше пересечений, тем лучше - выше оценка. Они начинают тратить уйму времени, придумывая невероятные хитросплетения, чтоб сократить код - потом конечно же гордятся своими результатами)
Проблема заключается в том, что они зафиксировали систему в текущем состоянии, так сказать "сфотографировали" и завязали мертвым узлом. Тут стоит задуматься - а действительно ли отсутствие кода это хорошо? Что именно является хорошим кодом?

Чтоб ответить на этот вопрос - вы должны представить такую ситуацию, что в ваш проект приходит абсолютно левый программист, который совсем не знаком с вашим проектом и не знает предметной области. На сколько быстро он разберется в вашем коде и сможет безопасно внести изменения? Одна из проблем заключается в том, что многие программисты боятся вносить изменения, что могут что-то поломать и в таких ситуациях начинают костылять. Не нужно думать, что задача якобы заранее известна, а вы лишь пишете ее реализацию. Когда вы пишете код - вы как-бы рассказываете повествование для других будущих (в том числе и себя) программистов - он должен быть максимально очевидным, и не вызывать сомнений, что если здесь что-то изменить, то может что-то поломаться. Вы должны именно отразить то, как этот код работает на данный момент. Не стоит задумываться и делать заготовки на будущее - вы никогда не угадаете) Поверьте моему опыту - когда приходит время, все оказывается совсем не так, как вы могли себе предположить)

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

В реальных проектах ООП в первую очередь используется для построения архитектуры приложения. Код можно написать как угодно, и это будет работать. Проблемы начинаются, когда его нужно изменить - мы сталкиваемся с множествами проблемами:

1) Монолит, сильно связанный код. Чтоб сделать простейшее изменение - необходимо буквально изучить всю систему, которая настолько огромна, что не помещается в вашу голову.
2) Запутанный, хитросплетенный код. При малейшем изменении есть риск повредить уже работающие части нашей системы. Мы получаем бесконечные баги.
3) Низкоуровневый, сложночитаемый код, стоимость поддержки. Скорость печатания не влияет на скорость разработки, ведь большую часть времени программист читает окружающий код, даже тот, который он только что написал. Имеется в виду не то, что его в принципе трудно прочитать - а то, что при его чтении необходимо его каждый раз разбирать, держать в голове много лишней информации, тратя на это время и умственные ресурсы. В идеале должно быть достаточно одного взгляда, чтоб понять, что этот код делает, и то, что он 100% работает, т.е. он настолько очевидный, что не дает повода засомневаться в его работоспособности.

Это далеко не весь список проблем. Мы не нострадамусы, и нам трудно предположить, каким образом будет меняться программа, и с какими проблемами мы столкнемся. Большинство проблем далеко не очевидны и кроются как мины замедленного действия, которые в один момент могут привести к краху.

По сути ни один человек не сделал ни одного открытия с нуля. Все величайшие открытия базировались на многолетней работе и опыте тысячи людей. Невозможно просто так внезапно придумать телевизор или фотоаппарат - прошли тысячелетия от изучения простейших моделей анимационных и оптических эффектов/свойств.

Так же и в программировании, многолетняя практика тысячи программистов набивания шишек, попытки решить те или иные проблемы и обмен опытом родили некие принципы, следуя которым вы избежите большинство проблем. Такие как SOLID, GRASP, DRY, YAGNI, DDD... и еще куча букв. Каждая буква это не просто аббревиатура - это целая философия, про каждую из них есть целые книги). Все они сводятся так или иначе к деньгам, их так просто бы не придумали. Нужно в них верить и тогда сможете в итоге познать их целесообразность.

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

@cia · 16.08.2021, 14:23

Да, набор предлагаемых классов очень раздутый. Обычно на сайте всегда есть такая сущеность как "пользователь". Если её нет, то в качестве рефакторинга я бы предложил реализовать. К этому классу можно добавить статический метод получения количества посетителей, вот и всё.

Осмелюсь порекомендовать изучение шаблонов программирования, например тут.
Только не делайте ошибку, которую допускают многие: не нужно старательно искать где применить эти патерны и не нужно их применять шаблонно. Это не руководство к действию, а сборник удачных решений часто возникающих задач. В "чистом виде" эти решения не должны применяться, лучше просто помнить об их существовании и когда возникнет схожая задача вы будете знать куда копать.

@tarasalk · 16.08.2021, 16:18

Сообщение от cia

К этому классу можно добавить статический метод получения количества посетителей, вот и всё.

Это путь к будущему божественному классу

@web-junior · 17.08.2021, 09:01 **[ТС]**

Добрый день. Спасибо за ответы. Да, реализация действительно избыточна. Попробовала создать один класс и в нём несколько методов, в т.ч. и статических. Однако столкнулась с ajax-запросом и не поняла, как его использовать в моём случае. В итоге, опять решила задачу с помощью функций. Конечно, такой код никому не покажешь(

@Para bellum · 17.08.2021, 09:42

Сообщение от web-junior

столкнулась с ajax-запросом и не поняла, как его использовать в моём случае

А как способ HTTP-запроса из браузера может усложнить использование того или иного объекта в PHP-скрипте?
Правильно, никак.

В чём ваша ошибка, сказать невозможно, не увидев код.

@web-junior · 17.08.2021, 10:37 **[ТС]**

Сообщение от Para bellum

В чём ваша ошибка, сказать невозможно, не увидев код.

вот такой класс Counter я создала. Немного сократила реализацию, для получения посетителей и визитов одинаковые функции.

PHP
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
<?php
class Counter 
{
    private $times = [];
 
    public static $connection;    
 
    public static function Request($rqst, $param = null)   // запрос к базе данных
    {
        if($stmt = static::$connection->prepare($rqst))
        {
            if($param !== null) 
            {
                $stmt->bind_param("s", $param);
            }
            
            $stmt->execute();
            $rsp = $stmt->get_result();
 
            if($rsp->num_rows > 0) 
            {
                return $rsp->fetch_array(MYSQLI_ASSOC);
            }
        }        
    }
 
    public function __construct($connection)
    {
        $this->setupTimes();
        static::$connection = $connection;
    }
 
    private function setupTimes()   // установка временных периодов
    {
        $this->times["now"] = [
            "name" => "Сегодня",
            "date" => date("Y-m-d")
        ];
 
        $this->times["yesterday"] = [
            "name" => "Вчера",
            "date" => date("Y-m-d", strtotime("-1 day"))
        ];
 
        $this->times["now_month"] = [
            "name" => "Текущий месяц",
            "date" => date("Y-m")
        ];
 
        $this->times["last_month"] = [
            "name" => "Предыдущий месяц",
            "date" => date("Y-m", strtotime("-1 month"))
        ];
    }
 
    public function getVisits()   // получение визитов
    {
        $visits = [];
 
        foreach($this->times as $time)
        {
            $visits["Визиты"][$time["name"]] = static::Request(
                "sql запрос",
                $time["date"]
            );
        }
 
        return $visits;
    }
 
    public function getLastVisits()    // получение последнего визита
    {
        return static::Request("sql запрос");
    }
}

В index.php в папке модуля вот этой мини-аналитики создаю экземпляр класса. И вызываю метод getVisits.
Потом подключаю файл viewReport.php и распределяю данные из полученного массива по верстке.

Но пользователю должна быть предоставлена возможность строить график, переключая периоды: текущий месяц, прошлый месяц (в процессе реализации добавился ещё и год). Т.е. при нажатии на определенную кнопку я должна вызывать метод getVisits с параметром (тут я не реализовывала, поскольку не поняла, как дальше), а точнее отправить ajax запрос. Вот здесь я окончательно запуталась, если отправлю на index.php, то у меня получается пересоздастся экземпляр класса...

@Para bellum · 17.08.2021, 11:54

1) Уберите статику, тут ей не место.
2) Свойство $connection сделайте приватным.
3) Вот этим times в данном классе не место. Он должен отвечать только за возвращение кол-ва визитов/посещений/товаров и т.п. за указанный ему извне период.
Представьте, что этот класс -- бухгалтерия огромной фирмы. Теперь подумайте, должна ли бухгалтерия сама определять даты, за которые она хочет выдавать те или иные выписки?

К тому же, если грамотно вынести массив times в другое место, его можно будет повторно использовать в шаблоне, где пользователю должна быть предоставлена возможность строить график, переключая периоды.

Сообщение от web-junior

Вот здесь я окончательно запуталась, если отправлю на index.php, то у меня получается пересоздастся экземпляр класса

Всё правильно. К моменту, когда клиент сможет в браузере переключать периоды, текущий процесс уже будет завершён.
AJAX-запрос спровоцирует запуск нового процесса, который тоже уже будет мёртв, когда в браузер вернутся от него данные.
Почитайте вот это: http://phpfaq.ru/newbie/na_tanke

@web-junior · 17.08.2021, 14:02 **[ТС]**

Спасибо. Обязательно попробую так сделать. Сейчас уже понятнее стало)

@cia · 17.08.2021, 14:33

Сообщение от tarasalk

Это путь к будущему божественному классу

Да, верно. Но не забывайте контекст, в котором был задан вопрос. Речь явно идёт о чём-то простом, поэтому раздуваться тут нечему. И в таком контексте, по-моему скромному мнению, следует выбирать наиболее простой путь.

@tarasalk · 17.08.2021, 16:33

cia, так контекст как раз таки изучение ООП, а по простому она и на функциях напишет)
И непонятно в чем тут упрощение. В том что отдельный файл не создали? Ну такое)

@OpXiv · 22.08.2021, 20:48

Сообщение от tarasalk

В том что отдельный файл не создали? Ну такое)

Знаю одного человека, который себя чтит как гуру. Он в 1 файле за 4 месяца написал 20 тысяч строк кода. Когда я спросил - зачем???? Он сказал - мне лень было создавать новые файлы

Добавлено через 1 минуту

Сообщение от OpXiv

20 тысяч строк кода

На новеньком PHP8 с JIT. Свой 3D простенький движок. Для визуализации моделей, что бы просматривать интерьеры квартир.

У каждого свои тараканы)))

@sad67man · 23.08.2021, 17:07

Сообщение от OpXiv

Он сказал - мне лень было создавать новые файлы

Через IDE создать класс - это секундное дело. Мне трудно такое представляется для человека, привыкшего работать в ООП стиле. Тем более он сам признал, что это не правильно - ему просто лень)

@OpXiv · 23.08.2021, 17:11

Сообщение от sad67man

Через IDE создать класс - это секундное дело.

А потом нужно прописывать namespace и прочее. Тут в этом смысле ему лень было)

@sad67man · 23.08.2021, 18:07

Сообщение от OpXiv

А потом нужно прописывать namespace и прочее. Тут в этом смысле ему лень было)

namespace прописывается автоматически.

Новые блоги и статьи Все статьи Все блоги /
Модель заражения группы наркоманов alhaos 17.04.2026 Условия задачи сформулированы тут Суть: - Группа наркоманов из 10 человек. - Только один инфицирован ВИЧ. - Колются одной иглой. - Колются раз в день. - Колются последовательно через. . .	Мысли в слух. Про "навсегда". kumehtar 16.04.2026 Подумалось тут, что наверное очень глупо использовать во всяких своих установках понятие "навсегда". Это очень сильное понятие, и я только начинаю понимать край его смысла, не смотря на то что давно. . .	My Business CRM MaGz GoLd 16.04.2026 Всем привет, недавно возникла потребность создать CRM, для личных нужд. Собственно программа предоставляет из себя базу данных клиентов, в которой можно фиксировать звонки, стадии сделки, а также. . .	Знаешь почему 90% людей редко бывают счастливыми? kumehtar 14.04.2026 Потому что они ждут. Ждут выходных, ждут отпуска, ждут удачного момента. . . а удачный момент так и не приходит.
Фиксация колонок в отчете СКД Maks 14.04.2026 Фиксация колонок в СКД отчета типа Таблица. Задача: зафиксировать три левых колонки в отчете. Процедура ПриКомпоновкеРезультата(ДокументРезультат, ДанныеРасшифровки, СтандартнаяОбработка) / / . . .	Настройки VS Code Loafer 13.04.2026 { "cmake. configureOnOpen": false, "diffEditor. ignoreTrimWhitespace": true, "editor. guides. bracketPairs": "active", "extensions. ignoreRecommendations": true, . . .	Оптимизация кода на разграничение прав доступа к элементам формы Maks 13.04.2026 Алгоритм из решения ниже реализован на нетиповом документе, разработанного в конфигурации КА2. Задачи, как таковой, поставлено не было, проделанное ниже исключительно моя инициатива. Было так:. . .	Контроль заполнения и очистка дат в зависимости от значения перечислений Maks 12.04.2026 Алгоритм из решения ниже реализован на примере нетипового документа "ПланированиеПерсонала", разработанного в конфигурации КА2. Задача: реализовать контроль корректности заполнения дат назначения. . .

@web-junior 0 / 0 / 0 Регистрация: 11.08.2021 Сообщений: 17

	Мини-аналитика сайта ООП php 11.08.2021, 22:50. Показов 3487. Ответов 16 Метки php, ООП (Все метки) Добрый день, осваиваю ООП php и любую новую задачу пытаюсь решить с его помощью. Ранее использовала только функциональное программирования. Поэтому у меня есть сайт, личный кабинет которого написан на php, но основан на функциях. Работает и хорошо, но всё-таки хочется уже более профессионального уровня. Задача в том, что в этом личном кабинете нужно вывести количество уникальных посетителей и визитов из базы данных по определенным параметрам (текущий день, неделя, месяц). У меня была идея создать два класса, соответственно Посетители и Визиты. Эти два класса будут наследоваться от абстрактного класса Метрики и будут реализовывать метод получения количества. Далее создать еще один класс Аналитика, который по-идее должен оперировать классами Посетители и Визиты. Потом я думала, как решать вопрос с периодами с учётом добавления новых в будущем. Тут классы ТекущийДень, ТекущаяНеделя и ТекущийМесяц. Все три класса реализуют метод, возвращающий период. И класс Период, в котором создаются экземпляры классов периодов и записываются в свойство класса (массив). Понимаю, что не вижу дальнейшего решения, возможно моя абстракция в корне не верна. Дальше реализация только разрастается и становится уже нерасширяемая. С функциями решала бы проще. Создала две функции, одна для формирования периодов. А вторая для запросов к базе и соответственно возврата значения. Но это решение опять же невозможно быстро расширить. Допустим нужно будет выводить количество посетителей за вчерашний день, прошлую неделю. Может даже добавится ещё одна метрика, например, количество покупок. Или потребуется не количество, а сумма покупок. Подскажите, пожалуйста, как бы вы решали такую задачу именно на ООП? Как вообще оценивать задачи с точки зрения решения на ООП? Т.е. я сейчас изучаю основы, решаю задачи по ООП на подобие создать фабрику мебели. Здесь понятно, как решать, а когда неконкретная, а прикладная задача уже сложно. 0

@Para bellum 5755 / 4134 / 1508 Регистрация: 06.01.2011 Сообщений: 11,276
	12.08.2021, 06:41
	Я считаю, что для вашей задачи использование такого уровня абстракции избыточно. Всю функциональность счётчиков можно заключить в один класс "Счётчики". 0

@sad67man 2604 / 1508 / 689 Регистрация: 23.08.2015 Сообщений: 3,839
	14.08.2021, 01:10
	web-junior, В задачах изучают самые базовые механизмы ООП в виде полиморфизма, наследования и т.д. К сожалению зачастую их ставят не лучшим образом, впихивают их ради чтоб впихнуть, в тоже время могут нарушаться другие принципы, о которых начинающий программист еще не знает. Это вредит выработке правильного мышления в ООП парадигме. Я заметил общую проблему новичков, которые изучая ООП кроме наследования ничего знают и воспринимают ООП как гребаный кроссворд. Знаете как в школе нам давали домашнее задания составить кроссворд - чем больше пересечений, тем лучше - выше оценка. Они начинают тратить уйму времени, придумывая невероятные хитросплетения, чтоб сократить код - потом конечно же гордятся своими результатами) Проблема заключается в том, что они зафиксировали систему в текущем состоянии, так сказать "сфотографировали" и завязали мертвым узлом. Тут стоит задуматься - а действительно ли отсутствие кода это хорошо? Что именно является хорошим кодом? Чтоб ответить на этот вопрос - вы должны представить такую ситуацию, что в ваш проект приходит абсолютно левый программист, который совсем не знаком с вашим проектом и не знает предметной области. На сколько быстро он разберется в вашем коде и сможет безопасно внести изменения? Одна из проблем заключается в том, что многие программисты боятся вносить изменения, что могут что-то поломать и в таких ситуациях начинают костылять. Не нужно думать, что задача якобы заранее известна, а вы лишь пишете ее реализацию. Когда вы пишете код - вы как-бы рассказываете повествование для других будущих (в том числе и себя) программистов - он должен быть максимально очевидным, и не вызывать сомнений, что если здесь что-то изменить, то может что-то поломаться. Вы должны именно отразить то, как этот код работает на данный момент. Не стоит задумываться и делать заготовки на будущее - вы никогда не угадаете) Поверьте моему опыту - когда приходит время, все оказывается совсем не так, как вы могли себе предположить) И такой поток левых программистов может быть достаточно большой - и вы устанете объяснять все ваши хитросплетения, что если ты хочешь сделать какую-то вещь, то нужно почесать правое ухо левой пяткой. В реальных проектах ООП в первую очередь используется для построения архитектуры приложения. Код можно написать как угодно, и это будет работать. Проблемы начинаются, когда его нужно изменить - мы сталкиваемся с множествами проблемами: 1) Монолит, сильно связанный код. Чтоб сделать простейшее изменение - необходимо буквально изучить всю систему, которая настолько огромна, что не помещается в вашу голову. 2) Запутанный, хитросплетенный код. При малейшем изменении есть риск повредить уже работающие части нашей системы. Мы получаем бесконечные баги. 3) Низкоуровневый, сложночитаемый код, стоимость поддержки. Скорость печатания не влияет на скорость разработки, ведь большую часть времени программист читает окружающий код, даже тот, который он только что написал. Имеется в виду не то, что его в принципе трудно прочитать - а то, что при его чтении необходимо его каждый раз разбирать, держать в голове много лишней информации, тратя на это время и умственные ресурсы. В идеале должно быть достаточно одного взгляда, чтоб понять, что этот код делает, и то, что он 100% работает, т.е. он настолько очевидный, что не дает повода засомневаться в его работоспособности. Это далеко не весь список проблем. Мы не нострадамусы, и нам трудно предположить, каким образом будет меняться программа, и с какими проблемами мы столкнемся. Большинство проблем далеко не очевидны и кроются как мины замедленного действия, которые в один момент могут привести к краху. По сути ни один человек не сделал ни одного открытия с нуля. Все величайшие открытия базировались на многолетней работе и опыте тысячи людей. Невозможно просто так внезапно придумать телевизор или фотоаппарат - прошли тысячелетия от изучения простейших моделей анимационных и оптических эффектов/свойств. Так же и в программировании, многолетняя практика тысячи программистов набивания шишек, попытки решить те или иные проблемы и обмен опытом родили некие принципы, следуя которым вы избежите большинство проблем. Такие как SOLID, GRASP, DRY, YAGNI, DDD... и еще куча букв. Каждая буква это не просто аббревиатура - это целая философия, про каждую из них есть целые книги). Все они сводятся так или иначе к деньгам, их так просто бы не придумали. Нужно в них верить и тогда сможете в итоге познать их целесообразность. На данный момент я устал все это писать, позже распишу подробнее, в чем заключается ошибка ваших суждений. 2

@cia 100 / 70 / 26 Регистрация: 19.12.2014 Сообщений: 332
	16.08.2021, 14:23
	Да, набор предлагаемых классов очень раздутый. Обычно на сайте всегда есть такая сущеность как "пользователь". Если её нет, то в качестве рефакторинга я бы предложил реализовать. К этому классу можно добавить статический метод получения количества посетителей, вот и всё. Осмелюсь порекомендовать изучение шаблонов программирования, например тут. Только не делайте ошибку, которую допускают многие: не нужно старательно искать где применить эти патерны и не нужно их применять шаблонно. Это не руководство к действию, а сборник удачных решений часто возникающих задач. В "чистом виде" эти решения не должны применяться, лучше просто помнить об их существовании и когда возникнет схожая задача вы будете знать куда копать. 1

@web-junior 0 / 0 / 0 Регистрация: 11.08.2021 Сообщений: 17
	17.08.2021, 09:01 [ТС]
	Добрый день. Спасибо за ответы. Да, реализация действительно избыточна. Попробовала создать один класс и в нём несколько методов, в т.ч. и статических. Однако столкнулась с ajax-запросом и не поняла, как его использовать в моём случае. В итоге, опять решила задачу с помощью функций. Конечно, такой код никому не покажешь( 0

@web-junior 0 / 0 / 0 Регистрация: 11.08.2021 Сообщений: 17
	17.08.2021, 14:02 [ТС]
	Спасибо. Обязательно попробую так сделать. Сейчас уже понятнее стало) 0

@tarasalk 1992 / 1216 / 440 Регистрация: 13.06.2013 Сообщений: 4,115
	17.08.2021, 16:33
	cia, так контекст как раз таки изучение ООП, а по простому она и на функциях напишет) И непонятно в чем тут упрощение. В том что отдельный файл не создали? Ну такое) 0

Мини-аналитика сайта ООП php

Решение