Tag: 设计

为什么Java的语言设计者更倾向于对大多数基于散列的结构的开放寻址进行链接，除了像ThreadLocal这样的结构？: 我知道Open Addressing和Chaining之间在解决哈希冲突方面的区别。大多数基于哈希的基本哈希数据结构如Java中的HashSet ， HashMap主要使用链接技术。我读到ThreadLocal实际上使用了探测方案。所以我想理解为什么开放式寻址在Java中没有那么多用？我的意思是，使用该方案删除记录很困难，因为您必须使用一些特殊处理来标记这些单元格。然而，对于开放寻址方案，似乎存储器要求将是低的。编辑：我只是想了解这个设计决定的可能主要原因/原因。我不想要更精细的细节。此外，我想知道为什么ThreadLocal使用较少见的开放寻址技术。我想这两个答案可以联系在一起。所以我更喜欢在同一个问题中提问。

unit testingOSGi组件: 我目前正在考虑“如何设计一个OSGi组件，以便使用jUnit和Mockito等框架轻松编写测试” 。由于OSGi强化DIP （依赖性倒置原则）并且通常存在注入器方法（例如，设置器），因此模拟捆绑间依赖性非常容易。但是捆绑内部依赖呢？例如，看看这个案例。现在我想将它带入一个OSGi上下文…我们希望在OSGi平台中提供任何类型的网络协议作为声明服务，并希望编写unit testing来测试直接与之交互的较低网络代码套接字对象。如果我们将套接字创建重构为一个单独但仍然捆绑的内部POJO （Plain Old Java Object）类，我们应该如何将它注入协议实现？在unit testing中，我们可以简单地使用setter方法但是谁会在我们的OSGi容器中执行此操作？对测试类进行子类化并覆盖创建者方法只有在测试类未声明为final时才有效。

