7 хороших объектно-ориентированных привычек в PHP

PHP

7 хороших объектно-ориентированных привычек в PHP

Улучшение PHP-приложений объектно-ориентированным способом

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

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

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

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

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

7 хороших привычек PHP OO включают в себя:

  1. Быть скромным.
  2. Будь хорошим соседом.
  3. Избегайте встречи с Медузой.
  4. Воспользуйтесь самым слабым звеном.
  5. Ты резина, я клей.
  6. Ограничить спред.
  7. Рассмотрите модели использования.

быть скромным

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

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

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

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

Плохая практика: раскрытие публичных полей

В примере плохого кода в листинге 1PersonПоля объекта отображаются непосредственно как общедоступные поля, а не с использованием методов доступа. Хотя такое поведение заманчиво, особенно для легковесных объектов данных, оно накладывает на вас ограничения.

Листинг 1. Плохая привычка открывать публичные поля
<?php
class Person
{
    public $prefix;
    public $givenName;
    public $familyName;
    public $suffix;
}
 
$person = new Person();
$person->prefix = "Mr.";
$person->givenName = "John";
 
echo($person->prefix);
echo($person->givenName);
 
?>

Если какой-либо объект изменяется, весь код, использующий этот объект, также должен измениться. Например, если чье-то имя, фамилия и другие имена инкапсулированы вPersonNameОбъект, все, что вам нужно для изменения кода для размещения изменений.

Хорошая практика: используйте общедоступные методы

Используя хорошие идиомы объектно-ориентированного программирования (см. листинг 2), тот же объект теперь имеет приватные поля вместо общедоступных полей, а вызовметод доступаизgetиsetОбщественные методы осторожно открыты для внешнего мира. Эти методы доступа теперь предоставляют общедоступный подход к получению информации из класса PHP, чтобы спрос на все код для изменения с использованием класса, скорее всего, будет меньше при реализации изменений.

Листинг 2. Использование общего метода доступа хороших привычек
<?php
class Person
{
    private $prefix;
    private $givenName;
    private $familyName;
    private $suffix;
     
    public function setPrefix($prefix)
    {
        $this->prefix = $prefix;
    }
     
    public function getPrefix()
    {
        return $this->prefix;
    }
     
    public function setGivenName($gn)
    {
        $this->givenName = $gn;
    }
     
    public function getGivenName()
    {
        return $this->givenName;
    }
     
    public function setFamilyName($fn)
    {
        $this->familyName = $fn;
    }
     
    public function getFamilyName() 
    {
        return $this->familyName;
    }
     
    public function setSuffix($suffix)
    {
        $this->suffix = $suffix;
    }
     
    public function getSuffix()
    {
        return $suffix;
    }
     
}
 
$person = new Person();
$person->setPrefix("Mr.");
$person->setGivenName("John");
 
echo($person->getPrefix());
echo($person->getGivenName());
 
?>

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

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

Листинг 3. Еще один пример с другой внутренней реализацией
<?php
class Person
{
    private $personName = array();
     
    public function setPrefix($prefix)
    {
        $this->personName['prefix'] = $prefix;
    }
     
    public function getPrefix()
    {
        return $this->personName['prefix'];
    }
     
    public function setGivenName($gn)
    {
        $this->personName['givenName'] = $gn;
    }
     
    public function getGivenName()
    {
        return $this->personName['givenName'];
    }
 
    /* etc... */
}
 
/*
 * Even though the internal implementation changed, the code here stays exactly
 * the same. The change has been encapsulated only to the Person class.
 */
$person = new Person();
$person->setPrefix("Mr.");
$person->setGivenName("John");
 
echo($person->getPrefix());
echo($person->getGivenName());
 
?>

быть хорошим соседом

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

Плохая привычка: не обрабатывать ошибки

