Are questions regarding design patterns welcome? I...

# announcements

[tschuchort]

Are questions regarding design patterns welcome?
I have a tree of objects that I need to convert to a similar tree of other objects and the creation logic is quite complex. The object types are also in a hierarchy where only the leafs are non-abstract and can be instantiated. So right now I have a static factory method in each class that checks the necessary conditions and then returns the object or null (in the case of leaf types) or delegates the object creation to the right factory method of it's sub types (in the case of a non-leaf type). But I was thinking that it might be better to put all of that creation logic in a factory class. In particular, I think it will improve error handling since the nested nullable factory methods tend to swallow error reasons which makes debugging much harder. And since everything is in one place, there is less repetition of the necessary conditions for creating some object.
But a big concern is that putting all the checks in the factory class would make it possible to create some class in an invalid state. I could of course also put the same checks into each constructor, but that repetition would make the whole thing pointless.

What do you think? What are the pros/cons of one factory class vs nested factory methods vs checks in constructors that throw, and trying them all in order?

[Ruckus]

Generally, questions about general programming patterns are better suited for StackOverflow for a couple of reasons. First, the structure of SO is better suited for such quandaries (and is searchable, which is a huge bonus). Second (and possibly more imporatntly), we like to keep thinks Kotlin specific on this slack.

[karelpeeters]

Although good look keeping the question "how do I design this" open on stackoverflow.

[leolima]

there is also https://softwareengineering.stackexchange.com/