Btw, using an iterator along with the visitor is a very common thing.

From what I see, you'll have to depend on some of the concrete classes from the original tree anyway, unless it exposed methods to distinguish between leaf/component classes. So, the question seems to be where that dependency is least awkward to have. If you're building a universal mapper, certainly you should provide some means to inject that dependency to the mapper. But if it's a mapper built for a specific thing, which unlikely to be changed in the near future, I'd always go the easy route and hardcode the required tree classes in it. You can always refactor your way out of it if needed.

Fixed, thanks!

嗨！

对不起，我的中文不好。 我对Go一无所知，但是我听说它在OOP方面的方法与Java之类的方法截然不同。 GoF模式在Go上下文中是否有意义？

---

Hi!

Sorry for my bad Chinese. I don't know anything about Go, but I heard that it has a very different approach to OOP than languages like Java. Are the GoF patterns even make sense in Go context?

固定！ 非常感谢您报告问题！

固定！ 非常感谢您报告问题！

Hi Anne!

Thanks for asking! When people ask me questions regarding their own projects & code, the first counter-question I ask is: what do you think is the answer? Sometimes people don't realize they have perfectly good answers for their own questions.

I mean why do you NEED to use a pattern at all? Implement the code without a pattern and then see whether applying a pattern would improve your code. This is the approach I usually take in real-life coding.

В Laravel работа с базой так и сделана, вот тут можно глянуть: https://laravel.com/docs/7.x/queries#selects

Если хотите, можете копнуть в исходники, там всё более-менее понятно. Из того, что я вижу в вашем коде, главное отличие в том, что в ларавеле тип запроса определяется сразу же, а оттуда вы уже достраиваете запрос методами как хотите.