Пример, показанный в рассматриваемом листинге 4, этот пример примет параметры и значения возврата ряда заполненныхPersonобъект. Но когдаparsePersonName()метод, валидация не предусмотрена$valЯвляется ли переменная пустой, строкой нулевой длины или форматом, не поддающимся анализу.parsePersonName()метод не возвращаетPersonобъект, но возвращает ноль. Администраторы или программисты, использующие этот метод, могут найти его громоздким. — По крайней мере, теперь им нужно приступить к установке точек останова и отладке PHP-скриптов.

Листинг 4. Плохая привычка не выдавать и не обрабатывать ошибки
class PersonUtils
{
    public static function parsePersonName($format, $val)
    {
        if (strpos(",", $val) > 0) {
            $person = new Person();
            $parts = split(",", $val); // Assume the value is last, first
            $person->setGivenName($parts[1]);
            $person->setFamilyName($parts[0]);
        }
        return $person;
    }
}

в листинге 4parsePersonName()метод может быть изменен наifусловная внешняя инициализацияPersonобъект, чтобы всегда получать действительныйPersonобъект. Однако то, что вы получаете, не имеет атрибута setPerson, что все еще не очень хорошо улучшает ваше затруднительное положение.

Полезные привычки: Каждый модуль обрабатывается самостоятельно

Не позволяйте вызывающей стороне угадывать, но предварительно проверьте параметры. Если неустановленная переменная не дает допустимого результата, проверьте переменную и выбросьтеInvalidArgumentException. Если строка не может быть пустой или должна быть в определенном формате, проверьте формат и создайте исключение. В листинге 5 показано, как продемонстрировать базовую проверку.parsePerson()метод для создания исключения вместе с некоторыми новыми условиями.

Листинг 5. Хорошая привычка выдавать ошибки
<?php
class InvalidPersonNameFormatException extends LogicException {}
 
 
class PersonUtils
{
    public static function parsePersonName($format, $val)
    {
        if (! $format) {
            throw new InvalidPersonNameFormatException("Invalid PersonName format.");
        }
 
        if ((! isset($val)) || strlen($val) == 0) {
            throw new InvalidArgumentException("Must supply a non-null value to parse.");
        }
 
 
    }
}
?>

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

Избегайте встречи с Медузой

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

Интерфейс — это зеркало против Медузы. Когда вы используете конкретную конкретную реализацию, код также должен меняться по мере изменения кода реализации. Использование реализации напрямую ограничит ваши возможности, потому что вы по сути превратили класс в «камень».

Плохая привычка: не использовать интерфейсы

В листинге 6 показана загрузка из базы данных.PersonПример объекта. Он возьмет имя человека и вернет соответствующее имя из базы данных.Personобъект.

Листинг 6. Плохая привычка не использовать интерфейсы
<?php
class DBPersonProvider
{
    public function getPerson($givenName, $familyName)
    {
        /* go to the database, get the person... */
        $person = new Person();
        $person->setPrefix("Mr.");
        $person->setGivenName("John");
        return $person;
    }
}
 
/* I need to get person data... */
$provider = new DBPersonProvider();
$person = $provider->getPerson("John", "Doe");
 
echo($person->getPrefix());
echo($person->getGivenName());
 
?>

Загрузка из базы данных до изменения средыPersonКод работает нормально. Например, загрузить из базы данныхPersonМожет работать для первой версии приложения, но для второй может потребоваться добавить возможность загружать людей из веб-сервиса. Фактически, класс стал «камнем», потому что он напрямую использует класс реализации и теперь может вносить очень ограниченные изменения.

Хорошая привычка: используйте интерфейсы

В листинге 7 показан пример кода без изменений после реализации нового метода загрузки пользователей. Пример показываетPersonProviderИнтерфейс, который объявит один метод. Если какой-либо код используетPersonProvider, код запрещает прямое использование класса реализации. Вместо этого он используется так, как будто это реальный объект.PersonProvider.

Листинг 7. Хорошая практика использования интерфейсов
<?php
interface PersonProvider
{
    public function getPerson($givenName, $familyName);
}
 
