创建许多新实例还是重用它们？
我在 VB.NET Windows 窗体应用程序中有多个业务实体。现在，它们在应用程序启动时实例化并在需要时使用。它们保存业务实体以及存储和检索数据的方法的描述。长话短说，它们是一些需要构建的重对象（它们有一些内部字典和对其他对象的引用），创建并保存在一个名为“BLogic”的大全局变量中。
我应该重构它，以便每个对象在需要时创建并在超出范围时释放吗？那么 UI 上的每个事件都可能会创建一些这样的对象。
我应该努力最小化新对象的创建还是最小化静态和全局对象的数量？一般来说，我试图最小化每个变量的范围，但是我应该特别对待这个业务逻辑对象吗？
I have multiple business entities in VB.NET Windows Forms application. Right now they are instanced on application startup and used when needed. They hold descriptions of business entities and methods for storing and retrieving data. To cut the long story short, they are somewhat heavy objects to construct (they have some internal dictionaries and references to other objects) created and held in one big global variable called "BLogic".
Should I refactor this so that each object is created when needed and released when out of scope? Then every event on UI will probably create a few of this objects.
Should I strive to minimize creation of new objects or to minimize number of static and global objects? Generally I am trying to minimize the scope of every variable but should I treat this business logic objects specially?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
让我们看看您提供的两个选项：
单一全局实例
优点：
缺点：
每个函数实例都是唯一的
优点：
缺点：
这并不是一个详尽的列表，但它确实指出了我所看到的主要权衡。显然，您更了解情况以及哪些权衡是可以接受的。一些明智选择的全局变量可能很有用，但像大多数人一样，我会倾向于避免使用大量全局变量，除非它们代表只能存在其中之一的东西，例如串行端口，或者整个应用程序应该只具有其中之一，就像一个 ApplicationSettings 类。
不要低估您的时间（无论是现在还是稍后您回来进行维护时）作为成本。有时“更好”的解决方案实际上可能更糟糕，因为实施时间太长。通常，“足够好”最终证明是，嗯，足够好。
Let's look at the two options you've presented:
Single Global Instances
Pros:
Cons:
Unique per function instances
Pros:
Cons:
This is not meant to be an exhaustive list, but it does point out the main tradeoffs as I can see them. Obviously, you know more about the situation and which tradeoffs are acceptable. A few judiciously chosen globals can be useful, but like most people I would lean away from having a lot of globals unless they represent something that there can only be one of, like a SerialPort, or something that the entire application should only have one of, like an ApplicationSettings class.
Don't undervalue your time (both now and later when you come back for maintenance) as a cost. Sometimes a "better" solution may actually be worse because it takes too long to implement. Often "good enough" turns out to be, well, good enough.
是的，您应该重构为仅在需要时分配对象，并在不再需要时将其丢弃。这始终是一个不错的设计选择，除非无法满足特定且可测量的性能要求。
将分配推迟到绝对需要的时候的优点是，在许多（大多数？）情况下，对象根本不会被分配。拖延是要付出代价的！ ;>您的应用程序运行得更精简，整个系统应该负担更少、更敏捷。没有人喜欢使用内存消耗者。
按需分配的缺点是它可能会导致用户反馈/响应延迟，这会令人恼火。如果您有一个对象需要花费相当多的时间来构造或初始化（例如，通过网络加载数据），那么如果用户期望，那么该对象可能不太适合在按钮单击时分配就是点击按钮后立即看到结果。如果您可以立即调出用户界面来响应按钮单击，但新表单上的控件会尽快从网络数据中填充自己（并表明它们正在加载某些内容），那么这就不是什么问题了。 “相当长的时间”的一般 UI 指标通常是点击和 UI 响应之间最多大约半秒。
Yes, you should refactor to allocate the objects only when needed, and dispose of them when they are no longer needed. This is always a good design choice unless trumped by specific and measurable performance requirements.
The advantage of deferring allocation until absolutely needed is that in many (most?) cases, the object will never be allocated at all. Procrastination pays! ;> Your app runs leaner and the system as a whole should be less taxed and snappier. Nobody enjoys using a memory hog.
The disadvantage of allocate on demand is that it may introduce delays in user feedback/responsiveness that will be irritating. If you have an object that takes a considerable amount of time to construct or initialize (say, loading data across the network), that would probably not be a great match for allocate on button click if the user expectation is to see results immediately after the button click. If you can bring up UI immediately in response to the button click but have controls on the new form fill themselves in from network data as soon as they can (and indicate that they are loading something), that would be less of an issue. The general UI metric for "considerable amount of time" is usually about half a second max between click and UI response.