Форум PHP

С чего вы взяли, что для сервера самым важным будет размер файла?
У Вас больше ни с чем проблем нет?
Я ни разу не встречал проблем с размером файла скрипта. Разве что не удобно мотать вниз-вверх. Да и то современные IDE эту проблему полностью решают. Ну и к нагрузке на сервер это не имеет отношения.
Нагрузка на сервер идет от функционала, а не от размера. Можно и в 1ом килобайте зарядить рекурсивный обход дерева в MySQL и мало не покажется.
Делайте так, чтоб вам было удобно и понятно. Размер файла - это последний вопрос, который вас будет интересовать.

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

Зря вы в абстрактном классе кучу кода нагородили. Он у вас далеко не абстрактный. В абстрактном классе опишите методы, свойства, но возможностями им не давайте, это сделают наследники.

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

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

нет понятие оптимальный размер класса, но есть понятия: читабильность и производительность кода.
Можно давать переменным именна которые будут понятны стороннему($message,$userId и тп.) а можно сокращать объем кода($m,$ui...). Уменьшение лишней писанины раз в 5 приведет к заметному изменению отношения читабельность/скорость. Меня в данной теме инетересовало мнение людей работающих с большими проектами и было интересно тянут ли сервера объем пхп кода более чем в 200-500кБ.

лучший ответ :), спасибо.

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

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

>P.S.Но главный вопрос: оптимальный размер класса. Давайте не будем уходить от темы

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

pageNavigation - и есть отдельный класс
sendMail - пока функционал не предусматривает каких либо расширенных опций кроме как отправки текстовых сообщения
> в нем явно лежит функционал, который должен быть в моделях
согласен, но в нем больше Вида :), это исправляю по-тихоньку
а так прислушаюсь к вашим советам. Может еще кто-нибудь что-нибудь подкинет?

P.S.Но главный вопрос: оптимальный размер класса. Давайте не будем уходить от темы

как по мне, так pageNavigation и sendMail это вообще не из той оперы. это должны быть отдельные классы, никак не связанные с контроллером. pageNavigation это вообще ближе по логике к модели, а sendMail - явно утилиты.
notFound я бы вынес во frontController, в котором бы были как минимум общий конфиг и маршрутизация.
ну и вообще, у вас толстый контроллер, в нем явно лежит функционал, который должен быть в моделях. mvc ради mvc это плохо

p.s обязательно используйте модификаторы доступа public/protected/private. а то код читается плохо, и инкапсуляции как таковой нет (потому что по дефолту public, а им лучше не злоупотреблять как и private).

pp.s я бы меньше загонялся на вашем месте на нагрузке на сервер, а больше уделял бы лаконичности и грамотности кода (если конечно это не высоконагруженное приложение). лучше конечно, чтобы в совокупности была и хорошая производительность, но куда важнее именно читабельность. кому-то в этом коде потом скорее всего придется разбираться, с большой вероятностью Вам же, и если код будет плохим, сопровождаться он будет долго. а время программиста намного дороже компьютерного