Здравствуйте, lexius, Вы писали:
L>Если очень кратко:
L>абстрактный класс может содержать реализацию.Иногда это удобно.
L>Если приложение правильно проектируется с точки зрения ООП, то очень часто самый первый класс в цепочке наследования — абстрактный. L>Все стальное — в посте выше, там более подробно.
Прощу прощения за расплывчатую формулировку. Вот здесь
Если работа идет с некой "недоменной" областью — то есть technology for technology — то как правило всегда использую только интерфейсы.
Если проектируется часть соотв. некой доменной области — простой подход такой:
Интерфейсы описывают в большей степени свойства объектов, в то время как классы — это is a отношение.
Абстрактный класс Cat это куда сильнее чем некий интерфейс Feedable. Интерфейсы позволяют описать некую общность поведения,
в то время как абстрактные классы это еще и общность состояний и свойств.
wbr,
Igor
Re[2]: Проектирование: интерфейс vs абстрактный класс
Здравствуйте, Pharod, Вы писали:
P>Если работа идет с некой "недоменной" областью — то есть technology for technology — то как правило всегда использую только интерфейсы.
Я встречал в таком виде: "Если задумался над тем, класс это или интерфейс, то это интерфес". Задачи с "недоменной" областью в этом смысле, пожалуй, проще анализировать.
P>Если проектируется часть соотв. некой доменной области — простой подход такой: P>Интерфейсы описывают в большей степени свойства объектов, в то время как классы — это is a отношение. P>Абстрактный класс Cat это куда сильнее чем некий интерфейс Feedable. Интерфейсы позволяют описать некую общность поведения, P>в то время как абстрактные классы это еще и общность состояний и свойств.
Ваши аргументы приняты. Попробую уточнить вопрос.
Классический пример — "простой графический редактор". Идем по классическому пути: редактор работает с фигурами. Треугольник, круг, квадрат. Логично предложить их в качестве кандидатов в классы. Абстрактный класс Фигура тоже выглядить уместным.
Теперь добавим в редактор точку. Точка — это фигура? Или правильнее выделить интерфейсы Drawable, Resizeable, etc?
Как поступить на этапе анализа задачи?
Re[3]: Проектирование: интерфейс vs абстрактный класс
Здравствуйте, boluba, Вы писали:
B>Классический пример
А почему не подходит классическое решение? В данном случая я бы использовал абстарктный класс для создания заглушек под все методы.
Мне интерессно вот чего:
наследование абстрактного класса дороже чем наследование интерфейса ?
Re[3]: Проектирование: интерфейс vs абстрактный класс
B>Классический пример — "простой графический редактор". Идем по классическому пути: редактор работает с фигурами. Треугольник, круг, квадрат. Логично предложить их в качестве кандидатов в классы. Абстрактный класс Фигура тоже выглядить уместным.
B>Теперь добавим в редактор точку. Точка — это фигура? Или правильнее выделить интерфейсы Drawable, Resizeable, etc? B>Как поступить на этапе анализа задачи?
"правильнее" это нехорошее слово — проектирование ради проектирования удел тех, у кого много времени.
если перед вами стоит задача создать графический редактор — оцените требования.
если есть требование, к примеру, поддержать разные predefined фигуры в качестве плагинов — стройте фрэймворк
на интерфейсах, определяйте default behavior с помощью абстрактных имплиментаций.
если просто нужно уметь рисовать точки и три стандартные фигурки, обладающие 100% сходным поведением — думаю
подойдет абстрактный базовый класс вполне. является ли точка фигурой — вопрос сложный. тут опять нужны требования.
можно ли рисовать карандашом? использовать кисти? как раценивать нарисованную юзером карандашом кракозябру?
сильно зависит от того растровый ли это редактор или же векторный.
короче — смотреть детали, оценивать требования, не боятся ошибится. ну заэкстрактите вы потом интерфейсы если
назреет необходимость — чай не конец света :)
извините что так абстрактно отвечаю — но, как говорят, "правильно сформулированный вопрос содержит не менее 80% ответа" :)
и это все сугубо IMHO.
wbr,
Igor
Re[5]: Проектирование: интерфейс vs абстрактный класс
Здравствуйте, boluba, Вы писали:
B>Тут можно спорить. Использование UnsupportedOperationException прямо и подробно описано в документации по Collections Framework. Насколько я понимаю, вы считаете, что раз уж класс реализует интерфейс (контракт), то должен его реализовывать (исполнять) полностью. Но если еще раз подумать, то выброс UnsupportedOperationException является неотемлемой частью контракта в данном контексте, не находите? На ваш взгляд было бы лучше вместо десятка интерфейсов и базовых реализаций иметь сотни конкретных частных решений, не выбрасывающих UnsupportedOperationException?
Я говорю не о конкретной реализации. Возможно тут Джошуа Блох и г-н Моринеску сделали все как посчитали нужным и правильным. Я лишь говорю, что они исказили "нормальность" использования абстрактных классов. По двум причинам.
1. Явно перегрузили методы интерфейса, сделав их абстрактными. (можно было просто ничего не писать и не путать этим следы)
2. Явно "реализовали" методы интерфейса, которые не используются в базовом функционале и реализованы так, что в рантайме (не не в компиляции) говорят о том, что они на самом деле не реализованы.
По этим двум пунктам я и говорил, что Collection Framework является плохим примером Interface -> Abstract Class -> Implementation Class.
Т.е. если абстрактный клас заявляет себя базовым, то он должен:
1. Не трогать методы интерфейса, которые он не собирается реализовывать в базовом варианте.
2. Реализовать методы интерфейса в базовом варианте по возможности с модификатором final!
3. При необходимости дополнения базовой фнкциональности он должен ввести дополнительные абстрактные методы с модификатором protected.
Замечу также, что оставление возможности перегрузки методов интерфейса реализованных в базовом абстрактном классе является также не очень хорошим примером. Потому, что в любой реализации можно изменить базовый функционал таким образом, а он меняться не должен.
Re[3]: Проектирование: интерфейс vs абстрактный класс
Здравствуйте, boluba, Вы писали:
B>Классический пример — "простой графический редактор". Идем по классическому пути: редактор работает с фигурами. Треугольник, круг, квадрат. Логично предложить их в качестве кандидатов в классы. Абстрактный класс Фигура тоже выглядить уместным.
Относительно различий между интерфейсом и абстрактным классом. Ответ: с точки зрения проектирования нет никакой разницы. Различия чисто языковые, т.к. Java и C# не поддерживают множественного наследования.
Здравствуйте, boluba, Вы писали:
B>Могли бы вы ответить на простой вопрос: В каких случаях при проектировании вы делаете выбор в пользу интерфейса, а в каких — в пользу абстрактного класса?
если я правильно интерпретирую канонические книги, то применять нужно всегда интерфейс
за исключением тех случаев, когда без наследования (кроме как большой кровью) не обойтись.
Re[2]: Проектирование: интерфейс vs абстрактный класс
Здравствуйте, mike_sikalo, Вы писали:
_>если я правильно интерпретирую канонические книги, то применять нужно всегда интерфейс _>за исключением тех случаев, когда без наследования (кроме как большой кровью) не обойтись.
У Эккеля так написано в TIJ, если ничего не путаю.
Ветка ушла совсем в сторону от того, что я хотел спросить. Попробую еще раз в новой ветке.
