Php абстрактные классы: PHP: Абстрактные классы — Manual

Обзор абстрактного класса в Python

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

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

Важность абстрактных классов

1. Он обеспечивает функциональность по умолчанию базовых классов.

2. Он определяет общий API для набора подклассов, полезен, когда третье лицо предоставляет плагины в приложении.

3. Полезным в большом коде было запоминание многих классов, это сложно.

Синтаксис

From abc import ABC
Class Educba(ABC):

Чтобы рассматривать любой класс как абстрактный класс, класс должен наследовать метакласс ABC от встроенного abc-модуля python. Модуль abc импортирует метакласс ABC.

Абстрактные методы в Python

Абстрактные методы — это методы, которые объявлены без каких-либо реализаций.

Синтаксис

from abc import ABC, abstract method
Class Educba(ABC):
@abstractmethod
def mymethod(self):
#empty body
pass

Чтобы определить абстрактные методы в абстрактном классе, метод должен быть украшен ключевым словом @abstractmethod decorator. Декоратор @abstractmethod должен быть импортирован из встроенной библиотеки python abc.

Как абстрактные классы работают в Python?

Python не имеет абстрактных классов по умолчанию, но у него есть модуль или библиотека, которые образуют основу для определения абстрактных базовых классов (ABC), и это имя модуля называется ABC. Он помечает метод базового класса как абстрактный базовый класс, а затем создает конкретные классы как реализации абстрактной базы. Метод превращается в абстрактный метод с помощью ключевого слова decorator, называемого @abstractmethod.

Модуль ABC используется для создания абстрактных классов, @ abstractmethod — декоратор, используемый для объявления абстрактного метода. Модуль ABC устанавливает договор между базовым классом и конкретным классом.

Модуль abc обеспечивает основу для определения абстрактных базовых классов (ABC) в Python. Модуль коллекций имеет несколько конкретных классов, которые являются производными от ABC, и их можно разделить дальше. Помимо всего этого, модуль коллекций также содержит некоторые ABC, которые можно использовать для проверки того, предоставляет ли класс или экземпляр конкретный интерфейс или нет.

Этот модуль предоставляет следующий класс:

класс abc.ABCMeta

Метакласс используется для определения абстрактных базовых классов (ABC)

Мы используем метакласс для создания абстрактного базового класса.

from abc import ABCMeta
class C:
__metaclass__ = ABCMeta
MyABC.register(tuple)
assert issubclass(tuple, C)
assert isinstance((), C)

пример

# importing the ABC module
from abc import ABC, abstractmethod
class Shape(ABC):
def common(self):
print("This is a concrete method")
@abstractmethod # decorator
def area(self):
pass
@abstractmethod
def perimeter(self):
pass
class Square(Shape):
def __init__(self, side):
self.__side=side
def area(self):
return self.__side*self.__side
def perimeter(self):
return 4*self.__side
class Rectangle(Shape):
def __init__(self, length, breath):
self.__length=length
self.__breath=breath
def area(self):
return self.__length*self.__breath
def perimeter(self):
return 2*(self.__length+self.__breath)
S1=Square(4)
print(S1.common())
print(S1.area())
print(S1.perimeter())
R1=Rectangle(2, 4)
print(R1.common())
print(R1.area())
print(R1.perimeter())

Выход получен

Это конкретный метод

16

16

Это конкретный метод

8

12

В приведенном выше примере класс Abstract — это Shape, который содержит один конкретный метод, называемый common, и два абстрактных метода, называемых area и perimeter. Есть два дочерних класса Square и Rectangle, которые наследуют абстрактный класс Shape и реализуют абстрактный метод.

Реализация через подклассы:

import abc
class Shape:
def area(self):
pass
class Square(Shape):
def area(self):
print("Square is a child class")
print( issubclass(Square, Shape))
print( isinstance(Square(), Shape))

Абстрактные свойства

Абстрактные классы содержат абстрактные свойства наряду с абстрактными методами, определенными @abstractproperty.

Теперь мы можем использовать property, property.getter (), property.setter () и property.deleter () с абстрактными классами.

