Доброй ночи.

Сегодня хотел бы поговорить на тему стилей программирования.
Начнем со следующего:
 В функции обычно выносят повторяющиеся куски кода
 Для удобства можно использовать классы

Так вот где та грань, когда к примеру в классе мы разделяем функцию __construct на несколько частей, при этом зная что функции, которые получились после разделения другой - более использоваться не будут. 
Что бы не быть голословным приведу пример исходного класса:

и пример после разделения:

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

П.С. писал на сонную голову, если что простите .... 

С уважением, Адам.

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

Логически правильные. Почитай про рефакторинг кода.

Хоть я в ООП новичок, но у меня сложилось на данный момент свое ИМХО - на чем больше методов разбит класс, тем продуктивнее будет использоваться наследование. Например, можно написать класс для работы с базой данных. Есть два варианта - написать все в 2 метода, например, коннект к базе и вытягивание данных. А можно - в 10. Если у нас класс из двух методов, наследуя его и переопределяя как раз эти два метода мы никакой пользы не извлекем. А унаследовав класс с 10 методами, и переопределив допустим два, мы как минимум уменьшим время написания  Коротко говоря, чем больше % всех методов нам приходится переопределять в классе-наследнике, тем хуже. Но это далеко не говорит о том, что каждое действие нужно загонять в свой метод  Просто нужно искать золотую середину и перед написанием основного класса задумываться о наследовании этого класса и группировать код по методам, как бы 

Пихать все, что только можно в движок тоже не очень хорошо. Если нужен сайт, состоящий максимум из 2-3 страничек, то, имхо, и движка никакого не нужно   Но если это какой-то портал, игра или чат, то движок должен быть максимально быстр и в то же время максимально эффективен. 
Вот, я сейчас пишу движок-винегрет   Собираю туда все, что только можно..а потом буду чисто выбирать отдельные классы, которые мне понядобятся для того или иного сайта\проекта.

Исповедуйте принцип бритвы Оккама: не плодите функций больше, чем нужно.
Выделять кусок кода в отдельную функцию совершенно точно надо в следующих случаях:

•  Этот кусок кода используется более одного раза
•  Функция занимает более одного экрана
•  Этот код больше подвержен изменениям, чем окружающий его код

Так же следует руководствоваться принципом KISS (Keep It Simple, Stupid).
А баланс между бритвой Оккама и делением на множество методов определить невозможно - его нужно находить для каждого отдельного случая.

С этим я абсолютно согласен, да и поступаю точно так. Так же как и в том слечае. если этот код у меня вызывается не однократно в движке.


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

Обычно делю код в зависимости от требований к приложению. Скажем, надо написать чат, значит, функции или методы должны быть, соответственно, прием сообщений, отправка, валидация, ну и все что потребуется в чате. Если приложение объёмное, стараюсь смотреть вперед. После написания нескольких приложений стараюсь их оценить, увидеть что можно было бы вынести в "ядро", т.е. полезный на будущее код.

Во всём по этой теме согласен с WhiteWind.

Ага, а если эти 2-3 раза используется одинаковый код, размером, скажем хотя бы в 30 строк? Мне лишние строки в коде допустим ни к чему, к тому же, как известно PHP тратит львиную долю времени именно на синтаксическую проверку скрипта, то можно сделать вывод что выделение дублирований в отдельные методы позволит повысить скорость работы приложения.

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

И вот почему:

• Обособлять и инкапсулировать куски кода которые занимаются конкретной задачей (даже если задача такая конкретная, что она не используется более чем в одном месте).
• Четко видно какие переменные нужны для исполнения кода + проверка входных данных.
• И самое важное не засорять глобальное пространство переменными.

это говорит о том что задачу следует разбить мельче

Ну так-же можно разделять код на функции когда написанием занимается более одного человека

один из принципов ООП - "Если считаешь какую-то вещь чем-то отдельным - сделай ее отдельным классом".