设计程序时,怎么提高扩展性

Posted 2023-03-16

设计程序时,提高扩展性的相关注意：

一个可扩展的应用程序应该能够以某种方式实现增长，并且添加、删除、增强、重构某些组件，对于其他组件的影响微乎其微。

再大的应用程序，往往都是从很小的规模开始，然后一点一点发展起来的。但有时可能会由于增长过快，规模变得越来越大，导致项目难以管理，最终软件可能需要完全重写。

想象一种常见的场景，“A”组件需要组件“B”才能运行，这意味着A对B有一个直接的依赖。如果代码中的组件对彼此的依赖性非常大，就称为高耦合的代码。这种代码最终会导致项目很难维护和更改，一更改就会影响其他部分代码。

高、低耦合的代码在开发人员的工作中有很大的差别，最直接的体现是，在修改部分模块代码所需的时间上，低耦合的代码可能需要5分钟，而高耦合的代码可能会需要5个小时。

解决办法是——编写自包含、自封装、不影响其他组件的代码，最大化地减少依赖。这在理论上很简单，但实践起来非常难。

尽管接口在javascript语言中不存在，但其广泛用于Java或其他语言中。因此，也可以在JavaScript程序中应用接口的概念。

接口是对一组公共方法和属性的描述。一个函数如果要实现接口，那么也需要去实现接口中的所有方法。在面向对象编程中，接口可以解决许多代码重用相关的问题。

因为引入了可扩展性， 导致了代码的可读性降低，那宁可放弃。 软件永远不是一个人维护， 在开发软件的时候，可读性要排在第一位。 如果可读性很差， 影响的不是一个人的效率， 而是所有维护该系统的人的效率。

所以， 在增加软件的扩展性之前， 要三思。 记得三思而行。 写代码永远不是最复杂的一项， 在动手之前，先想好怎么实现，然后说服自己和队员。

扩展资料：

程序设计注意点：

1、在数据库插入之前，应先检查有没有相同记录存在。

2、注意程序中需要LOG的地方的设计，是否每个操作都需要记录LOG。

3、删除一条记录在界面上提示要不要删除，删完后弹出一个框说明删除成功的几条，失败的话说明失败原因。

4、Result在完成后在FINALLY 中关闭。

5、做页面时保存时点完保存最好把按钮DISABLED掉，保存完毕后再恢复。

参考资料：百度百科-设计程序

参考技术A

一个可扩展的应用程序应该能够以某种方式实现增长，并且添加、删除、增强、重构某些组件，对于其他组件的影响微乎其微。

再大的应用程序，往往都是从很小的规模开始，然后一点一点发展起来的。但有时可能会由于增长过快，规模变得越来越大，导致项目难以管理，最终软件可能需要完全重写。

开发人员在一开始编码时就要充分考虑到这种情况。本文以编写功能独立的JavaScript应用为例来说明如何构建可扩展的应用程序，同时还将讨论如何编写可测试、可维护、可调试、直观的代码。

扩展资料：

应用程序中应该包含以下这些不同的实体：

一个作为起始组件的应用实例——/js/app/clock.js (ClockDemo)。

用于准备应用程序所需要的东西，作用是定义依赖关系和创建元素。它接收DOM元素来作为参数，所以应用程序中没有硬DOM引用。一个保存应用程序的状态（时间）的模型——/js/app/models/timer.js (TimerModel)。用于提供必要的时间信息，以便view层可以显示当前时间。

3种时钟的视图。作用是在屏幕上以不同的方式显示一个时钟，所有视图实现相同的接口，以便它们可以以同样的方式收到时间信息。

一个中介者（mediator）——/js/app/mediators/clock.js (ClockMediator)，表示一个DOM元素的。其作用是隐藏和创造时钟，它还连接timer模型到view层，以便可以接收时间。中介者封装了通信事件，并从model层和view层中消除了依赖。

一个selector视图——/js/app/views/selector.js (SelectorView)，用来创建3种不同时钟的按钮。其作用是调度事件，并通知元素需要删除当前的时钟，再创建一个新的时钟。

参考技术B 多针对接口编程而不是针对实现编程
多用组合编程，少用继承 参考技术C 怎么提高扩展性
这个词不知道你有多少理解
高内聚,低耦合
这是软件工程中的概念 。高内聚、低耦合的模块是设计时追求的目标。
这个思想需要你在开发中不断地去理解，贯彻。

内聚：一个模块内各个元素彼此结合的紧密程度