Синтаксис

class class_name(ABC):
@property
@abstractmethod
Def method(self):

Это определяет свойство только для чтения.

class Class_name:
__metaclass__ = ABCMeta
def getx(self): ...
def setx(self, value): ...
x = abstractproperty(getx, setx)

Python 2

class C(ABC):
@abstractproperty
def my_abstract_property(self):

Python 3.3

class C(ABC):
@property
@abstractmethod
def my_abstract_property(self):
import abc
from abc import ABC, abstractmethod
class Shape(ABC):
@abc.abstractproperty
def area(self):
return "Shape class"
class Square(parent):
@property
def area(self):
return "Square class"
try:
s1 =Shape()
print( s1.area)
except for Exception as err:
print (err)
s1 = Square()
print (s1.area)

Выход:

Не удалось создать экземпляр абстрактного класса Shape с областью абстрактного метода

Квадратный класс

Вывод

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

Рекомендуемые статьи

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

1. Файловые операции Python
2. Инкапсуляция в Python
3. Петли в Python
4. Конструктор в Python
5. Наборы Python
6. Введение в абстрактный класс в PHP

php — Интерфейс или абстрактный класс: какой использовать?

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

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

И это может помочь вам в качестве метафоры:

ИНТЕРФЕЙС

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

Дело здесь

— чтобы было правильно
— осторожно
— для предотвращения вещей, которые могут испортиться (например, слишком много клубники или чего-то еще)
— упростить для тех, кто попробует
— сказать вам, сколько времени нужно делать (например, помешивать)
— чтобы сказать, что вы МОЖЕТЕ делать, но НЕ ИМЕЕТЕ, на номер

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

АБСТРАКЦИЯ

Продолжая эту метафору … представьте, что на этот раз вы гость, который ест этот торт. Тогда вы пробуете торт по рецепту.Но вы хотите добавить новые ингредиенты или изменить / пропустить шаги, описанные в рецепте. Итак, что будет дальше? Придумайте другой вариант этого торта. На этот раз с черными ягодами, а не с соломенными ягодами, а с добавлением ванильного крема … вкусно.

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

Теперь вы хотите поменять ингредиенты и этапы, и они ДОЛЖНЫ быть определены в новой версии этого торта. Это абстрактных методов , которые должны быть определены для нового торта, потому что в торте должен быть фрукт, но какие? Итак, на этот раз вы возьмете черные ягоды. Сделанный.

Итак, вы расширили торт, следовали интерфейсу и извлекли из него шаги и ингредиенты.

Практическая демонстрация интерфейсов и абстрактных классов в PHP | Кейси МакМаллен

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

Чтобы проиллюстрировать это, давайте начнем с изучения нашего абстрактного класса Data_Access .В нашем примере кода я создал файл с именем data_access.php . В нем есть две функции: dbConnect и getResultSetArray .

На изображении 1 ниже вы можете видеть, что мы определяем Data_Access как «абстрактный класс» в третьей строке. Это навязывает идею о том, что это абстрактный класс, и поэтому не может быть создан как как отдельный класс. может быть расширен только . Это правило абстрактных классов, которое гарантирует, что оно рассматривается как абстрактное.

Если бы мы попытались создать экземпляр класса Data_Access как автономный объект:

 $ cDataAccess = new Data_Access; 

Это вызовет следующую ошибку:

 Неустранимая ошибка PHP: Неперехваченная ошибка: невозможно создать экземпляр абстрактного класса Data_Access ... 

Изображение 1 выше показывает функцию dbConnect в Data_Access , которая выполняет подключение к базе данных.

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

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

Наконец, на изображении 2 ниже у нас есть функция getResultSetArray в Data_Access :

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

Примечание: Причина, по которой я возвращаю все в виде массива ответов, заключается в обеспечении согласованности вызывающих функций. При этом мои вызывающие функции могут знать, что ответ всегда будет возвращаться в этой форме, пройден или не пройден, с кодом ответа, сообщением и любыми данными в ассоциативный массив с именем dataArray . Этот ассоциативный массив легко использовать в PHP или Javascript.

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

