Преобразование процедурного PHP в объектно-ориентированный PHP

Question

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

Существует много областей, где ООП может помочь уменьшить количество кода и облегчить его чтение. Однако у меня есть несколько вопросов.

1) Насколько я понимаю, один класс используется в качестве плана для любого количества объектов, но любой класс представляет только один объект, не более одного. Таким образом, один класс может представлять игрока, но не много игроков.

2) Поскольку я довольно много различных классов для включения, я использую класс «Loader», чтобы загрузить их все с помощью spl_autoload_register или я просто использовать spl_autoload_register в программных файлах для моего приложения?

Edit: Так что мой автозагрузчик будет класс, который я затем создать экземпляр для запуска автозагрузку или просто PHP файл с функцией и spl_autoload_register, что я хотел бы включать в себя, чтобы избежать повторения того же кода в нескольких файлах ?

3) Некоторые из моих классов зависят от других классов. Я никогда не сталкивался с этим раньше, поэтому я честно не знаю ответа. Если я включу все классы в свой основной файл программы, но мой класс класса не включает класс, который должен функционировать, будет ли класс игрока работать, поскольку основная программа включает класс, от которого зависит игрок?

Edit: Так что даже если один класс может создать экземпляр объекта типа проигрывателя, а класс игрока не включены непосредственно этим классом, он все равно будет работать, потому что класс контроллера делает включают класс игрока?

4) Существует несколько случаев, когда мне нужно будет работать с объектами, которые я создаю. Мне интересно, как я должен это делать. Например, в моем классе Player мне иногда нужно будет отправлять что-то от одного игрока другому игроку. Итак, реализую ли я статический метод в классе Player, который принимает два игрока в качестве параметров и выполняет ли передача, или я делаю что-то еще?

Редактировать: Итак, избегайте статических методов. Теперь у меня есть серьезная проблема: у меня есть методы, которые выполняются несколько раз в моем приложении, но я не могу реализовать их как статические методы. Я должен реализовать их как методы экземпляра? Например, отправка от одного игрока к другому. Я бы создал метод экземпляра, который принимает объект Player, и отправляет либо , либо или от?

5) У меня есть много методов, которые действительно не принадлежат ни одному экземпляру класса, ни они действительно не подходят как статические методы. Должны ли они быть объявлены в их собственном классе как статические методы, такие как Common или аналогичные? Что делается на практике в этой ситуации?

Редактировать: Будут ли эти методы принадлежать определенному файлу приложения, для которого они используются или, возможно, хранятся в их собственном файле "functions.php"?

6) Я хотел бы узнать, как использовать пространства имен, но мой код никогда не будет использоваться другими, и я никогда не буду использовать чужой код в своем приложении. Являются ли пространства имен излишним дополнением в моем приложении или было бы хорошей идеей научиться их использовать? Независимо от того, имеет ли одно приложение одно пространство имен (имя приложения?) Или каждый класс принадлежит к собственному пространству имен?

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

Спасибо за любую помощь и понимание, которые вы можете предоставить.

Answer 1

1) Это мое понимание того, что один класс используется в качестве плана для любого количества объектов, но ни один класс представляет собой лишь один объект, никогда больше, чем один. Таким образом, один класс может представлять игрока, но не много игроков.

Как правило, вы также будете иметь классы, представляющие коллекции объектов, например, класса «Игроки», которые могут быть использованы для получения одного игрока из коллекции всех игроков:

$players = new Players(); 
$john = $players->findByName("john"); 

2) Так как у меня будет довольно много различных классов для включения, я использую «Loader «класс, чтобы загрузить их все с помощью spl_autoload_register или просто использовать spl_autoload_register в файлах программы для моего приложения?

Это в значительной степени зависит от сложности вашего проекта. Простая функция автозагрузки обычно будет достаточно хорошей, но вы можете взглянуть на Zend Framework Autoloader class.

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

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

4) Есть несколько случаев, когда мне нужно будет работать с объектами, которые я создаю. Мне интересно, как я должен это делать. Например, в моем классе Player мне иногда нужно будет отправлять что-то от одного игрока другому игроку. Итак, реализую ли я статический метод в классе Player, который принимает два игрока в качестве параметров и выполняет ли передача, или я делаю что-то еще?

Статические методы - это почти всегда неправильный подход. Нормальные методы относятся к экземпляру (т. Е. Конкретному игроку) и статическим методам относятся к классу, т. Е. Общая «идея» игрока. Если вам нужно передать материал от одного игрока к другому, почему бы не реализовать это так:

class Player { 
    public function transferMoney(Player $recipient, $amount) { ... } 
} 

$tom = new Player("tom"); 
$marc = new Player("marc"); 

$tom->transferMoney($marc, 500); 