耦合：一个软件结构内不同模块之间互连程度的度量本回答被提问者采纳 参考技术D 多态
多态(polymorphism)在一些编程教材中被弄得很神秘，而在另外一些教程中则被忽
略，其实它不过是C++语言所支持的一个简单而有用的概念。按照C++标准所言，“多态类
型”旧时代由虚函数的类类型(class type)。从设计的角度来看，“多态对象”就是一个具
有不止一种类型的对象，而“多态基类”则是一个为满足多态对象的使用需求而设计的基
类。
让我们看一个金融期权的类型AmOption,如图1所示。

+-------------------------------------------------------+

| Deal iceable |

| ^ ^ |

| | | |

| +------------------------------+ |

| | Option | |

| +------------------------------+ |

| ^ ^ |

| | | |

| AmOption EurOption |

+------------------------------------------------------------------+
图1 在一个金融期权层次结构中多态的作用。AmOption有4种类型

AmOption对象同时具有四种类型：AmOption\Option\Deal\Priceable。由于一个类
型是一组操作，因此，AmOption对象通过其4个接口中的任何一个进行操纵。这意味着一
个AmOption对象可以被针对Deal\Priceable\Option接口编写的代码所操纵，从而允许
AmOption的实现利用或复用所有那些代码。对于AmOption这样的多态类型，从基类继承
的最重要的东西就是他的接口，而不是他的实现。事实上，一个基类仅仅由接口组成不
但常见，而且通常正是我们所希望的。

当然，这里还有一个需要注意的地方。如果让这种优势能够发挥出来，一个良好设计
的多态类对于他的每个基类而言必须是可替换的。换句话说，如果针对Option接口编写的
通用代码接受的是一个AmOption对象，那么该对象的行为最好就像一个Option对象。
这并不是说AmOption对象应该和Option对象的行为完全一致(Option可能有很多纯虚函
数)。实际上一个多态基类想象成一份合同更好理解一些。这个基类对其借口的用户作了
某些承诺，这些承诺包括郑重的语法承诺，即约定的成员函数可以通过一些特定类型的实
参进行调用，以及不容易验证的语义上的承诺，即当一个特定的成员函数被调用时将会发
生什么实际情况。像AmOption和EurOption这样的具体派生类被称为“转包者”，他们实现
Option与其客户签订的合同，如图2所示。

+--------------------------------+

+--------------+ |class Option |

|针对Option | | |

|接口编写的 |< --> | virtual price()=0; |

|代码 | | update(); |

+--------------+ |; |

|---------------------------------+

|class AmOption:public Option |

| |

| virtual price(); |

|; |

|----------------------------------+

|class EurOption:public Option |

| |

| virtual price(); |

|; |

+----------------------------------------+
图2，一个多态的承包者及其“转包者”

举了例子，如果Option具有一个纯虚成员函数Price,其作用是给出Option的当前值，
那么AmOption和EurOption都必须实现这个函数。我们显然不会为这两种类型的Option实
现完全一致的行为，但他们都应该计算并返回一个价格(price),而不应该去拨打一个电
话或者去玩游戏:)

另一方面，如果我们要去访问同一个对象的两种不同接口的price函数，那么我们应
该得到相同的结果。就本质而言，每一个调用都应该绑定到同一个函数：
AmOption *d=new AmOption;
Option *b=d;
d->price();
b->price(); //其实就是说虚函数实际上还是调用的AmOption的。

这是有意义的。假如我问你“那个美国期权的当前值是什么？”，我期望得到与下面
简短提问方式相同的答案：“那个期权的当前值是什么？”
当然，同样的推理也适用于对象的非虚函数：
b->update();
d->update(); //都是调用的b里面的update

正是基于提供的合同允许针对基类借口编写的“多态”代码对特定的合同起作用，同时
有助于对派生类的存在保持“健康的不知情”。换句话说，多态代码可能正在操作AmOption
和EerOption对象，但除非特别关心他们到底是什么对象，否则均被视为Option对象。各
种各样“具体的”Option类型可以被添加或删除而不会影响到只关心基类Option的通用代码。
比方说，如果某一个地方出现一个AsianOption对象，那么只知道Option的多态代码也能
操作它，这全托"对具体类型不知情"的福，如果以后这个对象消失了，也犯不着去挂念它。
出于同样的原因，像AmOption和EurOption这样具体的期权类型只需要知道积累就可
以了，改变通用代码对他们毫无影响。原则上，基类可以不知道出自身以外的任何事物。
从实践的角度来看，对其接口的设计要考虑与其用户的需求，并且应该以这样的方式进
行设计：派生类很容易的推知并实现其合同。然而，基类应该对其派生类的具体细节全
然不知，因为知道这些会不可避免的致使类层次结构上添加或删除派生类变得困难。
和生活中一样，在面向对象设计中，“不知情”或“忽略”也是天赐之福。