3 ms·
> You've probably seen the Factory<Factory<NaturalNumbersFacade>> joke somewhere, real live enterprise software is sometime like this, but unironically. I'm so
by ratww 7y ago
> You've probably seen the Factory<Factory<NaturalNumbersFacade>> joke somewhere, real live enterprise software is sometime like this, but unironically.
I'm sorry, this is a terrible argument. That's definitely not a common usage of Generics.
The common enterprise OOP idiom that is mocked is NaturalNumbersFacadeFactoryFactory, which use no Generics at all, leading to a large number of classes.
Ironically, if one used generics to replace factories like you did in your example, you would be able to replace hundreds or thousands of Factory or FactoryFactory classes in an enterprise application with a single Factory<T> class. Of course, that would probably be pointless. There's a reason multiple factories exist in a program, even though there are ways to replace them with something simpler.
I get it that Go programmers don't want the language to be complex, but Generics themselves don't have to be complex. They solve a lot of problems in a simple way and are MUCH easier to use than ad-hoc generics made using interface{} + Reflection.
- naikrovek 7y ago> I'm sorry, this is a terrible argument. That's definitely not a common usage of Generics. It is very common indeed in the three large Enterprise Java houses I've worked in over the past 15 years. FizzBuzzEnterpriseEdition is the reality in all three of those places. Not only is it reality, it is requirement.
- ratww 7y agoFizzBuzzEnterpriseEdition doesn't use generic classes. You're just making my point for me.
- sytringy05 7y agoIt definitely is common with generics, it happens all the time. Here's some production code I've worked on recently: new TypeReference<FooResponseCollectionResource<MemberUpdate>>(){}) I like generics, but I don't love this sort of thing and it's not even a mis-use of them
- je42 7y agowhat's the alternative ? using an "untyped" variable ? but then you loose type checking and some people don't like to loose type checking...
- KptMarchewa 7y agoDo not use patterns that require you to write code like that.
- KirinDave 7y agoOr use type aliases that are helpful.
- ratww 7y agoThat's the answer for me. The problem in those cases always the abuse of often obsolete OOP patterns and misnamed classes.
- Thiez 7y agoYou never have cases where you have a list of lists? Or do you introduce a pointless wrapper type for the inner lists to "hide" the generics?
- pjmlp 7y agoMany languages do support type alias. In C# you would do using NiceType = TypeReference<FooResponseCollectionResource<MemberUpdate>> // .... new NiceType ()
- ratww 7y agoMy point was that the commonly mocked VisitorObserverFacadeFactoryFactory Java idiom doesn't normally use generics at all. Of course you can mix generics with terribly named classes and OOP patterns, but that's hardly a problem with generics themselves.