restrykcyjne kodowanie "interface based" i uzywanie klas repository/dao

siemanko
droczę się z tym już jakiś czas i z myślą, że w końcu dojdę do swoistego wniosku tematu robić nie chciałem, no ale nie mogę się powstrzymać :)

chciałem zapytać co sądzicie o takim restrykcyjnym trzymaniu się zasady, że "kodujemy według interfejsów" tj że np mamy interfejs:

public interface ChickenService{
    public boolean getChicken();
}

I teraz tworzymy klasy:

public class HugeChickenService implements ChickenService{
    public boolean getChicken(){
        //stuff
    }
}

public class TinyChickenService implements ChickenService{
    public boolean getChicken(){
        //stuff
    }
}

No i w naszej klasie, która używa serwisu mamy @Inject albo @Autowired na polu: private ChickenService chickenService i sobie tam ustalamy @Qualifier czy jakoś inaczej, która implementacja ma być używana, z resztą sami wiecie

Pytanie moje jest następujące: chce zrobić np. klase @Service która mi sprawdza coś drobnego, czego na 99% więcej niż 1 implementacji nie będzie. Tworzyć w tym wypadku osobno interfejs i klase go implementującą, jako jego implementacje, czy sobie darować i po prostu zrobić klase nie implemetującą nic i ją wstrzyknąć?
Dodając interfejs jest bardziej "stajlowo" no i kod jak to mówią "podatniejszy na rozbudowe", ale czy jest w takim wypadku sens ciapać jeszcze interfejs bez sensu?

Drugie pytanie apropos klas Repository/Dao: jeśli np. potrzebuje w jakimś filtrze/gdziekolwiek jakąś metode z dao/repository, to robić taką delegacje: mojaKlasa -> service -> dao/repository czy bezpośrednio: mojaKlasa -> dao/repository?
Gdzieś przeczytałem że takie zasady panują i nie wiem czy się kurczowo trzymać tego, że tylko klasy @Service mają dostęp do dao/repository. Bo jesli np w tym (przykładowo) filtrze potrzebuję metodę żywcem z repository to po co robić identyczną metode w service i potem ją wywoływać - czy to nie wprowadza trochę zbędnego kodu?

pozdr i dzięki za przeczytanie ;)

1. Jest różnica. Na przykład jeśli chcesz mieć serwis z @Transactional to nie możesz wstrzykiwać przez konkretna klasę a tylko przez interfejs. Analogicznie ma sie sprawa ze wszystkimi innymi "proxy" i rozwiązaniami AOP. Poza tym jest to o tyle wygodne że pozwala na bardzo łatwe oddzielenie implementacji od interfejsów co pozwala uniknąć problemu krzyżowych zależności pomiędzy modułami aplikacji.
2. Zwykle transakcje wyciąga sie możliwie wysoko żeby nie zabijać bazy danych. Transakcje na poziomie DAO to taki-sobie pomysł. W efekcie ta warstwa pośrednia jest potrzebna tak czy siak.

1. Interfejs nie jest potrzebny. A proxy z klasy spring cglibem też robi
2. U nas repozytoria domyślnie działają w skopie transakcyjnym typu supported. Czyli jak jest transakcja np z serwisu to się dokleja, a jak nie ma bo np wołasz z filtra to nie ma transakcji i wtedy możesz robić tylko odczyty...bo do odczytów tx nie musi być. Inna kwestią jest jakie obiekty wymienia Repo a Filtry czy są to encji czy jakie projekcje