class DBPersonProvider implements PersonProvider 
{
    public function getPerson($givenName, $familyName)
    {
        /* pretend to go to the database, get the person... */
        $person = new Person();
        $person->setPrefix("Mr.");
        $person->setGivenName("John");
        return $person;
    }
}
 
class PersonProviderFactory
{
    public static function createProvider($type)
    {
        if ($type == 'database')
        {
            return new DBPersonProvider();
        } else {
            return new NullProvider();
        }
    }
}
 
$config = 'database';
/* I need to get person data... */
$provider = PersonProviderFactory::createProvider($config);
$person = $provider->getPerson("John", "Doe");
 
echo($person->getPrefix());
echo($person->getGivenName());
?>

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

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

В листинге 7createProvider()метод просто получить$type. если$typeустановлен наdatabase, завод вернетсяDBPersonProviderпример. Загрузка любой новой реализации людей из базы данных не требует никаких изменений в классах, использующих фабрики и интерфейсы.DBPersonProviderдобьетсяPersonProviderинтерфейс и иметьgetPerson()Собственно реализация метода.

Воспользуйтесь самым слабым звеном

модульслабо связанныйБыть вместе — это хорошо, это одно из свойств, которое позволяет инкапсулировать изменения. Две другие привычки — «Будь осторожен» и «Избегай встречи с Медузой» — помогают создавать слабосвязанные модули. Чтобы получить слабосвязанные классы, сделайте привычкой уменьшать зависимости классов.

Плохая привычка: тесная связь

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

Листинг 8.AddressПлохая привычка тесной связи в
<?php
 
require_once "./AddressFormatters.php";
 
class Address
{
    private $addressLine1;
    private $addressLine2;
    private $city;
    private $state; // or province...
    private $postalCode;
    private $country;
 
    public function setAddressLine1($line1)
    {
        $this->addressLine1 = $line1;
    }
 
        /* accessors, etc... */
 
    public function getCountry()
    {
        return $this->country;
    }
 
    public function format($type)
    {
        if ($type == "inline") {
            $formatter = new InlineAddressFormatter();
        } else if ($type == "multiline") {
            $formatter = new MultilineAddressFormatter();
        } else {
            $formatter = new NullAddressFormatter();
        }
        return $formatter->format($this->getAddressLine1(), 
            $this->getAddressLine2(), 
            $this->getCity(), $this->getState(), $this->getPostalCode(), 
            $this->getCountry());
    }
}
 
$addr = new Address();
$addr->setAddressLine1("123 Any St.");
$addr->setAddressLine2("Ste 200");
$addr->setCity("Anytown");
$addr->setState("AY");
$addr->setPostalCode("55555-0000");
$addr->setCountry("US");
 
echo($addr->format("multiline"));
echo("\n");
 
echo($addr->format("inline"));
echo("\n");
 
?>

существуетAddressвызов на объектformat()Код метода может выглядеть великолепно — этот код используетAddressкласс, звонитеformat()и сделано. Напротив,AddressС классами не так повезло. Это требует знания различных методов форматирования для правильного форматирования, что может сделатьAddressОбъекты не могут быть повторно использованы другими, особенно если другие не заинтересованы в них.format()В случае использования класса метода форматирования в методе. Хотя с помощьюAddressВ коде не так много зависимостей, ноAddressКласс имеет много кода и может быть просто объектом данных.

Addressклассы со знанием того, как форматироватьAddressКлассы реализации объектов тесно связаны.

Хорошая практика: слабая связь между объектами

При построении хорошего объектно-ориентированного проекта вы должны учитывать то, что называетсяразделение интересов(Разделение ответственности, SoC). SoC относится к попытке уменьшить связанность путем разделения объектов по тому, что их действительно волнует. в начальномAddressclass, он должен заботиться о том, как его отформатировать. Это может быть не очень хороший дизайн. Тем не мение,Addressкласс надо рассматриватьAddress, а метод форматирования должен фокусироваться на правильном форматировании адреса.

