BlazkowiczКак вариант - Java Proxy работают только на интерфейсах. Фреймверки их используют для реализации AOP.

В EJB 3.1 использование интерфейсов уже не обязательно.

А по топику, вопрос к автору зачем вообще нужны интерфейсы?
Представьте ситуацию что вы работаете в команде и пишите модуль который взаимодействует с базой по средством DAO, другой человек используя ваш ДАО пишет бизнес логику в другом модуле, вы можете написать публичный интерфейс вашего ДАО с джавадоками и.т.д и закомитить его, а потом потихоньку заниматься его имплементацией, в то время как другой девелопер независимо от вас пишет бизнеслогику и юнитесы мокая ваш интерфейс. Потом выяснилось что ваша имплементация хороша при редких запросах, а при частых тормозит, а третий модуль как раз делает частые запросы. Соответственно вы пишете вторую имплементацию для частых запросов и инжектите ее в интерфейс в третьем модуле.

Petro123OOsalivan,
точно так можно сделать на ООП\классах без интерфейсов.
И ещё есть куча способов "разделения труда".
Т.е. шаблоны-подходы сейчас очень быстро меняются.

Писать на ООП\классах без интерфейсов - это С++ стаил.

Здесь это хорошо выражено:
"В C++ класс неявно определяет интерфейс. И в силу этого одновременно объявляет тип. При этом единственный интерфейс связывается с единственной реализацией. Множественное наследование и абстрактные классы в C++ - это прежде всего попытка обойти жесткую детерминированность.
В Java подобного ограничения нет. Любой интерфейс (тип) может иметь много реализаций. Любой класс может реализовывать много интерфейсов."

ООП в java как раз и подразумевает программирование через интерфейсы. В качестве "бест практик" советую посмотреть код например для:
java.util
java.util.concurrent

Вообще заметил такую особенность, что многие люди пришедшие из С++ в java упорно продолжают писать по своему - на выходе говнокод

Petro123OOsalivan,
"Сделай настолько просто, насколько это возможно, но не проще". © А. Эйнштейн.
Практика Java говорит об усложнённости и многословности.
Также заметил особенность, что в Java много зашоренности шаблонными подходами (скоро синглетон забудем).
а говнокод есть везде.

Ни везде, а там где люди не понимают и не хотят учиться даже основам, типо зачем мне читать книги по яве если я на ООП в сях два года лобал. Грамотное применение шаблонов уменьшает количество кода в разы, и увеличивает на порядок его читаемость. Заметил что люди не используют шаблоны просто потому что глубоко в них не вникали да и не хотят, но в последствии отсутствие шаблонов в базовых вещах в больших проектах приводит к классам на 6 тысяч строк в процедурном стиле и дублированию - что и есть говнокод.

Petro123OOsalivanк классам на 6 тысяч строк в процедурном стиле и дублированию - что и есть говнокод.не всё так однозначно
- тут рядом тема была про интерфейсы. Люди настолько привыкли их пихать налево и направо, что не замечают разницу между ними и абстрактным классом
- конечно, я привёл Статистику - продажную девку империализма
- процедурный стиль в Java идёт автоматом, т.к. очень много кода снаружи в виде контейнера.
А люди потом спрашивают: "Куда положить объект долгожитель (межсессионный)".
Какой нафиг ООП, если в Java есть VO \ POJO \... Т.е. сложные объекты не поддерживает инфраструктура.
Попробуйте передать объект DataSet на другой сервер.
- уровень сервиса, это как раз и есть процедурный подход (вынос логики за сущности)
Я не спорю, интерфейсы в Java имеют иной смысл.
Взять MS, который их породил вместе с COM и потом их убил
Microsoft отказывается от компонентной объектной модели
http://soft.compulenta.ru/44742/

Забудет про С++ MS COM и.т.д - если вы рассуждаете о яве. Здесь совсем другая идеология. Почитайте Джошуа Блоха, а еще лучше вместе с тем посмотрите как он писал классы из того же java.util.*

Процедурный стиль в яве идет от неграмотности разработчиков. Что вы хотели выразить "очень много кода снаружи в виде контейнера" ? Если вы про аспектно ориентированное программирование, которое в тех же EJB (спринг) контейнерах реализовано по средством проксирования, то АОП вовсе не исключает ООП, а его дополняет.

POJO - простой Java-объект, не унаследованный от какого-то специфического объекта и не реализующий никаких служебных интерфейсов сверх тех, которые нужны для бизнес-модели. VO - объект содержащий значение. Чем они вам не угодили в планге ООП ?

>>"Попробуйте передать объект DataSet на другой сервер" - шедевр ))) зачем??

>> "- уровень сервиса, это как раз и есть процедурный подход (вынос логики за сущности)"
Это не вынос логики за сущность - а вынос логики не относящейся к данной сущности в отдельную - сервис, что и является одной из основ ООП

Petro123OOsalivanПисать на ООП\классах без интерфейсов - это С++ стаил.
Здесь это хорошо выражено:

интересная ссылка, но:
автор* Образец бесклассовой реализации
я против.
Удачи!

Т.е вы против :
java.util.Collection
java.util.List
java.util.Set
java.util.Map
....
и.т.д ?