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.