Меню
Что нового?

Как отличить абстрактный класс от "реального"

  • Автор темы Автор темы Cellard
  • Дата начала Дата начала
Adelf, ладно. Скажу по другому. Есть метод без какой бы то реализации - это абстракция. Есть метод для различной обязательной реализации - это интерфейс.
 
jonjonson, вы не все случаи рассматриваете. Как назвать абстрактный класс, в котором все методы реализованы? Как назвать интерфейс без объявления методов? Они имеют право на существование?
 
Cellard, класс в котором все методы реализованы называется в любом случае не абстрактным.
 
jonjonson, ну, в таком случае, вот вам пример не абстрактного класса:
PHP: 
abstract class ClassName {
  public function TheMethod()
  {
    return __METHOD__;
  }
}
 
Угу. Только это не абстрактный класс
PHP: 
abstract ClassName {
  abstract public function TheMethod()  {}
}
А вот это абстрактный
 
Cellard, вы скорее всего ведёте речь о переопределении методов при наследовании. Абстрактные классы нужны на этапе разработки и дальнейшей поддержки кода.
 
Вы меня в конец запутали своими парадоксальными, на мой взгляд, утверждениями. Прежде, чем мы продолжим, ответьте еще на один вопрос.

Какой это класс?
PHP: 
abstract class ClassName {
  public function TheMethod()
  {
    return __METHOD__;
  }
  abstract public function AMethod() { }
}
 
Cellard, это абстрактный :)
Конечно можно заявить класс со всеми реализованными методами абстрактным. Но в этом нет смысла.
 
AmdY написал(а):
но правильный ответ дали в первом же посте, ты не должен этого хотеть.
Нажмите для раскрытия...

Но никто так и не объяснил, почему. Объясните, это пойдет на пользу и мне, и другим читателям.

jonjonson написал(а):
Конечно можно заявить класс со всеми реализованными методами абстрактным. Но в этом нет смысла.
Нажмите для раскрытия...

То, что вы не видите в этом смысла, не дает вам права утверждать, что такой класс не является абстрактным.
 
Cellard. то есть далее на ваши вопросы можете отвечать вы сами? Феерично.
 
jonjonson
ну не прав ты. Спорили мы уже тут про абстрактные классы. дело даже дошло до правки в википедии его определения :)
Дошли примерно до такого:
"Абстрактный класс в объектно-ориентированном программировании — базовый класс, который не предполагает создания экземпляров."
Все! Очень советую не продолжать людям мозг канифолить своими представлении о данной сущности. А перечитать в умных книгах. Если твоя практика разработки предполагает другой смысл для абстрактного класса - то это только ТВОЯ практика. Не общепринятая.

По нужности этого для ТСа добавить к его последнему посту нечего. Это БЫВАЕТ нужно. Изредка. Как и в данном случае.
 
Cellard написал(а):
Попробую...

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

нарушается принцип единой ответственности класса. Проверку прав доступа лучше вынести в отдельный класс

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

сам же вопрос как проверить является ли класс абстрактным вполне нормальный и делается через Reflection, как уже и было сказано
(хотя так сходу не могу придумать ситуацию в которой это было бы нужно)
 
jonjonson
если в определении класса есть слово abstract - значит он абстрактный ;)
 
A1x, в определении класса можно рисовать всякие извращения которые не имеют отношения к ООП.
 
jonjonson
нет. и это единственное, что объединяет интерфейсы и абстрактные классы(АК).
АК может содержать реализацию, а интерфейс - нет.
 
Cellard написал(а):
Но никто так и не объяснил, почему. Объясните, это пойдет на пользу и мне, и другим читателям.
Нажмите для раскрытия...
потому что это противоречит всем принципам ООП.

копание в предках нарушает абстракцию, потому что класс становится зависимый от своей иерархии.
нарушает инкапсуляцию, потому что раскрывается реализация.
нарушает полифоризм, потому что помимо интерфейса становится важна информация о типе и внутренное структуре
.........
 
Adelf, АК может содержать реализацию базовых методов. Интерфейсу это то же не возбраняется :)
 
Войдите или зарегистрируйтесь для ответа.
Сверху