Недавно я столкнулся с трудностями в процессе изучения интерфейса PHP5. В книге сказано, что это способ реализовать множественное наследование, но я до сих пор не знаю, как его реализовать. Информации по интерфейсу PHP в Интернете очень мало, поэтому я проверил на Java. На самом деле они в принципе одинаковы. Прочитав статью «Разъяснение Java (Интерфейсы и наследование)», я вдруг понял, что неправильно ее понял с самого начала. Так называемое множественное наследование относится к интерфейсам, наследующим классы, а не к классам, наследующим интерфейсы.
В статье упоминалась абстракция ОО. Как и предложение в статье — «Абстракция — это удаление части изображения», оно очень яркое. Когда я думал об абстракции, мне всегда казалось, что абстракцию сложно понять, ха-ха. , теперь это легко понять. Да, именно это и делают интерфейсы и абстрактные классы.
В статье есть много других точек зрения, которые принесли мне большую пользу, они перечислены ниже:
Я думаю, что суть ОО — это абстракция объектов.
Вкратце, функция интерфейса — обозначить тип класса. Присвоение разных типов классов разным интерфейсам позволяет лучше ими управлять.
Точкой наследования также является абстракция, а не повторное использование кода.
Прочитав эту статью, я теперь в основном понимаю, как применять интерфейсы, абстрактные классы и наследование.
Исходный текст следующий:
Разъяснение Java (интерфейсы и наследование) Мой брат, аспирант второго курса факультета компьютерных наук, обсуждал со мной Java. Когда мы встретились, все вопросы касались интерфейсов. Каково использование интерфейсов? Зачем использовать интерфейсы? Когда следует использовать интерфейсы? Я рад, что меня не спросили, как подключиться к SQL Server с помощью Java или как разрабатывать приложения J2EE. Подобные вопросы смертельны, и их следует избегать. В этом году в Школе информатики есть дипломный проект по J2ME. Студенты, выбравшие эту тему, еще в конце мая с гримасой изучали пакет java.util.*, то и это... вздох.
Большинство людей считают, что цель интерфейсов — заменить множественное наследование. Как мы все знаем, в Java нет механизма множественного наследования, как в C++, но она может реализовывать несколько интерфейсов. На самом деле это надуманно. Интерфейсы и наследование — это совершенно разные вещи. Интерфейсы не имеют возможности заменить множественное наследование, и у них нет такой обязанности. Вкратце, функция интерфейса — обозначить тип класса. Присвоение разных типов классов разным интерфейсам позволяет лучше ими управлять. Я думаю, что суть ОО — это абстракция объектов, и интерфейс лучше всего это воплощает. Мы обсуждаем шаблоны проектирования только для языков с абстрактными возможностями (таких как C++, Java, C# и т. д.), потому что изучение шаблонов проектирования на самом деле заключается в том, как разумно абстрагировать. (Известное высказывание Ковбоя: «Абстракция — это удаление части изображения», что кажется шуткой, но на самом деле это правда).
Самым простым из шаблонов проектирования является шаблон Factory. В очень простом приложении, которое я недавно создал, я хотел сделать все возможное, чтобы сделать мою программу переносимой между несколькими базами данных. Конечно, это связано со многими проблемами, в том числе с обеспечением совместимости SQL. из разных СУБД - это головная боль. С таким же успехом мы могли бы сначала упростить задачу и рассматривать только способы соединения разных баз данных.
Предположим, у меня есть много классов, а именно Mysql.java, SQLServer.java, Oracle.java и DB2.java. Они подключаются к разным базам данных соответственно, одинаково возвращают объект Connection и все имеют метод закрытия соединения. Вам просто нужно выбрать разные классы для вашей СУБД, и вы сможете ее использовать. Но какую базу данных будет использовать мой пользователь? Я не знаю, я надеюсь изменить код как можно меньше, чтобы удовлетворить его потребности. Я могу абстрагировать следующий интерфейс:
пакет org.bromon.test;
общедоступный интерфейс БД
{
java.sql.Connection openDB (URL-адрес строки, пользователь строки, пароль строки);
недействительно закрыть();
}
Этот интерфейс определяет только два метода без какого-либо значимого кода. Конкретный код задается классом, реализующим этот интерфейс, например Mysql.java:
Package org.bromon.test;
импортировать java.sql.*;
публичный класс Mysql реализует БД
{
частная строка url="jdbc:mysql:localhost:3306/test";
частная строка user="root";
личный строковый пароль =»»;
частное подключение;
общедоступное соединение openDB (url, пользователь, пароль)
{
//Код для подключения к базе данных}
public void close()
{
//Закрываем базу данных}
}
Подобные классы, конечно, Oracle.java и т. д. Интерфейсная БД классифицирует эти классы. В приложении мы определяем объект следующим образом:
org.bromon.test.DB myDB;
используйте myDB для работы с базой данных, и вы этого не сделаете. Об этом не стоит беспокоиться. На самом деле я использую так называемый принцип «открыто-закрыто». Но проблема в том, что интерфейс не может быть создан, myDB=new DB(), такой код абсолютно неправильный, мы можем только myDB=new Mysql() или myDB=new Oracle(). Извините, мне все еще нужно указать, экземпляр какого класса нужно создать. Использование интерфейса бесполезно. Итак, нам нужна фабрика:
package org.bromon.test;
общедоступный класс DBFactory
{
публичное статическое соединение с БД getConn()
{
Возврат (новый Mysql());
}
}
Таким образом, код создания экземпляра будет выглядеть следующим образом: myDB=DBFactory.getConn();
Это самая базовая обычная фабрика (Factory) среди 23 режимов. Класс фабрики отвечает за конкретное создание экземпляра того или иного класса, и другая программная логика работает на интерфейсе БД. Это «программирование для интерфейса». Обязанности были переданы классу фабрики. Конечно, вы также можете продолжать определять интерфейс фабрики и продолжать распределять обязанности, что превращается в абстрактную фабрику.
Интерфейс не отвечает за какие-либо конкретные операции в течение всего процесса. Если другие программы захотят подключиться к базе данных, им нужно только сконструировать объект БД, независимо от того, как изменится фабричный класс. В этом суть интерфейсов — абстракция.
Излишне говорить, что концепцию наследования легко понять. Зачем наследовать? Потому что вы хотите повторно использовать код? Это определенно не причина. Суть наследования — абстракция, а не повторное использование кода. Если у объекта A есть метод run(), объект B также хочет иметь этот метод, поэтому кто-то использует класс B, расширяющий A. Это бездумный подход. Если вы создадите экземпляр A в B и вызовете метод Run() A, можно ли достичь той же цели? следующее:
Класс Б
{
А = новый А();
а.запустить();
}
Это использование агрегации классов для повторного использования кода. Это прототип модели делегирования и практика, которую GoF всегда поддерживал.
Так в чем же смысл наследования? На самом деле это вызвано историческими причинами. Исходный объектно-ориентированный язык имел только наследование и не имел интерфейсов, поэтому абстракция могла быть достигнута только посредством наследования. Обратите внимание, что первоначальная цель наследования — это абстракция, а не повторное использование кода (хотя в наследовании тоже есть это). эффект). Это одна из самых серьезных ошибок многих плохих книг по Java. Я не полностью избавился от тени, которую они нанесли. Плохие книги вредны для людей, особенно вводные. Они слишком ядовиты. Когда следует использовать наследование? Используйте его только в абстрактных классах, старайтесь не использовать его в других ситуациях. Абстрактные классы не могут быть созданы. Они предоставляют только шаблон, который иллюстрирует проблему.
Корень всех зол в разработке программного обеспечения, особенно среди программистов C++, — это дублирование кода вместо повторного использования кода и неправильное использование наследования. Целью запрета множественного наследования в Java является прекращение неправильного использования наследования. Это очень мудрый подход, но многие его не понимают. Java может лучше отражать дизайн, и это одна из причин, почему я очарован.