[Новичок] PHP OOP появились сомнения. Что делать и как быть?
Приветствую разработчиков!
Довольно давно занимаюсь программированием на PHP, но некоторое время назад попробовал Java, а затем C# и был в восторге от ООП и строгой типизации. Оттого и решил заняться "подтягиванием" знаний, решил так сказать, попробовать ООП в PHP. И вроде как даже получается, основные концепции ООП вроде как понимаю, паттерны так же, но со временем начали появляться вопросы с тем правильно ли я делаю или нет, знакомых гуру у меня нет поэтому решил попытаться с сообществом тостера.
1) Правильно ли это утверждение "не стоит применять паттерны абсолютно везде где пахнет малейшим ООП"?
2) Правильно ли для каждой элементарной сущности будь то комментарий, пост или пользователь создавать отдельный объект Comment, Post, User или File которые будут содержать в себе какую либо информацию для использования в обработчике. Например User в качестве аргумента конструктора AuthHandler или File в качестве аргумента одного из методов ImageHandler?
3) Сколько максимально стоит использовать аргументов для конструктора и для методов (чтобы было читабельно и "правильно")?
4) Правильно ли использовать связку менеджер базы данных -> элементарная сущность для каждой такой сущности: Например: class UserManager extends Db и class User (конструктор принимает UserManager и распихивает по полям данные. Ну или сама по себе сущность File в которую можем запихнуть бинарные данные (тут мы не ведем речь о базе данных)
1. Паттерны как и любые вещи в программировании стоит применять только там, где это требуется, а не абсолютно везде. К каждой задаче нужно подбирать свой инструмент
2. Да это нормальная практика. Но тут нужно понимать как Вы с ними будете работать
3. Думаю не более 3-4, в противном случае будет не очень читабельно и удобно работать.
4. Нет. Для работы с базой данных у Вас должен быть реализовать отдельный класс. А уже сущность должна его использовать для получения данных
А менеджер собственно нужен для того чтобы дергать данные из базы по заранее заготовленным параметрам, например activeUsers выполняет запрос к базе который выводит всех активных пользователей (длинное выражение SQL)
Не совсем правильно выразился. Класс сущности не должен наследоваться от класса DB - он должен его использовать. Вообще в этой ситуации я бы рекомендовал применить паттерн ActiveRecord
Максим Федоров: а как быть с сущностью File при использовании ActiveRecord (напомню, этой сущности не существует в базе данных) оно будет находиться в том же неймспейсе что и допустим User?
это относится к ответу на первый вопрос. Не нужно слепо следовать паттернам, например "каждая сущность должна быть построена по принципам ActiveRecord". Если у Вас сущность должна взамодействовать с базой - применение этого паттерна допустимо, если нет - то и паттерн применять не стоит.
1. Паттерны это просто примеры решения часто возникающих проблем. Если вы знаете много паттернов, то скорее всего не будете изобретать велосипед там, где не надо. Но всегда можно действовать по ситуации, потому что стандартные методы не покрывают все требования.
2. Смотря как вы будете с ними работать. Если сущности слишком элементарные, можно и общий объект-массив
3. Сложно сказать. Если вам кажется, что много - подумайте, можно ли передавать в качестве аргумента сразу объект. И имеет ли смысл создавать новый класс для этого. Иногда бывает достаточно сделать достаточно конструкторов, и иметь возможность указывать не все аргументы.