关于javascript：在应用程序中只使用一种设计模式

Using just one design pattern in application

我正在努力学习如何让我的应用程序在所有文件中具有相同的"面孔"，相同的模式，但我不知道这是否是正确的做法。

我想知道在软件开发中是否更正确，是将应用程序限制为只有一种类型的模式。

例如，这就是我的应用程序的样子(只是一块)

Api.js：

1
2
3
4
5
6
7

'use strict'
var Server = require('./server');
var Api = {
init: function() {
Server.init('start');
}
};

Server.js：

1
2
3
4
5
6
7
8
9
10

'use strict'
var Server = {
init: function(command) {
this.command = command;

if (command === 'start') {
this.start();
}
}
};

我在我的所有应用程序中使用"初始化程序对象模式"。所以我正在避免装饰图案，立面，一切。

我应该避免或者我可以使用多个？如果正确的答案是使用几个，根据需要，我还有其他问题。这不会使维护更加困难吗？是不是让代码像意大利面？

谢谢。

更新。

我将再次尝试解释，这次是赏金。

我已经试着问，但似乎没有人真的可以给我一个简明的答案。

我想知道制作一个好的应用程序，一个好的网络应用程序，谈论代码外观的秘诀。我想知道我是否应该在我的洞应用中保持相同的标准代码，如果这是好的，或者真的无关紧要。

例如，我有两个EXAMPLES文件

app.js：

1
2
3
4
5
6
7
8
9

var server = require('./server');

var app = {
init: function() {
server.init('DEVELOPMENT');
}
};

module.exports = app;

server.js：

1
2
3
4
5
6
7
8
9
10
11

var server = {
init: function(env) {
if (env === 'DEVELOPMENT') {
// CODE
} else {
// CODE
}
}
}

module.exports = server;

在这种情况下，我使用方法init的一个对象，这是我在我的洞应用程序中使用的模式..

或者没关系，我应该写任何东西：

第一个对象：

1
2
3
4
5
6
7
8
9

var server = require('./server');

var app = {
init: function() {
server('DEVELOPMENT');
}
};

module.exports = app;

比服务器作为一个功能：

1
2
3
4
5
6
7
8
9

var server =function(env) {
if (env === 'DEVELOPMENT') {
// CODE
} else {
// CODE
}
}

module.exports = server;

我可以给出100分。令人难以置信的是我怎么能找不到这个特定问题的好答案。

谢谢。

相关讨论

我应该使用其他模式吗？

不，你不应该坚持一个单一的模式。

没有任何设计模式书籍会建议您使用单一模式。
就像你不能用一种方式砍掉所有的成分(你是不是要把意大利面骰子？)，你不能用一种模式组织所有的逻辑。

当然，您可以使所有对象使用初始化模式，并且根本不使用构造函数。
还行吧。去过也做过。我喜欢。

但是这些对象可以与Builder或Abstract Factory一起使用(如果它使事情更简单)。
只要构建器/工厂本身具有初始化器，并且它们正确地初始化所创建的对象，那么您对初始化器模式的使用将是一致的。
在创作模式之外，
组织具有结构和行为模式的对象通常是好事。
它们根本不与初始化者冲突。

例如，看看DOM。
所有节点都由Document对象创建 - 元素，文本节点，注释甚至事件。
这是工厂模式。

然而Document对象也是Facade！
从中您可以访问整个系统的状态，对象，数据，甚至可以写入它！
每个DOM操作都从Document开始，它是DOM系统的Facade。

DOM节点还实现了多种模式。
它们以Composite形式组织，让您使用Observer和Command监听事件，并处理责任链中的事件。
它们肯定由解释器解析，DocumentFragment是一个代理，svg元素实现为装饰器，而createNodeIterator显然为你提供了一个迭代器。

关键是，良好的面向对象设计将产生多种设计模式，无论是有意还是无意。

良好代码外观的秘诀是什么

我认为最好看的代码是最容易理解的代码，
以及随着您获得更多经验而阅读代码的方式。

例如，对于大多数程序员来说，我的风格过于浓缩，但对我而言，它的平衡性很好。
所以要发展自己的风格 - 你不是我，你不是昨天也不是你。

我们经历各种风格时请记住这一点。

在最低级别，我们有编码风格 - 最重要的是缩进和支架。

这个很简单，选择你喜欢的那个并坚持下去。
有语言特定的风格，它们往往是很好的起点。
配置IDE的格式化程序，以便您可以使用热键格式化所有代码。

在代码语法之上，我们有注释样式和命名约定。

设置评论规则很好，有时需要记录工具。
在实践中避免过多的评论。
您可能还想确定命名空间和命名函数表达式的立场。

在这些结构之上，我们有逻辑惯例。

相同的代码逻辑通常可以通过多种方式完成，有些代码逻辑比您眼中的其他方式更"漂亮"。
看看这个例子。

我第一眼就选择了第二种风格：没有重复，逻辑分区干净，格式不是我的风格，而是合理的。
但是许多程序员更喜欢第一种风格：逻辑很明显，一些重复是值得的。
虽然抽象，但这个级别非常深 - 以错误的方式呈现你的逻辑实际上增加了有经验的程序员读错的机会。

最后，我们达到了设计模式的层次，就代码美而言。

保持代码结构美观的关键是使用正确级别的正确模式来始终如一地实现松散耦合和代码重用，
同时避免陷阱和过度设计。

有很多关于漂亮代码的书，
然后还有更多关于设计和实现漂亮软件的书籍。
(决定你自己超出你的水平。)
知识与经验同样重要，只有花时间学习，编写和修改/重构应用程序才能获得知识。

在探索和试验代码时，请随意改变主意。
改变主意是学习的好兆头。

但首先，要熟悉设计模式。
只是不要忘记，它们是将面向对象的主体应用于常见任务的一般结果。
仍然由您来完成设计。

设计模式不是银子弹。

好。