在exception被捕获错设计后返回null: 我总是遇到同样的问题，当在具有非void返回值的函数中捕获exception时，我不知道要返回什么。以下代码段说明了我的问题。 public Object getObject(){ try{ … return object; } catch(Exception e){ //I have to return something here but what?? return null; // is this a bad design?? } } 所以我的问题是：返回null设计不好吗？如果是这样，什么被视为更清洁的解决方案？谢谢。

但是，不应该过度使用创建静态实用程序方法？怎么避免呢？: 随着时间的推移……在java项目中引入了大量的实用方法，以实现更复杂，更简单的任务。当使用静态方法时，我们在代码中引入紧耦合，这使得我们的代码更难以测试，特别是如果实用方法非常复杂。我只是觉得现在很难管理和测试这些实用程序。请指导我避免使用这些实用程序方法，以及如何组织现有项目以删除所有STATIC实用程序。你能帮我避免静态方法吗？

发送telnet命令并使用Java读取响应: 我在一个支持全国网络上许多不同站点的大型组织工作。我们的供应商为我们在每个站点使用的硬件提供诊断工具。可通过Telnet访问诊断和报告。问题是我们想要同时监控所有站点，目前我们只能一次检查一个站点（通过telnet）。我已经构建了一些将使用Runtime.exec(String)向每个IP地址发送ping命令的东西。但现在我希望能够使用供应商的诊断和报告工具自动发送特定命令。有关最佳方法的任何想法吗？注意我们有一个混合系统 – 一些站点在防火墙后面，有些则没有。一个完整的解决方案将是理想的，但我也将满足于部分解决方案。它可以像获取Runtime.exec(String)返回的Process对象的输入和输出流一样简单，并将我的命令发送到输入并读取输出上的响应吗？或者我应该连接到端口23（通常的telnet端口），然后表现为任何其他客户端 – 服务器系统。还是别的什么完全不同？我正在继续尝试，只是在这一点集思广益…… 代码:(删除敏感信息） void exec(String ip) { Socket sock = null; BufferedReader br = null; PrintWriter pw = null; try { sock = new Socket(ip, 23); br = new BufferedReader(new InputStreamReader(sock.getInputStream())); pw = new PrintWriter(sock.getOutputStream()); this.read(br); System.out.println(“Sending username”); pw.println(“username”); this.read(br); […]

Java抽象类或静态实用类设计选择: 我正在实施一些具有一些共同行为的战略（战略模式），并且尚未确定共同运营应该存在的地方。假设我有1个上下文和3个策略，策略中使用的一些操作是共享的，有些仅需要2个其他操作，只需要1个策略。没有成员级别的状态共享，因此唯一的操作实际上是无状态的。操作的目的是支持将状态格式化为文件，例如视图助手。选项1：创建一个AbstractStrategy类我正在使用Java，因此将来会立即使用此function。 inheritance倾向于导致。在一个山脊结构。操作将是最终的。选项2：创建一个Util类的静态助手灵活，但由于某种原因感觉像代码味道。没有山脊。任何建议或偏好？请注意，我正在处理的级别是策略级别，而不是上下文级别（请参阅维基百科链接）。

保留选项值的位置，重要文件的路径等: 我正在创建一个程序，需要设置一些选项值以及图像文件的一些路径，SQLite数据库的路径，各种按钮上的文本的一些信息，有关使用哪个数据库的信息（例如SQLite / MySQL）等到目前为止，我有一个帮助类，我把所有东西都设置为静态，我从程序中的任何地方访问它，但它变得一团糟，我读到这是一种不好的做法，因为它不遵循面向对象的编程准则。所以我所做的是使该类成为一个单例，并在我的控制器对象中引用它。要访问我的选项，我现在调用controller.getOptionName而不是直接调用Helper.getOptionName。我有一种感觉，我正在以错误的方式接近这一点，特别是因为从我所读过的内容来看，如果我的许多对象依赖于单个类（助手类），我就不能将这一切分开。我不知道我应该做什么，是否有一个“标准”在哪里保留我的所有选择？我考虑过使用XML文件或类似的东西，但我最终还是要从任何地方访问它，所以感觉这会产生同样的问题。

内/匿名课程的最佳实践: 匿名类和静态内部类的最佳实践（设计和性能）是什么？我个人认为静态内部类提供了更好的封装，并且应该提供更好的性能，因为他们无法访问类外的最终变量。但我从来没有真正质疑这一点。我发现了一篇关于此的post，但我觉得它实际上并没有回答这个问题，只是人们对此的个人想法。

用于HTTP错误的Javaexception类是什么？: 我正在使用Apache HttpClient，并希望通过Javaexception机制将HTTP错误（400 Bad Request，404 Not Found，500 Server Error等）传达给调用代码。 Java标准库或广泛使用的库中是否存在适合使用或子类用于此目的的exception？另一种方法是检查状态返回码。这似乎是HttpClient设计理念，但由于这些错误在我的应用程序中确实非常特殊，我希望在它们发生时为我设置堆栈跟踪和其他好的exception事项。

Java服务器的单个或多个线程池？: 我正在编写一个相当复杂的Java服务器应用程序，除了通常的请求 – 响应处理之外，它还具有重要的后台处理部分。一些后台处理是使用Quartz框架以类似cron的方式完成的。其他任务更受欢迎 – 如果新客户端连接它会创建额外的工作，偶尔更新它。 cron任务也可以变化 – 有些可以监控外部应用程序，有些可以计算统计数据等等。我正在使用许multithreading池来运行所有这些作业，并认为类似的作业将共享一个线程池，但不同的作业将不会共享一个。例如，监视器作业永远不会在统计信息池上运行，统计信息作业永远不会在监视器池上运行。另一方面，我知道有些人宁愿只拥有一个线程池并在其上运行所有内容而不会有任何分离。我想知道在这种情况下什么是最佳实践。分离线程池的优点是什么？它甚至重要吗？