Интерфейс ничего не реализует :)

Но интерфейс следует по контракту SoR, так как выполняет только одну задачу: конвертирует экземпляр одного типа в другой тип (или тот же, в контракте не декларируется).

Юнит-тесты тестируют реализацию (юнита).
Интерфейсы же позволяют протестировать конкретную реализацию изолировано от зависимостей.

Был вопрос про метрику оценки, я сказал пример такой метрики: тесты.
Однако юнит-тесты пишутся не для этой метрики, это просто дополнительный бонус.



Это принцип, нарушение которого приводит к увеличению сложности и другим неприятным эффектам. Вывели эти принципы эмпирическим путём. В общем-то любые методики, методологии и практики были выведены для того, чтобы не наступать на грабли, которые отбили лоб не одной тысяче людей.



Речь не в количестве методов. А об программной ответственности. Не так сложно понять, решает ли класс одну конкретную задачу, или несколько слабо связанных задач.

Следование этому принципу порождает увеличение количество классов. Что иногда приводит некоторых людей в ужас. Дескать, зачем же плодить классы, когда можно было всё запихать в один.

Полагаю на заре дисциплины, декомпозиция программы на процедуры могла вызывать такой же батхёрд у мамонтов программирования с их километровыми листингами, напичканными GOTO

mayton,

Ну и самое главное. Как же применять SOLID на практике?
Кого не спросишь:

— ну... знаю, что-то слышал, что-то читал, готов раскрыть значение каждой буквы
— ну... да, применяю... там...

Да-да, написав каждую строчку кода сижу и задумываюсь, а соответствует ли он солиду, солидный ли мой код? )))

Но ответ лежит на поверхности, особенно для людей, работающих в команде с применением код ревью.

Звучит как признание в нарушениях ПДД )



SOLID лежит сугубо в практической и только практической плоскости.
Ничем философским тут не пахнет и в помине :)

Насчёт того, что видят каждый своё, ну а как в таких условиях вы собираетесь вести командную работу в принципе? Типа два художника каждый со своим больным воображением пришли рисовать единую картину?



Популярные проекты на гитхабе зачастую отличаются очень высоким качествам.



Ну так вот и хотелось бы разобраться, какие у вас есть с ней проблемы.

Вполне уместно рассмотреть на примере репозитория, о чём говорит skyANA.

Нашлёпка какая-то над хибером c нетипизированными JPQL запросами :)

В .NET это Entity SQL. Ну и при большой любви к хиберу можно подключить NHibernate и писать HQL )
Не исключаю, что стырили идею как раз из JPA.

Но какой смысл писать объектные запросы, если нет информации о типах, как в LINQ? Ни тебе статической проверки на этапе компиляции, ни интеллисенса (хотя может идея как-то умеет, не исключаю).

Фишка LINQ, что написанный запрос может как транслироваться в БД, так и оперировать самыми обычными коллекциями объектов в памяти. Универсально.

Если уж писать запросы в строках, то имеет смысл писать из БД, а не к промежуточной нашлёпке.





Т.е. если у тебя есть JPA, тебе не нужен репозиторий? )))

А что не верно в формулировке? JPA это спецификация, при чём языка JPQL основан на HQL. Hiber реализует JPA.

Скорректируешь?

Ясно ) Ну нашлёпка же, над хибером. При чём если ты используешь расширенные возможности хибера, то смысл в спецификации становится всё менее ценным, так как на другую реализацию уже перейти не получится в принципе.

Почему же тёмный?

https://en.wikipedia.org/wiki/Java_Persistence_Query_Language

JPQL is based on the Hibernate Query Language (HQL), an earlier non-standard query language included in the Hibernate object-relational mapping library.

Hibernate and the HQL were created before the JPA specification. As of Hibernate 3 JPQL is a subset of HQL.

Опять врут и темнят? )

Да смена ORM это вообще мифическая фича, кто в здравом уме в большом живом проекте будет менять ORM? Даже со сменой СУБД будут явые проблемы.

Это так, небольшой наброс )