Теперь посмотрим на интерфейс.

Nautaskrá

Vafrakökur (например, печенье) eru smáar textaskrár sem vefsíður koma fyrir á tölvu inni, síma eða snjalltæki egar þú heimsækir þær.Almennt eru vafrakökur notaðar тиль bæta viðmót síðunnar ог тиль þess að vefsíðan muni mikilvægar upplýsingar frá fyrri heimsóknum þínum. Vafrakökur eru öruggar, þær innihalda ekki kóða og geta ekki verið notaðar til komast inn í tölvuna þína. Энгар тилраунир эру герар тиль и тенгья хеймсокн við persónugreinanlegar upplýsingar.

Af hverju notar nautaskra.net vafrakökur ?
Við notum vafrakökur til mælinga á heimsóknum á heimasíðu okkar. Umfer á vefinn eru mæld með Google Analytics.Að þýðir að skráður er tími og dagsetning heimsókna á vefinn, IP tölur þeirra sem heimsækja hann og frá hvaa vefsíðu heimsóknir koma, tegund vafra og st finri Vafrakökur eru notaðar í margvíslegum tilgangi eins og til dæmis að muna hvað notandi hefur valið í útfyllingu á eyðublaði á meðan hann er tengdur vefsvæðinu, r aggí vefsvæðinu, r kunna Lotukökur eyðast egar notandi fer af vefsvæði og eru því ekki vistaðar til lengri tíma.Viðvarandi vafrakökur vistast á tölvu notanda og muna val eða aðgerðir notanda á vefsvæði.

Hvernig er hægt að eyða vafrakökum ?
Allir vafrar bjóða upp á takmörkun á notkun á vafrakökum, eins er mögulegt að slökkva á eim í stillingum vafrans. Ólíkt er eftir vöfrum hvernig þetta er gert en leiðbeiningar má finna í hjálparvalmöguleika í vafranum sem ú notar. Einnig er hægt að eyða eim vafrakökum sem egar eru vistaðar hjá ér. Skrefin við að eyða vafrakökum eru ólík eftir vöfrum en leiðbeiningar um slíkt ma finna í hjálparvalmöguleika í vafranum sem ú notar.

Hægt er að nálgast allar upplýsingar um hvernig vafrakökur virka og hvernig hægt er að komast hjá notkun eirra á essari vefsíðu: http://www.allaboutcookies.org/

Разница между интерфейсом и абстрактным классом

С поправками от 18 сентября 2017 г.

Введение

Абстрактный метод

Статический метод

Обычный метод

Интерфейс

Абстрактный класс

Бетон (простой) класс

Мифы об интерфейсах

Сводка

История изменений

Комментарии

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

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

Абстрактный метод определяется как сигнатура метода без тела метода, т. Е. Не имеет реализации.

При определении в абстрактном классе требуется префикс ключевого слова abstract . В этом нет необходимости, если они определены в интерфейсе, поскольку все методы в интерфейсе по умолчанию являются абстрактными.

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

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

Статический метод не может использовать псевдопеременную $ this .

У простого метода есть подпись и тело, но тело может быть пустым. Это отличается от абстрактного метода, который может иметь подпись, но не иметь тела.

Если унаследован простой метод, его можно использовать в подклассе, не определяя его в подклассе.

Простой метод может использовать любой из модификаторов видимости public , private или protected .

Интерфейс определяет один или несколько абстрактных методов. Он не может содержать никаких простых или статических методов.

Интерфейс идентифицируется по ключевому слову interface перед именем интерфейса / класса

Интерфейс может содержать константы, но не переменные.

Не удается создать экземпляр интерфейса в объекте.

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

Интерфейс может быть унаследован другим интерфейсом с помощью ключевого слова Implements.

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

Следующее описание абстрактного класса взято из Components, Frameworks, Patterns (PDF) Ральфа Э. Джонсона:

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

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

Абстрактный класс идентифицируется по ключевому слову abstract перед именем класса

Невозможно создать экземпляр абстрактного класса в объекте.