В листинге 9 код для форматирования адресов перенесен в интерфейсы, классы реализации и фабрики — по привычке «использовать интерфейс». в настоящее время,AddressFormatUtilsКласс отвечает за создание методов форматирования и форматированиеAddress. Теперь можно использовать любой другой объектAddressИ не беспокойтесь о том, чтобы попросить получить определение метода форматирования.

Листинг 9. Хорошая практика слабой связи между объектами
<?php
 
interface AddressFormatter
{
    public function format($addressLine1, $addressLine2, $city, $state, 
        $postalCode, $country);
}
 
class MultiLineAddressFormatter implements AddressFormatter 
{
    public function format($addressLine1, $addressLine2, $city, $state, 
        $postalCode, $country)
    {
        return sprintf("%s\n%s\n%s, %s %s\n%s", 
            $addressLine1, $addressLine2, $city, $state, $postalCode, $country);
    }
}
 
class InlineAddressFormatter implements AddressFormatter 
{
    public function format($addressLine1, $addressLine2, $city, $state, 
        $postalCode, $country)
    {
        return sprintf("%s %s, %s, %s %s %s", 
            $addressLine1, $addressLine2, $city, $state, $postalCode, $country);
    }
}
 
class AddressFormatUtils 
{
    public static function formatAddress($type, $address)
    {
        $formatter = AddressFormatUtils::createAddressFormatter($type);
         
        return $formatter->format($address->getAddressLine1(), 
            $address->getAddressLine2(), 
            $address->getCity(), $address->getState(), 
            $address->getPostalCode(), 
            $address->getCountry());
    }
     
    private static function createAddressFormatter($type)
    {
        if ($type == "inline") {
            $formatter = new InlineAddressFormatter();
        } else if ($type == "multiline") {
            $formatter = new MultilineAddressFormatter();
        } else {
            $formatter = new NullAddressFormatter();
        }
        return $formatter;
    }
}
 
$addr = new Address();
$addr->setAddressLine1("123 Any St.");
$addr->setAddressLine2("Ste 200");
$addr->setCity("Anytown");
$addr->setState("AY");
$addr->setPostalCode("55555-0000");
$addr->setCountry("US");
 
echo(AddressFormatUtils::formatAddress("multiline", $addr));
echo("\n");
 
echo(AddressFormatUtils::formatAddress("inline", $addr));
echo("\n");
?>

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

Ты резина, я клей

Высокосвязные объектно-ориентированные проекты централизованы и организованы в связанные модули. Понимание «проблем» важно для принятия решения о том, насколько тесно связаны функции и классы.

Плохая привычка: снижение сплоченности

при разработкенизкая сплоченность, он плохо организует классы и методы.код спагеттиЭтот термин часто используется для описания классов и методов, которые связаны друг с другом и имеют низкую связность. В листинге 10 приведен пример спагетти-кода. относительно общийUtilsКласс будет использовать много разных объектов и иметь много зависимостей. Он выполняет множество операций, что затрудняет его повторное использование.

Листинг 10. Вредные привычки, снижающие сплоченность
<?php
 
class Utils
{
    public static function formatAddress($formatType, $address1, 
        $address2, $city, $state)
    {
        return "some address string";
    }
     
    public static function formatPersonName($formatType, $givenName, 
        $familyName)
    {
        return "some person name";
    }
     
    public static function parseAddress($formatType, $val)
    {
        // real implementation would set values, etc...
        return new Address();
    }
     
    public static function parseTelephoneNumber($formatType, $val)
    {
        // real implementation would set values, etc...
        return new TelephoneNumber();
    }
}
 
?>

Хорошая привычка: использовать высокую сплоченность

