c#关闭一个窗体打开另一个
我想你们中的许多读者都熟悉Open / Closed原理 。 它指出:
软件实体(类,模块,功能等)应打开以进行扩展,但应关闭以进行修改
面向对象的软件构造(1988)
此其他“打开/关闭”原理是完全无关的,但同样重要。 它指出:
当用某人的代码打开“某物”时,也必须将其关闭!
我的浴室(2014)
很简单? 那么,为什么我为什么经常偶然发现数据库连接未关闭( 即释放到池中),套接字,输入流未关闭,输出流未关闭等? (但是,老实说,我有时有时忘记了以后也感到内))。 如果在使用完资源后才释放资源,则可能会导致内存泄漏。 其他可能的后果也与资源的性质有关:例如,当不释放数据库连接时,迟早池将耗尽,因此无法获取与数据库的新连接-基本上,您的应用程序将无法使用,需要重新启动应用程序服务器。
尽管如此,没有什么可以阻止我们关闭资源,只有一些小事情要解决:
- 如上所示,关闭资源不是一种选择,必须确保。 Java使通过
finally
块成为可能(因此也需要相关的try
块)。 - 大多数
close()
(或release()
或destroy()
或您拥有的方法)签名都会引发一个已检查的异常。 如果您真的想要我的意见,这是一个设计错误,但是我们开发人员必须加以解决(老实说,这不是有人第一次决定必须由我来处理后果,这就是Management 1.0) )。
这是一个非常简单的示例:
Filefile=newFile("/path/to/file");
FileInputStreamfis=newFileInputStream(file);
try{
// Do something with file
}finally{
fis.close();
}
注意,第6行使用了一种方法,其签名会引发一个已检查的异常,并且必须进行相应处理。 与大多数情况一样,在关闭时几乎无法恢复(根本无法读取)时抛出异常,而不是进一步抛出异常不仅仅是一个有效的选择。 无需使代码更加混乱,只需使用Apache Commons IO的IOUtils.closeQuietly()
(或其数据库对应的Apache Commons DB的DBUtils.closeQuitely()
)。
上面的finally
块可以替换为:
finally{
LOGGER.log("Couldn't close input stream on file "+file.getAbsolutePath());
IOUtils.closeQuietly(fis);
}
(是的,在所有情况下,记录无法释放资源都是一个好习惯)
最终(没有双关语),人们可能还记得Java 7带来了AutoCloseable
接口以及try-with-resources语法。 如果方法签名没有引发异常,则使close()处理变得更加简单:
try(StringReaderreader=newStringReader(string)){
// Do something with reader
}
即使不执行任何操作,StringWriter.close()签名也会引发异常
总之,请记住,持续集成平台是您的朋友,而Sonar(或Checkstyle,PMD和FinddBugs)等工具是检查未发布资源的好方法。
翻译自: https://blog.frankel.ch/another-valid-openclosed-principle/
c#关闭一个窗体打开另一个