Он может наследовать один или несколько интерфейсов с помощью ключевого слова Implements.

Он может наследовать не более одного абстрактного класса с использованием ключевого слова extends.

Абстрактный класс не может наследовать от не абстрактного класса.

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

Он может содержать любое количество констант, переменных и методов (абстрактных или иных).

Может содержать любое количество статических или простых методов.

Он не может содержать никаких абстрактных методов, иначе он должен быть абстрактным классом.

Может содержать любое количество констант и переменных.

Его можно создать в виде объекта.

Он может расширять не более одного класса, абстрактного или не абстрактного.

Может реализовывать любое количество интерфейсов.

Может быть унаследован другим классом, но не абстрактным классом.

Унаследованный класс известен как суперкласс или родительский класс , тогда как класс, который наследует, известен как подкласс или дочерний класс .

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

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

Если метод в суперклассе переопределен в подклассе , тогда реализация в подклассе будет выполняться во время выполнения, а не реализация в суперклассе .

Константы, переменные и методы, которые не наследуются, могут иметь любые модификаторы видимости.

Абстрактный метод, унаследованный от интерфейса, должен быть определен с такой же видимостью (общедоступный).

Абстрактный метод, унаследованный от абстрактного класса, может быть определен с такой же или менее ограничительной видимостью .

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

Интерфейсы требуются на языках OO.

Мусор. Интерфейсы были изобретены для решения проблемы, которая существовала несколько десятилетий назад, когда скорость обработки была всего лишь долей того, что есть сейчас, и требовался механизм, чтобы проверить, существует ли метод с такой сигнатурой в объекте до его вызова.Это нельзя было сделать во время выполнения, поэтому это было сделано во время компиляции. Пожалуйста, обратитесь к разделу «Полиморфизм и наследование независимо друг от друга». Эта проблема больше не существует в современных языках с современными высокоскоростными процессорами, поэтому, если проблема больше не существует, почему все еще необходимо ее решение?

Интерфейсы предоставляют альтернативный тип наследования

Я часто читал о двух разновидностях наследования:

• Наследование реализации — где сигнатуры методов и их реализации наследуются от суперкласса.
• Наследование интерфейса — когда от интерфейса «наследуется» только сигнатура метода.

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

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

Не существует такой вещи, как наследование интерфейса , поскольку на самом деле ничего не передается получателю.Мало того, что нет реализации (вы должны ее кодировать самостоятельно), вы даже не «наследуете» сигнатуру метода, поскольку вы создали свой собственный дубликат. Это как сказать кому-то: «Поздравляю, вы только что унаследовали портфель, полный денег», а когда они спрашивают: «Хорошо, так где он?» вы говорите им, что они должны сами предоставить и деньги, и портфель. Итак, если на самом деле вам ничего не дается, потому что вы должны были предоставить это самостоятельно, что именно вы унаследовали? Нет ничего существенного, только концепция.

Интерфейсы обеспечивают лучший стиль программирования

В этой статье Википедии говорится следующее:

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

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

В статье «Наследование интерфейсов vs наследование реализации» автор утверждает следующее:

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

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

Наследование интерфейсов позволяет избежать сопряжения

Затем в той же статье он задает вопрос: «Так почему же наследование интерфейсов предпочтительнее наследования реализации?» на что ответ:

Простой ответ — избежать связи между двумя компонентами приложения.

Идея о том, что вы можете избежать связывания, когда один модуль вызывает другой, говорит мне, что этот человек не понимает, что на самом деле означает связывание.Когда у вас есть приложение, состоящее из множества модулей, которые должны взаимодействовать между собой, у вас автоматически возникают связи и зависимости. Это неизбежно в модульном приложении. Возьмем следующие примеры:

Если ModuleA вызывает ModuleB, применяются следующие утверждения:

• Между ModuleA и ModuleB существует зависимость.
• ModuleA зависит от ModuleB, поскольку для выполнения своей задачи ему требуются услуги ModuleB.
• ModuleB не зависит от ModuleA, потому что он не вызывает ModuleA и, следовательно, не требует услуги ModuleA для выполнения своей задачи.

Зависимость между двумя модулями / объектами является двоичным условием — если один вызывает другой, то существует зависимость. Если ни один из них не вызывает другого, то зависимости нет.

• Между ModuleA и ModuleB существует связь.
• ModuleA связан с ModuleB, потому что он вызывает метод внутри ModuleB.
• ModuleB связан с ModuleA, потому что у него есть метод, который вызывается из ModuleA.

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

Невозможно полностью исключить связывание, поскольку полностью изолированное приложение не будет работать.Два тесно связанных модуля имеют меньше шансов на повторное использование, поэтому единственный способ гарантировать большее повторное использование кода — это иметь как можно более слабую связь. Например, если у меня есть контроллер C1 , который тесно связан с моделью M1 , то я не могу использовать этот контроллер с любой другой моделью, и я не могу использовать эту модель с любым другим контроллером. В моей структуре RADICORE я перешел на другой конец спектра, позволив использовать любой из более чем 50 контроллеров многократного использования с любым из моих классов моделей (которых в настоящее время более 400).Таким образом, минимизируя (что НЕ то же самое, что исключение) уровень связи, я максимизировал уровень повторного использования кода.

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

ModuleA вызывает ModuleB (n), где «n» идентифицирует конкретный модуль, который разделяет эту подпись.Использование DI ModuleA не содержит кода для определения того, какую версию ModuleB необходимо создать, это делается вне ModuleA, а затем вводится в него. Затем ModuleA вызывает метод для той версии ModuleB, которая была в него введена.

Здесь вы должны увидеть, что все еще существует как зависимость, так и связь между ModuleA и всеми версиями ModuleB, поскольку одна из них вызывает метод с использованием сигнатуры, определенной в другой, все, что произошло, это где конкретная версия ModuleB идентифицирован и создан.

Наследование разрывает инкапсуляцию

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

Если вы прочитаете эти статьи, то увидите, что в одной из них написано следующее:

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

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

Другие говорят примерно следующее:

Он нарушает инкапсуляцию, поскольку предоставляет подклассу сведения о реализации его суперкласса.
Инкапсуляция связана с сокрытием информации, и когда вы наследуете от суперкласса, информация внутри этого суперкласса больше не скрывается в подклассе.

Эти люди не понимают, что когда вы наследуете содержимое класса C1 в класс C2 , то полученный объект объединяет содержимое C1 с содержимым C2 .Все, что в C1 , что должно быть скрыто от C2 , должно иметь правильную видимость. Следовательно, любая проблема связана с реализацией концепции программистом, а не с самой концепцией.

Есть еще один момент, который упускают из виду большинство людей — «проблема» может материализоваться только тогда, когда вы наследуете от одного конкретного класса, чтобы создать совершенно другой конкретный класс. Таким образом, «решение» очевидно — создавать конкретный класс только путем наследования от абстрактного класса, как это было задокументировано еще в 1994 году в книге «Шаблоны проектирования: элементы многоразового объектно-ориентированного программного обеспечения».

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

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

Мне нравятся абстрактные классы, поскольку они позволяют использовать шаблон метода шаблона.

Есть люди, которые считают, что абстрактный класс может содержать только абстрактные методы, но они не понимают, что это не отличает его от интерфейса. Абстрактный класс предоставляет многоразовые реализации, а интерфейс — нет.

В моей структуре RADICORE, которая имеет дело с приложениями баз данных, каждый компонент модели на уровне Business представляет одну таблицу базы данных, и весь код, общий для таблиц базы данных, был определен один раз в одном классе абстрактной таблицы, который затем наследуется каждый из моих 400+ классов конкретных таблиц.Этот абстрактный класс заполнен более чем 200 конкретными методами, а не абстрактными методами, поэтому ни один из них не нужно определять и реализовывать в подклассе. Это обеспечивает огромных кода для многократного использования / совместного использования, и поскольку это должно быть целью ООП, я категорически отказываюсь признавать любую критику, которая говорит, что моя реализация ООП неверна.

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