5) У меня есть много методов, которые на самом деле не принадлежат к какому-либо экземпляру класса, ни они действительно подходят как статические методы. Должны ли они быть объявлены в их собственном классе как статические методы, такие как Common или аналогичные? Что делается на практике в этой ситуации?

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

6) Я хотел бы узнать, как использовать пространства имен, но мой код никогда не будет использоваться другими, и я никогда не буду использовать чужой код в своем приложении. Являются ли пространства имен излишним дополнением в моем приложении или было бы хорошей идеей научиться их использовать? Независимо от того, имеет ли одно приложение одно пространство имен (имя приложения?) Или каждый класс принадлежит к собственному пространству имен?

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

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

Это зависит от того, как вы моделируете свою реальную ситуацию. Если соединение с базой данных и «сеть» - две разные вещи для вас, два пути - путь.

Answer 2

1) Насколько я понимаю, один класс используется в качестве плана для любого количества объектов, но любой один класс представляет только один объект, не более одного. Таким образом, один класс может представлять игрока, но не много игроков.

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

2) Так как я довольно много различных классов для включения, я использую класс «Loader», чтобы загрузить их все с помощью spl_autoload_register или я просто использовать spl_autoload_register в программных файлах для моего приложения?

Не зная, что вы подразумеваете под «программными файлами для моего приложения», я говорю «да». Используйте автозагрузчик, потому что он просто работает, и вам не нужно беспокоиться о выполнении require_*.

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

Вы не хотите загружать все классы, но только те, которые вы собираетесь использовать. Что снова не то, о чем вам нужно беспокоиться при использовании автозагрузчика. Но да, как только класс загружен, он может быть создан во всем приложении.

Обычно вы должны запустить автозагрузчик в bootstrap phase of the application.

4) Есть несколько случаев, когда мне нужно будет работать с объектами, которые я создаю. Мне интересно, как я должен это делать. Например, в моем классе Player мне иногда нужно будет отправлять что-то от одного игрока другому игроку. Итак, реализую ли я статический метод в классе Player, который принимает два игрока в качестве параметров и выполняет ли передача, или я делаю что-то еще?

Избегайте использования статических методов в OOP PHP. Это почти никогда не нужно. Вы могли бы подумать о том, чтобы иметь другой класс, который действует как пул игроков, который заботится о «отправке данных» от одного игрока к другому.

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

5) У меня есть много методов, которые действительно не принадлежат ни одному экземпляру класса, ни они действительно не подходят как статические методы. Должны ли они быть объявлены в их собственном классе как статические методы, такие как Common или аналогичные? Что делается на практике в этой ситуации?

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

Но это трудно сказать, просто прочитав свой вопрос. Может быть, вы можете привести пример в комментарии?

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

Пространство имен в PHP - это структурирование. Хотя никто не будет использовать ваш код, вам не придется беспокоиться о том, чтобы использовать одно и то же имя для какого-либо класса. Что произойдет, как только приложение будет расти быстрее, чем позже.

Независимо от того, имеет ли одно приложение одно пространство имен (имя приложения?) Или каждый класс принадлежит к собственному пространству имен?

Я часто следую PSR-0, когда дело доходит до пространств имен.

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

Просто помните о Single Reponsibility Principle и в целом SOLID.

Также я настоятельно рекомендую смотреть these и следить за ними, пока вы не поймете это.

Answer 3

1. A PlayerCollection будет действительным классом. Конечно, объектом этого является один коллекция нескольких игроков.

2. Используйте spl_autoload_register, период. Лучше следовать стандарту PSR-0 и использовать любой существующий автозагрузчик, совместимый с PSR-0 (то есть Symfony Loader)

3. Он будет работать. Но поскольку вы используете автозагрузчик (см. 2.) вам не нужно заботиться о включении классов вообще

4. Отправка сообщения от игрока 1 игроку 2 легко переводится при вызове метода игрока 2 в плеере 1. Однако «отправка вещей» и «работа на объектах "может означать много вещей, поэтому ответ: это зависит. Но в целом это хороший совет избегать статических методов.

5. Это очень похоже на процессуальное мышление. Извините, но я не могу дать вам ответ на серебряную пулю, вам нужно будет изучить и понять принципы объектно-ориентированного дизайна для их применения. В Интернете есть стандартная литература и множество полезных ресурсов. Также может быть полезно изучение на примере (см. Другие приложения OO и рамки, которые являются открытыми источниками)

6. «У одного приложения есть одно пространство имен (имя приложения?) Или каждый класс принадлежит к собственному пространству имен?» - ответ находится между ними. Пространства имен полезны для группировки вещей, которые работают вместе, и они полезны независимо от того, кто будет использовать или видеть код.

7. Первое правило объектно-ориентированного дизайна: один класс, одна ответственность.