在应用程序中只使用一种设计模式

Using just one design pattern in application

本文关键字：一种 设计模式 应用程序      更新时间：2023-09-26

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

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

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

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();
  }
 }
};

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

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

谢谢。

更新。

我再试着解释一遍，这次是赏金。

我已经试着问了，但似乎没有人能真正给我一个简洁的答案。

我想知道制作一个好的应用程序的秘密是什么，一个好的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;

than server as a function:

var server =function(env) {
  if (env === 'DEVELOPMENT') {
    // CODE
  } else {
    // CODE
  }
}
module.exports = server;

我可以给100分。对于这个问题，我怎么也找不到一个好的答案，真是不可思议。

谢谢。

我应该使用其他模式吗?

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

没有设计模式书籍会建议你使用单一模式。就像你不能用一种方法切所有的原料(你要切意大利面吗?)，你不能用一种单一的模式组织所有的逻辑。

当然，你可以让所有对象都使用初始化模式，而根本不使用构造函数。这没关系。我也经历过。我喜欢它。

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

以DOM为例。所有节点都是由Document对象创建的——元素、文本节点、注释，甚至事件。这是Factory模式。

然而Document对象也是一个Facade!从它你可以访问整个系统的状态，对象，数据，你甚至可以写它!每个DOM操作都从Document开始，它是DOM系统的门面。

DOM节点也实现了多种模式。它们以复合方式组织，让您使用Observer和Command来侦听事件，并在责任链中处理事件。它们当然是由解释器解析的，DocumentFragment是一个代理，svg元素是作为装饰器实现的，而createNodeIterator显然给了你一个迭代器。

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

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

我认为最好看的代码是你最容易理解的，当你获得更多的经验时，你阅读代码的方式也会改变。 例如，对于大多数程序员来说，我的风格过于简洁，但对我来说，它达到了很好的平衡。所以一定要发展你自己的风格——你不是我，你也不是昨天的你。

当我们浏览样式时，请记住这一点。

在最底层我们有编码风格 -最重要的是缩进和括号。

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

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

为注释设置规则是可以的，有时对于文档工具来说是必要的。在实践中避免过多的评论。您可能还想决定您的命名空间和您对命名函数表达式的立场。

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

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

我第一眼就选了第二种风格:没有重复，逻辑清晰，格式不是我的风格，但合理。但是许多程序员更喜欢第一种风格:逻辑很简单，一些重复是值得的。虽然抽象，但这个层次是相当深刻的——以错误的方式呈现你的逻辑实际上会增加经验丰富的程序员错误阅读它的机会。

最后，我们到达了设计模式的层次，大约是代码的美。

保持代码结构美观的关键是在正确的层次上使用正确的模式来一致地完成松耦合和代码重用。同时避免陷阱和过度设计。

有很多关于优美代码的书，还有更多关于设计和实现漂亮软件的书。(自己决定哪些是超出自己水平的。)知识和经验一样重要，你只能通过花时间学习、写作和修改/重构你的应用程序来获得知识。

在您探索和试验代码时，可以随意改变您的想法。改变思想是学习的好迹象。

但首先，要熟悉设计模式。只是不要忘记，它们是将面向对象原则应用于普通任务的一般结果。设计还是由你来做。

设计模式不是灵丹妙药

我认为这个问题的本质会让你有很多开放式的答案。最终，您需要选择现有范例的最佳方面，并完全或部分地使用其方法。在我看来，您的许多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);
};

祝你的申请顺利。

相关文章：