Question

我正在努力学习如何使我的应用程序在所有文件中具有相同的“面部”，相同的模式，但我不知道这是否正确。

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

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

Api.js：

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

Server.js：

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

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

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

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

感谢。

更新

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

我已经尝试过问，但似乎没有人能给我一个简明的答案。

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

例如，我有两个 EXAMPLES 文件

app.js：

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

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

module.exports = app;

server.js：

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

module.exports = server;

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

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

第一个对象：

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

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

module.exports = app;

比作为功能的服务器：

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

module.exports = server;

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

感谢。

Answer 1

我应该使用其他模式吗？

不，你不应该坚持一种模式。

否design pattern books会建议您使用单一模式。就像你不能以一种方式切割所有成分（你是否会骰子意大利面？），你不能用一种模式组织所有逻辑。

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

但是这些对象可以与Builder或Abstract Factory一起使用（如果它可以生成simpler）。只要构建器/工厂本身具有初始化器，并且它们正确地初始化所创建的对象，那么您对初始化器模式的使用将是一致的。在creational模式之外，组织具有structural和behavioural模式的对象通常很好。它们根本不与初始化者冲突。

例如，请查看DOM。所有节点均由Document对象创建 - elements，text nodes，comments，甚至events。这是Factory模式。

然而，Document对象也是一个Facade！通过它，您可以访问整个系统的status，objects，data，甚至可以write to it！每个DOM操作都从Document开始，它是DOM系统的Facade。

DOM节点还实现了多种模式。它们由Composite，let you组织，通过Observer和Command收听活动，并处理Chain of Responsibility中的活动。它们肯定由Interpreter解析，DocumentFragment是Proxy，svg元素implemented为Decorators，而createNodeIterator显然会为您提供Iterator

关键是，良好的面向对象设计会将多个设计模式作为结果产生，无论是否有意。

良好代码出现的秘诀是什么

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

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

在我们浏览styles时记住这一点。

在最低级别，我们有 coding style - 最重要的是缩进和括号。

这个很简单，选择你喜欢的那个并坚持下去。有language specific styles，它们通常是很好的起点。配置IDE的formatter，以便您可以使用热键格式化所有代码。

在代码语法之上，我们有 comment style 和 naming convention 。

在评论上设置rules很好，有时用于记录工具的necessary。在实践中避免使用too much comment。您可能还想确定namespace和naming函数表达式中的展台。

在这些结构之上，我们有逻辑约定。

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

我第一眼就选择了第二种风格：没有duplicate，逻辑被整齐划分，格式不是我的风格，而是合理的。但是许多程序员更喜欢第一种风格：逻辑就像白昼一样，few duplications是值得的。虽然是抽象的，但这个级别是quite deep - 实际上你的逻辑是错误的increase the chance 经验丰富的程序员读错了。

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

保持代码结构美观的关键是使用正确级别的正确模式来始终如一地完成loose coupling和code reuse，同时避免pitfalls和over-design。

There are quite some books about漂亮的代码， and then there are even more books about设计和实施漂亮的软件。（决定你自己超出你的水平。）知识与经验同样重要，只有花时间学习，编写和修改/重构应用程序才能获得知识。

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

但首先，familiarise yourself有设计模式。只是不要忘记，它们是将object-oriented principals应用于常见任务的通用结果。仍然由你来完成设计。

设计模式Are Not Silver Bullets。

Answer 2

我认为这个问题的本质是让你有很多开放式答案的问题。最终，您需要选择现有范例的最佳方面，并使用其方法全部或部分工作。在我看来，您的许多API结构（以及设计模式）将归结为您预期人们如何访问您的应用程序的端点。您提出的构造函数对象的方法是一种常见且非常灵活的方法;它允许对不可避免的代码重写进行原型设计，并且易于观察应用程序的关键和范围。您已准备好支持EMCA6，将其切换到基于Class的构造函数，您将发现自己拥有一个可管理的代码库，可以增长，面向对象并具有非常准确的函数范围。

通常情况下，我开发了应用程序以遵循这种初始化方式（尽量使其尽可能易读）：

var Application = {
    initialise: function (config) {
        config = config || {} // defaults;
        ....
        this.contactServer(config.serverConfiguration);

    },
    contactServer: function (configServer) {
        ....
    },
    renderServerPayload: function (payLoad) {}
};

Application.manageServerResponse = function (serverResponse) {
    this.renderServerPayload(serverResponse);
};

祝你的申请顺利。希望这有点用处。

在应用程序

2 个答案: