Questions tagged «design-patterns»

设计模式是解决软件设计中常见问题的通用可重用解决方案。



6
对象池是否已被弃用?
我对对象池的概念非常熟悉,并且我总是尝试尽可能多地使用它。 另外,我一直认为对象池是标准规范,因为我已经观察到Java本身以及其他框架尽可能多地使用池。 最近,尽管我读了一些对我来说是全新的东西(并且违反直觉?)。 该池实际上使程序性能变差,尤其是在并发应用程序中,并且建议实例化new对象,因为在较新的JVM中,对象的实例化确实非常快。 我在书中读过: Java Concurrency in Practice 现在,我开始考虑我是否对这里的事情有所误解,因为本书的第一部分建议使用Executors重用Thread而不是创建新实例。 那么,如今对象池是否已被弃用?


2
嵌套指令之间的通信
指令之间似乎有很多通信方式。假设您有嵌套指令,内部指令必须将某些内容传递给外部指令(例如,它是由用户选择的)。 <outer> <inner></inner> <inner></inner> </outer> 到目前为止,我有5种方法 require: 家长指令 该inner指令可以要求该outer指令,该指令可以在其控制器上公开某些方法。所以在inner定义中 require: '^outer', link: function(scope, iElement, iAttrs, outerController) { // This can be passed to ng-click in the template $scope.chosen = function() { outerController.chosen(something); } } 在outer指令的控制器中: controller: function($scope) { this.chosen = function(something) { } } $emit 事件 该inner指令可以$emit一个事件,该outer指令可以通过响应,$on。因此,在inner指令的控制器中: controller: function($scope) { …

12
这是C语言中goto的一个不错的用例吗?
我真的很犹豫要问这个问题,因为我不想“征求辩论,争论,民意测验或扩展讨论”,但是我是C语言的新手,并且希望对语言使用的常见模式有更多了解。 我最近听到对该goto命令有些反感,但最近也发现了一个不错的用例。 像这样的代码: error = function_that_could_fail_1(); if (!error) { error = function_that_could_fail_2(); if (!error) { error = function_that_could_fail_3(); ...to the n-th tab level! } else { // deal with error, clean up, and return error code } } else { // deal with error, clean up, and return error code …


3
DRY,KISS,SOLID等被分类为什么?
DRY是设计模式,方法论还是介于两者之间?他们没有可以证明的具体实现(即使您可以轻松地演示一个案例,而无需使用诸如KISS之类的东西……请参见The Daily WTF以获得大量示例),它们也无法像方法论一样完整地解释开发过程通常会。这些“经验法则”在哪里留下来?

6
事件循环是否只是具有优化轮询的for / while循环?
我试图了解什么是事件循环。通常的解释是,在事件循环中,您会做一些事情,直到收到事件发生的通知。然后,您可以处理事件并继续做之前的工作。 用示例映射以上定义。我有一台在事件循环中“侦听”的服务器,当检测到套接字连接时,将读取并显示其中的数据,此后服务器将像以前一样继续/开始监听。 但是,此事件正在发生,而我们收到的通知“就像那样”对我来说就很大了。您可以说:“注册事件侦听器不只是那样而已”。但是什么是事件侦听器,但由于某种原因没有返回的函数。它是否在自己的循环中,等待事件发生时得到通知?事件监听器是否还应该注册一个事件监听器?它在哪里结束? 事件是可以使用的很好的抽象,但是仅仅是一个抽象。我认为,最后不可避免地要进行投票。也许我们没有在代码中执行此操作,但是较低级别(编程语言实现或OS)正在为我们执行此操作。 它基本上可以归结为以下伪代码,这些伪代码在足够低的位置运行,因此不会导致繁忙的等待: while(True): do stuff check if event has happened (poll) do other stuff 这是我对整个想法的理解,我想听听这是否正确。我乐于接受整个想法从根本上是错误的,在这种情况下,我希望有正确的解释。


8
术语(或“模式”?)是“如果还没有做的话就做”
听起来很基本,我知道,但是最近我有一位同事告诉我,这种方法startHttpServer太复杂了,难以理解,因为它只会在服务器尚未运行时启动服务器。当我回答“严重吗?我已经这样做数十年了-这是编程中的常见模式”时,我发现自己很麻烦。我经常不愿意承认他带回来的一些有据可查的证据表明,整个编程社区都在支持他的观点,而我最终感到很讨厌。 问题:如果所需的措施已经生效,则在无操作方法的概念背后是否存在文档化的设计模式?或者,如果不是模式,它是否也有名称?如果不是,是否有任何理由认为考虑以这种方式编写方法太复杂了?

8
MVC体系结构—我需要多少个控制器?
我已经编码了一段时间,但主要是脚本和简单的应用程序。我已经升任新职位,其职责是开发Web应用程序并使用适当的MVC架构,因此我拼命尝试快速了解所有内容。 我希望这个问题与“ MVC体系结构的最佳实践 ”不太相似,但是当我浏览一些不同的教程时,我注意到其中有些具有针对不同事物的多个控制器。 一个Web应用程序需要多少个控制器? 我意识到如果没有示例,这将很难回答,因此我将提供一个示例: 应用: 用户登录。 用户可以做以下三件事之一: a) 上传一个文件(与元数据一起存储在mongodb数据库中)。 b) 搜索文件。 c) 注销。 我的问题很笼统,但我举了一个例子来帮助任何想回答的人。

2
双向数据同步的最佳实践/模式
在我的工作中,经常会出现数据库系统之间的2路数据同步的想法。经典示例是两个稍微不同的CRM系统(例如,Raiser's Edge和Salesforce),并且需要在它们之间进行双向联系人数据同步。 撇开API的考虑,假设您有一个要同步的共享密钥,并且纯粹考虑要使用的算法/模式,这是非技术人员经常低估的一项任务。 例如,您必须当心: 您可以轻松地检测到两个系统中的哪些记录已更改(或者您必须比较两个系统之间的所有记录以检测更改) 如果要进行每N小时一次的同步,那么在两个系统中相同记录或多或少同时发生更改的情况下,如何处理冲突 如果您要进行实时同步(例如,一个系统中的更新会立即触发另一个系统的更新),如何处理由于错误或系统崩溃而导致的时间差异。 我个人可以考虑解决所有问题的方法,但是我想知道是否可以参考任何众所周知的模式,文献或最佳实践。

2
与MVC相比,MVP有哪些改进?
我已经阅读了三天的有关Model-View-Controller(MVC)和Model-View-Presenter(MVP)模式的信息。有一个问题令我非常困扰。当已经有MVC时,为什么软件设计者会发明MVP? 他们遇到了什么问题,MVC无法解决(或解决得很差),但是MVP可以解决?MVP打算解决哪些问题? 我已经阅读了很多有关MVP的历史和解释,或者关于MVC和MVP之间差异的文章,但是没有一个对我的问题有明确的答案。 在我读过的一篇文章中,有人说: 现在进入Model View Presenter,这是对MVC模式应用于现代基于组件的图形用户界面时的不足之处的回应。在现代GUI系统中,GUI组件本身而不是某些中央控制器来处理诸如鼠标移动和点击之类的用户输入。 因此,我听不懂,但实际上可以以另一种方式使用,例如GUI组件不能自行处理用户输入吗?“单独处理”到底是什么意思?

10
我们应该避免将自定义对象作为参数吗?
假设我有一个自定义对象Student: public class Student{ public int _id; public String name; public int age; public float score; } 还有一个窗口Window,用于显示学生的信息: public class Window{ public void showInfo(Student student); } 它看起来很正常,但是我发现Window很难单独测试,因为它需要一个真正的Student对象来调用该函数。因此,我尝试修改showInfo,使其不直接接受Student对象: public void showInfo(int _id, String name, int age, float score); 以便更轻松地单独测试Window: showInfo(123, "abc", 45, 6.7); 但是我发现修改后的版本还有另一个问题: 修改学生(例如:添加新属性)需要修改showInfo的方法签名 如果Student具有许多属性,则Student的方法签名将非常长。 因此,使用自定义对象作为参数或接受对象中的每个属性作为参数,哪个更可维护?

By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.