On Tue, Apr 1, 2025 at 1:24 PM Eugene Sidelnyk <zsidel...@gmail.com> wrote:

> The wording “spicy”, “heretical”, “literally unusable”, “vibe”, the use
>> of ChatGPT, and the current calendar date requires me to ask:
>>
>
> Actually, if we put aside all of this, and think about it more seriously,
> personally I myself find it somewhat tedious to have every class have
> interface for the sake of being able to decorate it.
>
> Everything we expose as api for the client code normally should have an
> interface, and usually it ends up with superficial name: either suffixed
> with Interface (I know it is in PHP), or prefixed with I (C#), or just a
> normal name, while the actual class is suffixed with Impl (Java), or any
> other naming that only shows the problem of superficial separation.
>
> In my opinion, it could be a good thing to consider if we could do it more
> easily.
>
> It reminds me of C++, where every class has .h file with headers without
> actual implementation (IOW, interface, client code uses it), and the actual
> implementation in .cpp file. Though the two are still physically separated,
> they still logically make the same unit.
>
> Having the ability to implement the class, we'd not need to suffix
> interfaces with Interface all around where there's only one implementation
> of it. On the other hand, it still makes sense to keep normal full fledged
> interfaces, since these are usable when there are multiple different
> implementations (say, we have BankTransactionsGateway as the interface, and
> PrivatBankTransactionsGateway, MonoBankTransactionsGateway as
> implementations), since in this case interface is a normal expected
> abstraction, that should be kept separate.
>
> Thank you
>

Reading the original post I actually thought about being able to implement
the interface of a final class that doesn't have an interface by default.
This would include all public and protected methods and properties. Would
make it really easy to decorate/mock/stub objects.

Not sure if this would be considered a good practice, but certainly would
help with composition where otherwise nothing is possible. Would also make
it possible for a single object to implement the interface of multiple
different objects and fulfill all the contracts, which probably opens up a
whole new can of worms, but I could see myself using it to support legacy
code.

Reply via email to