系统设计中的可变性原则是指什么?

灵活性及可变性原则。灵活性是指系统对外界环境变化的适应能力。一个系统能否发挥作用和具有较强的生命力，在很大程度上取决于管理上是否可以接受。

因此，在系统设计时，要考虑到用户的业务类型、用户的管理基础工作、用户的人员素质、人机界面的友好程度、掌握系统 *** 作的难易程度等诸多因素的影响。因此在系统设计时，必须充分考虑到这些因素，才能设计出用户可接受的系统。

扩展资料

应用归纳法进行系统设计的程序是：首先尽可能地收集现有的和过去的同类系统的系统设计资料；在对这些系统的设计、制造和运行状况进行分析研究的基础上，根据所设计的系统的功能要求进行多次选择，然后对少数几个同类系统作出相应修正，最后得出一个理想的系统。

演绎法是一种公理化方法，即先从普遍的规则和原理出发，根据设计人员的知识和经验，从具有一定功能的元素集合中选择能符合系统功能要求的多种元素。

然后将这些元素按照一定形式进行组合（见系统结构），从而创造出具有所需功能的新系统。在系统设计的实践中，这两种方法往往是并用的。

参考资料来源：百度百科-系统设计

讨喜的隔离可变性(一)用角色实现隔离可变性

声明：本文是《Java虚拟机并发编程》的第五章，感谢华章出版社授权并发编程网站发布此文，禁止以任何形式转载此文。

Java将OOP变成了可变性驱动（mutability-driven）的开发模式[1]，而函数式编程则着重强调不可变性，而这两种极端的方式其实都是有问题的。如果每样事物都是可变的，那么我们就需要妥善处理可见性和竞争条件。而在一个真实的应用程序中，也并非所有事物都是不可变的。即使是纯函数式语言也提供了代码限制区，在该区域内允许出现带副作用的逻辑以及按顺序执行这些逻辑的方法。但无论我们倾向于哪种编程模型，避免共享可变性都是毋庸置疑的。

共享可变性——并发问题的根源所在——是指多个线程可以同时更改相同的变量。而隔离可变性——一个可以消除大部分并发问题的不错的折衷方案——是指任意时刻有且只有一个线程（或角色）可以访问某个可变变量。

在OOP中，由于对象的状态都被封装在对象中，所以只有实例函数才能够 *** 作对象的状态。然而不同的线程可以同时调用这些函数，从而导致并发问题的发生。在基于角色（actor）的编程模型中，我们只允许一个角色（actor） *** 作对象的状态。因此，即使整个应用程序是多线程的，那些角色（actor）本身也都是单线程的，所以也就不会有任何可见性和竞争条件相关的问题。虽然角色（actor）都可以发出 *** 作执行请求，但它们却无法接触到其他角色（actor）托管的可变状态。

我们在使用基于角色（actor）的模型进行编程时，往往会采取与普通的面向对象编程不同的设计方法。即将问题拆分成若干个可计算的异步任务，并将它们赋予不同的角色（actor）。其中，每个角色（actor）只负责执行分配给自己的那部分任务。这样我们就可以将任意可变状态限定在至多一个角色（actor）当中（见图 8‑1）。此外，我们还需要保证在角色（actor）之间传递的消息都是完全不可变的才行。

在这种设计方法中，我们令每个actor都负责解决问题的一个组成部分，而它们所接收的数据则都当作不可变对象来处理。一旦完成了分配给自己的任务，这些角色（actor）就会把处理结果封装到不可变对象中并返回给调用角色或其他特定的后置处理（post-processing）角色。我们可以将这种方式想象为OOP进化版，即我们让可变且活跃的对象分别运行在属于自己的线程里。在这种模式下，对对象进行 *** 作的唯一方法是将消息传递给它们而不是直接调用其成员函数。

---