В этой статье описывается использование интерфейсов Java и абстрактных классов. Поделитесь этим для вашей ссылки, следующим образом:
интерфейс
1 Поскольку Java не поддерживает множественное наследование, с интерфейсами, класс может наследовать только один родительский класс, но может реализовать несколько интерфейсов, а сам интерфейс также может наследовать несколько интерфейсов.
2 Переменные элемента в интерфейсе имеют публичный статический финальный тип по умолчанию. Инициализация, которая должна отображаться.
3 Методы в интерфейсе имеют публичную абстрактную абстракту по умолчанию. Неявное объявление.
4 Интерфейс не имеет конструктора и не может быть создан.
5 Интерфейс не может реализовать другой интерфейс, но может наследовать несколько интерфейсов.
6 Если класс реализует интерфейс, то должны быть реализованы все абстрактные методы в интерфейсе, в противном случае класс должен быть определен как абстрактный класс.
Аннотация класс
1 Если класс объявлен как абстрактный, этот класс не может генерировать объекты и может использоваться только унаследованным.
2 абстрактные методы должны существовать в абстрактных классах.
3 могут быть общие переменные и общие методы в абстрактных классах.
4 Подклассы наследуют абстрактный класс, должны реализовать свои абстрактные методы, если только подкласс не является абстрактным классом.
private void print () {}; Это утверждение представляет пустую реализацию метода.
Abstract void print (); Это утверждение представляет абстракцию метода без реализации.
Разница между интерфейсом и абстрактным классом
1 Интерфейс может содержать только абстрактные методы, а абстрактные классы могут содержать обычные методы.
2 Интерфейс может определять только статические постоянные свойства. Абстрактные классы могут определять как обычные свойства, так и статические постоянные свойства.
3 Интерфейс не содержит методов конструктора, а абстрактные классы могут содержать методы конструктора.
Абстрактный класс не может быть создан создан, но не означает, что он не может иметь конструктор. Аннотация класса может иметь конструктор и является заменой класса.
1 Интерфейс - это ядро, которое определяет, что делать, и содержит много методов, но не определяет, как эти методы должны быть сделаны.
2 Если многие классы реализуют интерфейс, то каждый из них должен реализовать эти методы в коде.
3 Если в реализации некоторых классов есть что -то общее, абстрактный класс может быть абстрактным, чтобы позволить абстрактному классу реализовать общий код интерфейса, в то время как эти персонализированные методы реализованы каждым подклассом.
Поэтому абстрактные классы предназначены для упрощения реализации интерфейсов. Они не только предоставляют реализацию общественных методов, позволяя вам быстро развиваться, но также позволяют вашим классам реализовать все методы сами по себе без проблем с жесткими связями.
Приложение очень простое
1. Определите интерфейсы сначала
2 Если есть несколько реализаций интерфейса, которые имеют общие части, используют абстрактные классы и интегрируют их.
Разница между интерфейсом и абстрактным классом-я считаю, что вы не будете запутаны после прочтения его
Я думаю, что для программистов, которые используют объектно-ориентированные языки программирования, термин «интерфейс» должен быть знаком, но мне интересно, есть ли у вас такие сомнения: какова цель интерфейса? В чем разница между ним и абстрактными классами? Можно ли использовать абстрактные классы вместо интерфейсов? Более того, как программисты, вы должны часто слышать фразу «интерфейсное программирование», так что это значит? Что такое идеологическая коннотация? Каковы отношения с объектно-ориентированным программированием? Эта статья ответит на эти вопросы один за другим.
1. Какова взаимосвязь между программированием, ориентированным на интерфейс и объектно-ориентированным программированием
Прежде всего, ориентированное на интерфейс программирование и объектно-ориентированное программирование не являются горизонтальными. Это не независимая идея программирования, которая является более продвинутой, чем объектно-ориентированное программирование, но прикреплена к объектно-ориентированной системе мышления и принадлежит ее части. Другими словами, это одна из сущности мысли в объектно-ориентированных системах программирования.
2. природа интерфейса
Интерфейс якобы состоит из нескольких определений методов без кода тела. Он имеет уникальное имя и может быть реализован классом или другим интерфейсом (или также можно сказать, что он унаследован). Это может выглядеть как следующее в форме:
Интерфейс InterfaceName {void method1 (); void method2 (int para1); void Method3 (String para2, String para3); }Итак, в чем суть интерфейса? Или что означает существование интерфейса? Я думаю, что это можно рассмотреть с следующих двух точек зрения:
1) Интерфейс - это набор правил, которые указывают набор правил, которые должны иметь класс или интерфейс, который реализует этот интерфейс. Это воплощает концепцию природы, что «если вы ... вы должны быть в состоянии ...»
Например, в природе люди могут есть, то есть «если вы люди, вы должны иметь возможность есть». Затем при смоделировании в компьютерной программе должен быть интерфейс Iperson (индивидуально, имя интерфейса начинается с «I») интерфейса, и есть метод под названием eat (). Затем мы предусматриваем, что каждый класс, представляющий «человека», должен реализовать интерфейс Iperson, который имитирует естественное правило «Если вы человек, вы должны иметь возможность есть».
Отсюда, я думаю, вы также можете увидеть некоторые объектно-ориентированные идеи. Одним из ядер объектно-ориентированного мышления является имитация реального мира и абстрактных вещей в реальном мире в категории. Вся программа опирается на экземпляры различных типов, чтобы общаться друг с другом и сотрудничать друг с другом, чтобы выполнить функции системы. Это очень согласуется с условиями эксплуатации реального мира, а также является сущностью объектно-ориентированного мышления.
2) Интерфейсы являются абстрактными представлениями о похожих вещах с определенным гранулированным взглядом. Обратите внимание, что здесь я подчеркиваю определенное гранулированное представление, потому что концепция «то же самое» относительно, и она варьируется из -за различных гранулированных взглядов.
Например, в моих глазах я человек, и между мной и свинью есть фундаментальная разница. Я могу принять утверждение, что мои одноклассники и я одинаковы, но я не должен принять, что я такой же, как свинья. Однако, если глаза зоолога похожи на свиней, я должен быть одинаковым, потому что мы оба животные, он может думать, что как «человеческие», так и «свинья» реализовали Ианимальный интерфейс. Когда он изучает поведение животных, он не будет относиться ко мне и свиньям отдельно, но будет изучать его из большего размера частиц «животного», но он будет думать, что между мной и деревом существует важная разница.
Теперь, когда я изменился на генетика, ситуация отличается. Поскольку все живые существа могут быть унаследованы, в его глазах, я не только ничем не отличается от свиней, но и от комара, бактерий, дерева, гриба или даже вируса SARS, потому что он подумал бы, что мы все внедрили все ее вещания. Он не будет изучать нас отдельно, но будет изучать все живые существа как похожие типы. В его глазах нет никакой разницы между людьми и вирусами, только наследственными веществами и нежимыми веществами. Но, по крайней мере, между мной и камнем все еще есть разница.
Но, к сожалению, однажды на земле появился великий человек по имени Ленин. После того, как он был знаком с Максом и Шедевром Энгельса диалектического материализма, у него был большой опыт, поэтому он дал знаменитое определение: так называемый вопрос-это объективная реальность, которая может быть отражена сознанием. На этом этапе я больше не отличается от камня, следа воздуха, идиомы и электромагнитного поля, которое передает сигналы мобильного телефона, потому что в глазах Ленина мы все являемся объективной реальностью, которая может быть отражена сознанием. Если бы Ленин был программистом, он бы сказал: так называемый вопрос-это случаи, генерируемые всеми классами, которые реализуют два интерфейса «Ireflectabe» и «iesse». (ПРИМЕЧАНИЕ: Отражает v. Отражайте эссе N. Объективная реальность)
Может быть, вы подумаете, что мой пример выше - чепуха, но это именно то значение интерфейса. Одной из объектно-ориентированных идей и ядра является полиморфизм. Что такое полиморфизм? Говоря о том, чтобы без разбора обращаться с похожими вещами на определенном уровне гранулированного обзора и обработки их равномерно. И причина, по которой я осмелюсь сделать это, заключается в том, что есть интерфейс. Как и этот генетик, он понимал, что все организмы реализовали идентифицируемый интерфейс. Пока они являются организмами, должен быть метод потушения (), чтобы он мог изучать их единым образом, не изучая каждый организм отдельно и в конечном итоге утомительно.
Может быть, мы не можем дать вам интуитивное впечатление о природе и функции интерфейса. Затем в следующих примерах и анализе нескольких шаблонов проектирования вы будете более интуитивно испытывать смысл интерфейса.
3. Резюме программирования ориентированного на интерфейс
Через приведенную выше статью, я думаю, что у вас есть понимание идеологической коннотации интерфейсов и интерфейсов. Так что же такое программирование, ориентированное на интерфейс? Мое личное определение: в системном анализе и архитектуре мы различаем иерархии и зависимости. Каждый уровень напрямую не предоставляет услуги своему верхнему слою (то есть не напрямую создан в верхнем слое), а вместо этого определяет набор интерфейсов, только выявляя свои функции интерфейса на верхний слой. Верхний слой зависит только от нижнего слоя и не полагается на конкретные классы.
Преимущества этого очевидны, и, прежде всего, это очень полезно для гибкости системы. Когда нижний слой должен быть изменен, до тех пор, пока функции интерфейса и интерфейса остаются неизменными, верхний слой не должен вносить какие -либо модификации. Вы даже можете заменить нижний слой, не изменяя код верхнего уровня, точно так же, как мы заменяем жесткий диск WD 60G на жесткий диск Seagate 160G. Нет необходимости вносить какие -либо изменения в других частях компьютера, но просто отключить исходный жесткий диск и подключить новый жесткий диск, потому что другие части компьютера не полагаются на конкретный жесткий диск, а только полагаются на интерфейс IDE. Пока жесткий диск реализует этот интерфейс, его можно заменить. Отсюда интерфейс в программе очень похож на интерфейс в реальности, поэтому я всегда верил, что интерфейс слова действительно похоже!
Другим преимуществом использования интерфейсов является то, что разработчики различных компонентов или уровней могут начать конструкцию параллельно, как и те, кто строит жесткие диски, не нужно делать процессоры или мониторы. Пока интерфейсы являются последовательными, а дизайн разумный, разработка может быть проведена параллельно, тем самым повышая эффективность.
Эта статья придет здесь первой. Наконец, я хотел бы сказать что-то еще: сущность объектно-ориентированной-имитировать реальность, которая также можно сказать, что является душой моей статьи. Следовательно, размышление о объектно-ориентированных вещах от реальности будет иметь большую пользу для улучшения анализа системы и проектирования.
В следующей статье я буду использовать пример, чтобы показать основные методы программирования интерфейса.
В третьей статье я проанализирую некоторые идеи программирования, ориентированные на интерфейс в классическом шаблоне дизайна, и проанализирую ориентированные на интерфейс идеи в иерархической архитектуре .NET.
Дополнение к этой статье:
После тщательного чтения ваших ответов я очень рад обсудить с вами технические проблемы. Спасибо вашим друзьям, которые дали подтверждение, а также вашим друзьям, которые выдвинули мнения и вопросы, которые побудили меня более глубоко задуматься о чем -то и надеяться добиться прогресса в этом. Здесь я хотел бы добавить что -то, чтобы обсудить некоторые из более концентрированных вопросов в ответах.
1. Относительно двух слов «интерфейс» в «Программировании интерфейса» и конкретном объектно-ориентированном языке «интерфейс»
Я видел, как друг, предполагающий, что слово «интерфейс» в «ориентированном на интерфейс программирования» должно иметь больший диапазон, чем интерфейс на простом языке программирования. Подумав об этом, я подумал, что это имеет смысл. То, что я написал здесь, действительно неразумно. Я думаю, что «интерфейс» на объектно-ориентированном языке относится к конкретной структуре кода, такой как интерфейс, определенный в C# с ключевым словом интерфейса. Можно сказать, что «интерфейс» в «ориентированном на интерфейс программирования» является структурным компонентом, который относится к более абстрактному уровню с точки зрения архитектуры программного обеспечения и более абстрактного уровня. В этом смысле, если определяется абстрактный класс, и цель состоит в том, чтобы достичь полиморфизма, то я думаю, что разумно назвать этот абстрактный класс также «интерфейс». Но разумно ли использовать абстрактные классы для реализации полиморфизма? Обсудите во второй статье ниже.
Таким образом, я думаю, что понятия двух «интерфейсов» разные и связаны друг с другом. Интерфейсы в «Программировании, ориентированном на интерфейс», являются архитектурными компонентами на идеологическом уровне для реализации полиморфизма, повышения гибкости и обслуживания программного обеспечения, в то время как «интерфейсы» на определенных языках являются средством для реализации компонентов в этой идее в код.
2. О абстрактных классах и интерфейсах
Я видел, что это была более интенсивная проблема в ответе. Извините, я плохо думал об этой проблеме в статье. Мое личное понимание этой проблемы заключается в следующем:
Если мы рассмотрим только конкретный код, эти две концепции легко размыть, и мы даже думаем, что интерфейс является избыточным, потому что только из конкретной функции, за исключением множественного наследства (C#, в Java), абстрактные классы, похоже, могут полностью заменить интерфейсы. Однако наличие интерфейсов для достижения множественного наследования? Конечно, нет. Я думаю, что разница между абстрактными классами и интерфейсами - это мотивация для использования. Использование абстрактных классов предназначено для повторного использования кода, в то время как мотивация для использования интерфейсов предназначена для полиморфизма. Итак, если вы колеблетесь к тому, использовать ли где -нибудь интерфейс или абстрактный класс, то вы можете подумать о том, что такое ваша мотивация.
Увидев сомнения друга в отношении интерфейса Iperson, мое личное понимание состоит в том, что следует ли определить интерфейс Iperson, зависит от конкретного приложения. Если в нашем проекте есть женщины и мужчины, как наследственный человек, и большинство методов женщин и мужчин одинаковы, и существует только один метод, DosomethingTementInwc () отличается (пример вульгар, пожалуйста, простите меня), то, конечно, более разумно определить абстрактный класс, потому что он может включать все другие, и все, что определяет, что в одном из них, которые могут быть определены, которые могут быть определены, которые могут включить все другие, и все это определяет. код
Однако, если классы женщин и мужчин в нашей программе в основном не имеют общего кода, и есть класс человека, который должен их создавать, и не хотят знать, являются ли они мужчин или женщинами, а просто относятся к ним как к людям и внедряют полиморфизм, то необходимо определить их как интерфейсы.
Короче говоря, разница между интерфейсом и абстрактным классом в основном связана с мотивацией для использования, а не сама. Когда вещь должна быть определена как абстрактный класс или интерфейс, она должна быть определена на основе контекста конкретной среды.
Кроме того, я думаю, что еще одно различие между интерфейсом и абстрактным классом заключается в том, что между абстрактным классом и подклассом должны быть общие и особые отношения. (Конечно, могут быть общие и особые отношения, но цель использования интерфейсов здесь нет.) Например, приемлемо определять транспортные средства как абстрактные классы, а автомобили, самолеты и суда в качестве подклассов, потому что автомобили, самолеты и суда являются всеми специальными транспортными средствами. Например, интерфейс Icomparable просто говорит, что классы, которые реализуют этот интерфейс, должны быть в состоянии сравнить, что является правилом. Если класс автомобиля реализует Icomplable, это просто означает, что в нашем автомобиле есть способ сравнить два экземпляра автомобиля, которые могут быть дороже, чем автомобиль или больше, чем автомобиль. Это не имеет значения, но мы не можем сказать, что «автомобили являются особенными и могут сравниваться», что не применимо грамматически.
Я надеюсь, что эта статья будет полезна для всех Java Programming.