Max Ba

Я полностью согласен с предыдущими ораторами.

Мне нужно, чтобы метод внутри класса могу работать внутри другого метода.

Перечитывайте перед публикацией )

ООП это не стиль, это парадигма.
Ее можно использовать для написания программ практически любого размера, но неудобно для мелких скриптов.
Стиль это скорее нотации, типа CamelNotation

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

Суть ООП и функционального программирования только в том, как располагать куски кода - по функциям или по методам. Но ограничение доступа связано ни с функцией ни с методом, а с тем, как вы это ограничение реализовали.

Главная идея ООП заключается вот в чем:

Есть данные. Мы их инкапсулирем в класс.
Есть методы, которые манипулируют именно этими данными. Поэтому методы должны тоже находиться в классе с данными.

Если нам приходится добавлять данные, менять их тип и формат, в случае с ООП мы легко правим методы, которые находятся в этом же классе. Можем написать новые методы, можем переделать старые, можем совместить. В случае с функциональным программированием, затраты на переделку программы будут гораздо дороже и запутаннее.

ООП предназначена, чтобы структурировать код так, чтобы новые возможности вносились малой кровью и позволяет писать меньше кода. Класс "товар" имеет, к примеру, цену и наличие - этот класс будет родителем всех товаров. Дольше расширяем класс "товар", создаём несколько детей: "фототехника", "телефоны" и т.п. Берём класс "фототехника" и создаём детей, которые символизируют производителей (тут можно сразу ввести их сайт и какие либо данные помимо). Далее расширяем класс производителя по его моделям - тут забиваем оставшиеся параметры. Теперь, чтобы добавить ещё какой либо товар из созданных групп, нужно только расширить класс последнего родителя, соответственно кода писать намного меньше. Ну это чисто для пониманию зачем и почему

1) Конечно удобно. Еще удобнее использовать фрейм-ворки, которые (все) используют ооп
2) Можно использовать синглтон (шаблон singleton) и в нём уже контролировать кол-во запросов. Однако тут я немного могу ошибаться (ибо сложно узнать откуда пришёл запрос: из сообщений или из загрузки страницы)
3) в самописных cms лучше использовать MVC. Тут уже идёт разделение на модели (товар, хлебные крошки), вьюхи (страница, ветрина, меню) и контроллеры, которые связывают это.

Ответил на все два вопроса ;-)

Говорит, привыкай к классам, но я не очень нахожу в данном случае им применение.

Конечно. Потому что ты не знаешь для чего они нужны, ты еще не умеешь мыслить объектами и начальник твой все же в большей степени прав. ООП надо понимать и знать. Читай книгу "гради буч объектно-ориентированный анализ и проектирование скачать pdf"

Просит создать вместо 7 функций - 7 классов.

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

Мои функции все равно не пересекаются с именами других, тк имеют уникальный префикс

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

зачем усложнять

готов поспорить, твой код и так сложен, даже без классов.

Тоже раньше не понимал зачем нужны классы и ООП если и так всё работает. Попытки вникнуть в тему по статьям, приводимым в инете (объснения на каких то стульях, столах, человеках, студентах и т.д.) результата не давали.
Потом просто попробовал что то написать с применением ООП. Что то мелкое... Поверхностно освоил наследование, конструкторы, статические методы и т.д. Когда писал мало задумывался о результате и удивился, когда всё заработало с первого раза как надо! До этого приходилось долго вылавливать логические ошибки и отлаживать.
Потом по живому коду других людей понял как надо писать ООП. Начал развивать в себе это объектное понимание и заметил что реально код содержит в разы меньше ошибок, неточностей и, если что то идет не так, то я примерно понимаю где произошла ошибка.
Так что просто начните использовать ООП и сами поймёте зачем оно нужно, но вначале, надо себя заставить ;)

напишите функцию, которая берет файл с кодом php и перегоняет все отдельные функции в классы и наоборот. а вообще если аргумент начальника в том, чтобы вы учились новому, то я с ним соглашусь

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

Структура нормальная. Говорю как человек, который использует такую же более чем на 10 миллионах строк с голосами.
Единственное, я бы делал запрос на выборку голосов не select * , а select user,val ведь id его голоса нам не нужен, а item у всех строк одинаковый. Ну, и пересчитывал бы рейтинг мероприятия всё таки при каждом голосовании, а не при просмотре результатов (хотя это зависит от того, что будет происходить чаще).
И чтобы проверять, гословал ли данный юзер за данное мероприятие, не помешает еще составной индекс по (user,item).

Вроде все правильно, а 1 000 000 при вашей структуре это совсем немного.

Вам нужен php.net/manual/ru/book.imagick.php
Там есть различные методы, некоторые кропят и уменьшают с средним качеством а некоторые как PS.
Но вы должны понимать, что при хорошем качестве будет и хорошая нагрузка.

$i = new \Imagick($target);
// По сути сначала вы делаете кроп 
$i->cropImage(...);
// Затем уменьшаете без потери качества
$i->ThumbnailImage($width, $height, true);

Вот, есть хороший обзор/урок sunnyblik.livejournal.com/39172.html?page=1

Строго личное мнение - алгоритм алгоритму рознь, я, например, в свое время тестил несколько разных подходов, библиотек, сталкивал GD с Imagick и т.д. - разница ощущалась.

Насчет фотошопа - думается мне, что просто ADOBE, будучи крутыми разработчиками и долго занимаясь своим продуктом, доработали или переработали алгоритмы сжатия jpeg.

Могу ошибаться.

imagejpeg() - качество не указываете? по умолчанию около 75.
imagecopyresampled - если вы ресайзите, это тоже может побить картинку.

В фотошопе намного шире выбор алгоритмов сжатия, GD и близко не стоит. В imagemagick получше, но до фотошопа далеко.
https://foliovision.com/2010/03/imagemagick-vs-gd

Гугл и яндекс с некоторого времени шифруют свои запросы