высокая сплоченностьОтносится к объединению связанных классов и методов. Если и методы, и классы тесно взаимосвязаны, всю группу можно легко разбить, не затрагивая дизайн. Конструкция с высоким сцеплением даст возможность уменьшить сцепление. В листинге 11 показаны два метода, которые лучше организованы в классы.AddressUtilsкласс будет содержать для обработкиAddressметодов класса, демонстрируя высокую степень согласованности между методами, связанными с адресами. Так же,PersonUtilsбудет содержать специализированную обработкуPersonметоды объекта. Оба этих новых класса с высоко связанными методами менее связаны, поскольку их можно использовать совершенно независимо.

Листинг 11. Хорошие привычки для высокой сплоченности
<?php
 
class AddressUtils
{
    public static function formatAddress($formatType, $address1, 
        $address2, $city, $state)
    {
        return "some address string";
    }
     
    public static function parseAddress($formatType, $val)
    {
        // real implementation would set values, etc...
        return new Address();
    }
     
}
 
class PersonUtils
{
    public static function formatPersonName($formatType, $givenName, 
        $familyName)
    {
        return "some person name";
    }
     
    public static function parsePersonName($formatType, $val)
    {
        // real implementation would set values, etc...
        return new PersonName();
    }
}
 
?>

ограничить распространение

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

Плохая привычка: не использовать иерархию классов

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

Листинг 12. Плохая привычка не использовать иерархии
<?php
class Person
{
    private $givenName;
    private $familyName;
}
 
class Employee
{
    private $givenName;
    private $familyName;
}
 
?>

наследоватьэто сложная привычка, так как анализ для построения правильной модели наследования обычно занимает много времени. В свою очередь используйтеCtrl+Cкомбинация клавиш иCtrl+VСоздание новых реализаций с помощью комбинаций клавиш занимает секунды. Но эта экономия времени обычно быстро сводится на нет на этапе обслуживания, поскольку на самом деле поддерживать приложение будет дорого.

Хорошая привычка: использовать наследство

В листинге 13 новыйEmployeeкласс будет расширятьсяPersonсвоего рода. Теперь он будет наследовать все универсальные методы и не будет их переопределять. Кроме того, в листинге 13 показано использование абстрактных методов, демонстрирующее, как поместить базовые функции в базовый класс и как запретить реализующим классам использовать определенные функции.

Листинг 13. Хорошая привычка использовать наследование
<?php
abstract class Person
{
    private $givenName;
    private $familyName;
     
    public function setGivenName($gn)
    {
        $this->givenName = $gn;
    }
     
    public function getGivenName()
    {
        return $this->givenName;
    }
     
    public function setFamilyName($fn)
    {
        $this->familyName = $fn;
    }
     
    public function getFamilyName()
    {
        return $this->familyName;
    }
      
    public function sayHello()
    {
        echo("Hello, I am ");
        $this->introduceSelf();
    }
     
    abstract public function introduceSelf();
     
}
 
class Employee extends Person
{
    private $role;
     
    public function setRole($r)
    {
        $this->role = $r; 
    }
     
    public function getRole()
    {
        return $this->role;
    }
     
    public function introduceSelf()
    {
        echo($this->getRole() . " " . $this->getGivenName() . " " . 
            $this->getFamilyName());
    }
}
?>

Учитывайте шаблоны использования

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

Плохая привычка: думать об одном объекте за раз

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

  • Объектная модель не разрабатывается заранее.
  • Начните писать реализацию одного метода, не удаляя большую часть модели.
  • Не используйте имена шаблонов проектирования в разговорах, а говорите о реализации.

Хорошая практика: добавить объекты, образованные в рисунке одновременно

В общем, вы думаете о шаблонах использования, когда:

  • Создавайте классы и их взаимодействия заранее.
  • Применять занятия по шаблонам.
  • Используйте имена схем, такие какФабрика, СинглтониFacade.
  • Избавьтесь от большинства моделей и начните добавлять реализации.

заключительные замечания

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

  • Будь осторожен.
  • Будь хорошим соседом.
  • Избегайте встречи с Медузой.
  • Воспользуйтесь самым слабым звеном.
  • Ты резина, я клей.
  • Ограничить спред.
  • Рассмотрите модели использования.

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

связанная тема

Категории