4 ms·

I've never done heavy development in Java, but my day-to-day has been C# for years. I've never seen a FactoryFactoryFactory, or even a FactoryFactory. Since the

I've never done heavy development in Java, but my day-to-day has been C# for years. I've never seen a FactoryFactoryFactory, or even a FactoryFactory. Since the two languages are so similar, I would think C# would have the same issues as Java in this regard, but in my experience it doesn't. Is there something about C# that has let it avoid this? Or have I just happened to work at places that don't like the Factory pattern as much as everyone else seems to? :D

frik 9y ago
> Is there something about C# that has let it avoid this? 1) You can write more hacky code in C# than in Java. In Java, everything has to a class and you have to write OO. In C# you can mix in hacky practice you may practiced before in Visual Basic. You can do increadable hacky things with threads in C# that just work (tm), while in Java you are hindered by it's monitor or later adoption of green thread implementation, maybe a good thing(tm). 2) OO patterns. The Design Patterns book written by the Gand of Four comes with Java examples. "Factory" and other patterns got introduced with this book to many new devs. If you came to programming from Visual Basic or have no university degree you probably never heard about programming patterns at all. And just code whatever comes to your mind.
Radle 9y ago
It's a cultural issue. Patterns are things you can avoid to use, they simplify a prior existing problem. But if engineers don't ask themselves what the code would look like if they wrote it differently, a lot of stupid code will be the result. That can be Boilerplate or it can be Spaghetti. More communication within the team will help.
pionar 9y ago
You see this a lot in C# projects that are ports from a Java analogue, like log4net.
WorldMaker 9y ago
C# often has "release valves" that allow you to divert from some of the mess that Java tends to exhibit. `events` and `delegates` from C# 1/.NET 1, flawed as they may be in retrospect, alone simplify several major patterns that Java falls into. I also think on the paradigm issue here is Java architects seem more inclined to have a "ravioli code" problem. There's an ancient Java ideal of componentization [1] that a lot of Java code tries to live up to. Lots of little components boxed into tight containers that only ever interact through often "reconfigurable" sauce: ravioli. There are some benefits to that ideal, it exists because it has some merits in terms of component testing, in particular. It's just that as with spaghetti code and copypasta code, ravioli code also sometimes winds up in a mess where the ideal meets the real world, and somehow a toddler (or junior developer in this analogy?) has thrown it all over the kitchen and you have no idea how to clean it up without destroying the entire kitchen and starting over... May not be a great analogy. ;) I'd argue that you are more likely to see Java-style ravioli code in C# projects that use IoC containers of one sort or another. Again, there's nothing particularly wrong with IoC containers [2] as an idea connected to some ideals of component testing, it's just that it's an ideal that often falls down and fails to deliver its advantages in the real world. [1] That somewhat resembles the Smalltalk ideal of object message passing while the language itself lacks much of the architecture for that. Arguably, a lot of Java's worst problems come from trying to replicate a lot of Smalltalk ideas and design patterns in a language that is nothing at all like Smalltalk and misses some important characteristics of Smalltalk. [2] IoC Containers are a ravioli concept directly imported to C# from the Java world, with the earliest IoC containers such as Spring.NET being Java ports.

frik 9y ago

> Is there something about C# that has let it avoid this? 1) You can write more hacky code in C# than in Java. In Java, everything has to a class and you have to write OO. In C# you can mix in hacky practice you may practiced before in Visual Basic. You can do increadable hacky things with threads in C# that just work (tm), while in Java you are hindered by it's monitor or later adoption of green thread implementation, maybe a good thing(tm). 2) OO patterns. The Design Patterns book written by the Gand of Four comes with Java examples. "Factory" and other patterns got introduced with this book to many new devs. If you came to programming from Visual Basic or have no university degree you probably never heard about programming patterns at all. And just code whatever comes to your mind.

Radle 9y ago

It's a cultural issue. Patterns are things you can avoid to use, they simplify a prior existing problem. But if engineers don't ask themselves what the code would look like if they wrote it differently, a lot of stupid code will be the result. That can be Boilerplate or it can be Spaghetti. More communication within the team will help.

pionar 9y ago

You see this a lot in C# projects that are ports from a Java analogue, like log4net.

WorldMaker 9y ago

C# often has "release valves" that allow you to divert from some of the mess that Java tends to exhibit. `events` and `delegates` from C# 1/.NET 1, flawed as they may be in retrospect, alone simplify several major patterns that Java falls into. I also think on the paradigm issue here is Java architects seem more inclined to have a "ravioli code" problem. There's an ancient Java ideal of componentization [1] that a lot of Java code tries to live up to. Lots of little components boxed into tight containers that only ever interact through often "reconfigurable" sauce: ravioli. There are some benefits to that ideal, it exists because it has some merits in terms of component testing, in particular. It's just that as with spaghetti code and copypasta code, ravioli code also sometimes winds up in a mess where the ideal meets the real world, and somehow a toddler (or junior developer in this analogy?) has thrown it all over the kitchen and you have no idea how to clean it up without destroying the entire kitchen and starting over... May not be a great analogy. ;) I'd argue that you are more likely to see Java-style ravioli code in C# projects that use IoC containers of one sort or another. Again, there's nothing particularly wrong with IoC containers [2] as an idea connected to some ideals of component testing, it's just that it's an ideal that often falls down and fails to deliver its advantages in the real world. [1] That somewhat resembles the Smalltalk ideal of object message passing while the language itself lacks much of the architecture for that. Arguably, a lot of Java's worst problems come from trying to replicate a lot of Smalltalk ideas and design patterns in a language that is nothing at all like Smalltalk and misses some important characteristics of Smalltalk. [2] IoC Containers are a ravioli concept directly imported to C# from the Java world, with the earliest IoC containers such as Spring.NET being Java ports.