Защо да настояваме всички реализации на интерфейс да разширяват базов клас?

Мисля, че това, което се случи, е, че първоначално API за съпоставяне беше създаден под формата на интерфейс.
След това, докато внедрявахме интерфейса по различни начини, беше открита обща кодова база, която след това беше преработена в класа BaseMatcher.

Така че моето предположение е, че интерфейсът на Matcher е запазен, тъй като е част от първоначалния API, а описателният метод след това е добавен като напомняне.

След като претърсих кода, открих, че интерфейсът може лесно да бъде премахнат, тъй като се изпълнява САМО от BaseMatcher и в 2 тестови единици, които лесно могат да бъдат променени, за да използват BaseMatcher.

Така че, за да отговоря на въпроса ви - в този конкретен случай няма предимство да го правите по този начин, освен че не нарушавате реализациите на Matcher на други хора.

Що се отнася до лошата практика? Според мен е ясно и ефективно - така че не, не мисля така, просто малко странно :-)

Hamcrest осигурява съвпадение и само съвпадение. Това е малка пазарна ниша, но изглежда, че се справят добре. Реализациите на този интерфейс на Matcher са разпръснати в няколко библиотеки за тестване на единици, вземете например ArgumentMatcher и в глупаво голямо количество малки анонимни копиране-поставяне на реализации в модулни тестове.

Те искат да могат да разширят Matcher с нов метод, без да нарушават всички тези съществуващи класове за изпълнение. Те биха били адски ъпгрейд. Само си представете внезапно всички ваши класове unittest да показват гневни червени компилационни грешки. Гневът и раздразнението биха убили пазарната ниша на hamcrest с един бърз замах. Вижте http://code.google.com/p/hamcrest/issues/detail?id=83 за малък вкус на това. Също така, критична промяна в hamcrest ще раздели всички версии на библиотеки, които използват Hamcrest, на преди и след промяната и ще ги направи взаимно изключващи се. Отново адски сценарий. Така че, за да запазят известна свобода, те се нуждаят от Matcher да бъде абстрактен базов клас.

Но те също са в подигравателния бизнес и интерфейсите са много по-лесни за подиграване от базовите класове. Когато хората от Mockito тестват Mockito, те трябва да могат да се подиграват на съвпадащия. Така че те също се нуждаят от този абстрактен базов клас, за да имат интерфейс на Matcher.

Мисля, че са обмислили сериозно вариантите и са открили, че това е най-малко лошата алтернатива.

Има интересна дискусия за това тук. За да цитирам nat_pryce:

здрасти Написах оригиналната версия на Hamcrest, въпреки че Джо Уолнс добави този странен метод към базовия клас.

Причината е особеност на езика Java. Както каза коментатор по-долу, дефинирането на Matcher като базов клас би улеснило разширяването на библиотеката, без да прекъсва клиентите. Добавянето на метод към интерфейс спира компилирането на всички изпълняващи класове в клиентския код, но нови конкретни методи могат да се добавят към абстрактен базов клас, без да се нарушават подкласовете.

Има обаче функции на Java, които работят само с интерфейси, по-специално java.lang.reflect.Proxy.

Затова дефинирахме интерфейса на Matcher, така че хората да могат да пишат динамични реализации на Matcher. И ние предоставихме базовия клас, за да могат хората да го разширят в техния собствен код, така че техният код да не се повреди, докато добавяме още методи към интерфейса.

Оттогава добавихме метода describeMismatch към интерфейса на Matcher и клиентският код наследи изпълнение по подразбиране, без да се счупи. Ние също предоставихме допълнителни базови класове, които улесняват прилагането на describeMismatch без дублиране на логика.

И така, това е пример защо не можете да следвате сляпо някои общи „най-добри практики“, когато става въпрос за дизайн. Трябва да разбирате инструментите, които използвате, и да правите инженерни компромиси в този контекст.

РЕДАКТИРАНЕ: отделянето на интерфейса от базовия клас също помага за справяне с проблема с крехкия базов клас:

Ако добавите методи към интерфейс, който е имплементиран от абстрактен базов клас, може да се окажете с дублирана логика или в базовия клас, или в подкласове, когато те бъдат променени, за да имплементират новия метод. Не можете да промените базовия клас, за да премахнете тази дублирана логика, ако това промени API, предоставен на подкласове, защото това ще разбие всички подкласове - не е голям проблем, ако интерфейсът и реализациите са в една и съща кодова база, но лоша новина, ако сте автор на библиотека.

Ако интерфейсът е отделен от абстрактния базов клас -- тоест, ако правите разлика между потребители на типа и изпълнители на типа -- когато добавяте методи към интерфейса, можете да добавите имплементация по подразбиране към базовия клас, която няма прекъсване на съществуващите подкласове и въвеждане на нов базов клас, който осигурява по-добра частична реализация за нови подкласове. Когато някой дойде да промени съществуващите подкласове, за да имплементира метода по по-добър начин, тогава може да избере да използва новия базов клас, за да намали дублираната логика, ако има смисъл да го направи.

Ако интерфейсът и базовият клас са от един и същи тип (както някои предложиха в тази тема) и след това искате да въведете множество базови класове по този начин, вие сте заседнали. Не можете да въведете нов супертип, който да действа като интерфейс, защото това ще наруши клиентския код. Не можете да преместите частичната реализация надолу по йерархията на типове в нов абстрактен базов клас, защото това ще наруши съществуващите подкласове.

Това се отнася толкова много за признаци, колкото интерфейси и класове в стил Java или C++ множествено наследяване.

Java8 вече позволява нови методи да бъдат добавяни към интерфейс, ако съдържат реализации по подразбиране.

interface Match<T>

    default void newMethod(){ impl... }

това е страхотен инструмент, който ни дава много свобода в дизайна и еволюцията на интерфейса.

Но какво ще стане, ако наистина искате да добавите абстрактен метод, който няма изпълнение по подразбиране?

Мисля, че трябва просто да продължите и да добавите метода. Ще разбие някои съществуващи кодове; и ще трябва да се оправят. Всъщност не е голяма работа. Вероятно бие други решения, които запазват двоичната съвместимост с цената на прецакване на целия дизайн.

Но ако намерението е всеки клас, който имплементира Matcher, да разшири и BaseMatcher, защо изобщо да използвате интерфейс? Защо просто не направите Matcher абстрактен клас на първо място и всички други съпоставители да го разширят?

Чрез разделянето на интерфейса и имплементацията (абстрактният клас все още е имплементация) вие спазвате Принцип на инверсия на зависимостта. Не бъркайте с инжектиране на зависимост, нищо общо. Може да забележите, че в Hamcrest интерфейсът се съхранява в пакет hamcrest-api, докато абстрактният клас е в hamcrest-core. Това осигурява слабо свързване, тъй като изпълнението зависи само от интерфейсите, но не и от друго изпълнение. Една добра книга по тази тема е: Интерфейсно ориентиран дизайн: с шаблони.

Има ли някакво предимство да го правиш по начина, по който го направи Hamcrest? Или това е чудесен пример за лоша практика?

Решението в този пример изглежда грозно. Мисля, че коментарът е достатъчен. Създаването на такива методи за мъничета е излишно. Не бих следвал този подход.