我正在考虑使用工厂模式在我的一个小型 GUI 工具包中实现样式和渲染，然后这个疯狂的想法让我震惊。为什么不对所有小部件使用工厂模式？
现在我正在思考以下风格的事情:
Widget label = Widget::create("label", "Hello, World");
Widget byebtn = Widget::create("button", "Good Bye!");
byebtn.onEvent("click", &goodByeHandler);
新的小部件类型将使用类似 Widget::register(std::string ref, factfunc(*fact)) 的函数进行注册
您认为这种方法的优点和缺点是什么？
我敢打赌，使用 std::map<std::string> 几乎不会出现性能问题。因为它仅在设置时使用。
是的，请原谅我被 JavaScript 和 C++ 中任何可能的语法错误所损坏，因为我已经有一段时间没有使用该语言了。
优缺点总结
优点
- 从文件动态加载新的小部件会很容易
- 小部件可以在运行时轻松替换(它还可以帮助进行单元测试)
- 吸引充满活力的人
缺点(以及可能的解决方案)
- 没有编译时检查(可以编写自己的构建时检查。JS/Python/命名它，也没有编译时检查；我相信开发人员没有它也能做得很好)
- 可能性能较差(不需要一直创建小部件。字符串映射不会一直使用，而是在创建小部件和注册事件处理程序时使用)
- 向上/向下转换 hell (在需要时提供常用的类实例化)
- 可能会增加配置小部件的难度(使小部件具有相同的选项)
我的 GUI 工具包还处于早期阶段，它在规划方面还缺乏很多。由于我不习惯制作 GUI 框架，所以可能有很多我还没有想到的问题/设计决定。
现在我看不出小部件的方法集会有太大不同，但这可能只是因为我还没有考虑过更高级的小部件。
感谢大家的意见!
最佳答案
优点
- 从文件或其他外部源读取小部件并通过其名称创建它们会很容易。
缺点
- 很容易将不正确的类型名称传递到 Widget::create 中，并且仅在运行时才会出现错误。
- 如果不进行向下转型，您将无法访问小部件特定的 API - 即又一个运行时错误来源。
- 找到创建特定类型小部件的所有位置可能并不那么容易。
为什么不通过允许使用常规构造函数和工厂创建小部件来获得两全其美的效果呢？
关于c++ - 使用工厂模式来实例化所有小部件是否明智？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/6773338/