讲解常见的工厂模式_使用工厂模式的好处( 二 )

例子7: 避免在构造函数中抛出异常。"构造函数里不要抛出异常"这条原则很多人都知道。不在这里展开讨论。但问题是，业务要求必须在这里抛一个异常怎么办？就像上面的Foo要求从文件读出来数据并创建对象。但如果文件不存在或者磁盘有问题读不出来都会抛异常。因此用FooCreator.fromFile这个工厂来搞定异常这件事。
其实还有很多例子，就不继续扩展了。要点是，当你有任何复杂的的创建对象过程时，你都需要写一个某种createXXXX的函数帮你实现。再拓展一下范围，哪怕创建的不是对象，而是任何资源，也都得这么干。一句话：
不管你用什么语言，创建什么资源。当你开始为“创建”本身写代码的时候，就是在使用“工厂模式”了。
具体形式可以根据当时的场景去调整，不管你用的是静态函数，抽象类还是模版等，那都是细节。不同语言的支持也不太一样。比如Java这方面就略微土一些，函数不是一等公民限制了表达力。所以你会看到各种XXXXFactory，AbstractXXXXFactory的类。
kotlin提倡用静态工厂方法解决一部分问题，即给一个class的companion object做一个表示工厂的函数。在Effective Koltin第一条就是这个。
interface ImageReader {fun read(file: File): Bitmapcompanion object {// 提供静态工厂方法fun newImageReader(format: String) = when (format) {"jpg" -> JpegReader()"gif" -> GifReader()else -> throw IllegalStateException("Unknown format")}}}// 使用静态工厂方法val reader = ImageReader.newImageReader("jpg")Bitmap bitmap = reader.read(someFile)而对于go，一般用一个函数去创建一个初始化好的对象（或者叫struct？）。go的想法很简单：反正你总是要写一个函数，就写函数吧，不要搞出那么多幺蛾子概念。
type SomeStruct struct { // ...}func NewSomeStruct() *SomeStruct {s := SomeStruct{...}// 做一些初始化return &s}最后特别提醒下初学者，我很理解你们刚学到了一招马上就想试试的心情，但如果是上生产，请总是使用可以满足需求的最简单的方案。不要为了工厂模式而工厂模式。搞工厂这么一套（或者任何其他模式）都是有成本的。开闭原则是没错，但只应该在合适的时候使用。更麻烦的是假如你一开始搞错了，做出来的工厂的接口抽象后来发现是不符合需求变更，改起来还不如一开始没有做工厂，直接new 。越简单的代码越容易改，哪怕看起来会有些体力劳动，但不费神。当然，这也不是说尽量不要用模式。这完全取决于你对需求的理解。所以多花时间理解需求和业务，然后问自己“这里可能会变得很复杂吗？这里未来3个月多大可能需要扩展？“
同时也不要照着《设计模式》去写代码。你可以将《设计模式》理解为是一本字典。它的内容是没错，但一般只用来做参考。对于一个模式要不要用，怎么用，要看场景。正常写文章的人，除非是学生，没人会在写文章的时候抱着本字典去写，对吧。