上机材料_上机位软件

上机材料由刀豆文库小编整理，希望给你工作、学习、生活带来方便，猜你可能喜欢“上机位软件”。

Strlen只能获取char类型数组的长度 Char str[20];Cin.getline(str,20);

String str;Getline(cin,str)

Getchar()清除上一个换行符

Fabs()函数求绝对值

#include或#include

#pragma once

功能函数写在主函数之前时要声明

静态分配&动态分配

内存的静态分配和动态分配的区别主要是两个：

一是时间不同。静态分配发生在程序编译和连接的时候。动态分配则发生在程序调入和执行的时候。

二是空间不同。堆都是动态分配的，没有静态分配的堆。栈有2种分配方式：静态分配和动态分配。静态分配是编译器完成的，比如局部变量的分配。动态分配由函数malloc进行分配。不过栈的动态分配和堆不同，他的动态分配是由编译器进行释放，无需我们手工实现。

对于一个进程的内存空间而言，可以在逻辑上分成3个部份：代码区，静态数据区和动态数据区。动态数据区一般就是“堆栈”。“栈(stack)”和“堆(heap)”是两种不同的动态数据区，栈是一种线性结构，堆是一种链式结构。进程的每个线程都有私有的“栈”，所以每个线程虽然代码一样，但本地变量的数据都是互不干扰。一个堆栈可以通过“基地址”和“栈顶”地址来描述。全局变量和静态变量分配在静态数据区，本地变量分配在动态数据区，即堆栈中。程序通过堆栈的基地址和偏移量来访问本地变量。

一般，用static修饰的变量，全局变量位于静态数据区。函数调用过程中的参数，返回地址，EBP和局部变量都采用栈的方式存放。

动、静态内存分配比较可以知道动态内存分配相对于静态内存分配的特点：

1、不需要预先分配存储空间；

2、分配的空间可以根据程序的需要扩大或缩小。

要实现根据程序的需要动态分配存储空间，就必须用到malloc函数.malloc函数的原型为：void *malloc(unsigned int size)其作用是在内存的动态存储区中分配一个长度为size的连续空间。其参数是一个无符号整形数，返回值是一个指向所分配的连续存储域的起始地址的指针。还有一点必须注意的是，当函数未能成功分配存储空间（如内存不足）就会返回一个NULL指针。所以在调用该函数时应该检测返回值是否为NULL并执行相应的操作。

堆&栈

堆：顺序随意 栈：先进后出

一个由c/C++编译的程序占用的内存分为以下几个部分

1、栈区（stack）— 由编译器自动分配释放，存放函数的参数值，局部变量的值等。其操作方式类似于数据结 构中的栈。

2、堆区（heap）— 一般由程序员分配释放，若程序员不释放，程序结束时可能由OS回收。

注意它与数据结构中的堆是两回事，分配方式倒是类似于链表

3、全局区（静态区）（static）—，全局变量和静态变量的存储是放在一块的，初始化的全局变量和静态变量在

一块区域，未初始化的全局变量和未初始化的静态变量在相邻的另一块区域。管理员创建题库（把题条加入题库）

-系统根据管理员输入的某些条件随机生成试题Grasp之信息专家模式 信息专家模式（Information Expert）是GRASP模式中解决类的职责分配问题的最基本的模式。

问题：

当我们为系统发现完对象和职责之后，对象设计和职责分配的基本原则（职责将分配给哪个对象执行）是什么？

解决方案：(将职责分配给信息专家，信息专家是指具有履行职责所需信息的类。)

职责的执行需要某些信息（information），把职责分配给该信息的拥有者。

换句话说，某项职责的执行需要某些资源，只有拥有这些资源的对象才有资格执行职责。这有点类似现实世界的“有能者为之”的概念。你有建筑知识，可以去执行盖楼的职责；你有法律知识，可以去裁判案件等等。

满足了面向对象设计的封装性的设计，一般情况下都会满足Information Expert模式。因为Information Expert是对类的属性（信息），以及对类的属性的操作的封装，它符合对象封装性的概念。优点：

-信息的拥有者类同时就是信息的操作者类，可以减少不必要的类之间的关联。GRASP之创建者模式

创建者模式（Creator）是GRASP模式中解决类的实例的创建职责问题的模式。问题

类的实例的创建职责，应该分配给什么样的类？或者说类的实例应该由谁创建？ Creator模式所提倡的解决方案

以下条件之一为真的情况，类A的实例的创建职责就分配给类B。1，B包含A 2，B聚集A 3，B记录A 4，B频繁使用A 5，B有A初始化数据

Creator模式提倡类的实例（对象）创建职责由聚集或包含该对象的对象创建。

注：Creator模式只是一个原则，如果类A，B之间没有包含或聚集关系，应该先考案是否有“B记录A”，或者“B有A初始化数据”的关系，然后是“B频繁使用A”的关系。另外，作为代替方案，一般的采用工厂（Factory）创建方案。如果不遵循Creator模式，把类的实例的创建职责交给无关的类，类之间的关系变得复杂化，降低系统的可维护性和可扩展性。

一般来说，应用Creator模式，可以从上之下设计好类之间的包含或聚集关系阶层图，让每个类负责创建自己包含的类的实例。应用Creator模式的好处有利于类或组件的重用降低耦合性

Creator模式的应用例

为了更清楚地说明Creator模式，我们举一个GUI的例子：

有一个用户窗口MainWindow，包含Menu，ToolBar，Dialog等，Dialog上布置有Textbox，Button等元素。

我们应用Creator模式，先为它们设计好具有阶层关系的类图，如下：

因为MyMenu，MyToolBar，MyDialog由MainWindow所包含，MyTextbox，MyButton被MyDialog包含，MainWindow由Main类调用。

根据Creator模式所提倡的方法，它们的实例的创建职责的分配应该是： MainWindow的实例由Main创建；

MyMenu，MyToolbar，MyDialog的实例由MainWindow创建； MyTextbox，MyButton的实例由MyDialog创建。

反过来，如果MyMenu，MyToolBar，MyDialog等实例的创建都放在Main类里，那么Main就跟它们产生一种“关联”关系，如果MyMenu，MyToolBar，MyDialog等发生修改，Main也不得不跟着一起修改，也就是说大大增强了Main类跟它们之间的耦合关系；而 Main类本身，也聚集了多余的实例创建功能，降低了Main类的聚合性。

GRASP High Cohesion PatternGRASP之低耦合模式

低耦合模式（Low Coupling）是GRASP模式中为降低类之间的关联程度，适应可变性而提出的面向对象设计的原则性模式。高内聚（High Cohesion）与低耦合（Low Coupling）模式是GRASP其他模式的根本。问题

怎么做才能降低类之间关联程度，能适应需求的变化呢？ Low Coupling模式所提倡的解决方案

为类分配职责时，应该尽量降低类之间的关联关系（耦合性）。亦即，应该以降低类之间的耦合关系作为职责分配的原则。

所谓耦合，是指多个物体（类）之间的物理或者意思上的关联程度。在面向对象方法中，类是最基本的元素，耦合主要指不同类之间相互关联的紧密程度。面向对象里的关联，主要指一个类对另一个类的调用，聚合（包含），参数传递等关系。

比如，所谓2个关联得非常紧密的类（高耦合），是指其中一个类发生变化（修改）时，另一个类也不得不跟着发生变化（修改）。

面向对象设计要求类之间满足“低耦合”原则，它是衡量一个设计是否优良的一个重要标准，因为“低耦合”有助于使得系统中某一部分的变化对其它部分的影响降到最低程度。应用High Cohesion模式的好处GRASP之控制器模式

控制器模式（Controller）是GRASP模式中解决事件处理职责问题的模式。问题

在UI层之外，应该由哪个类来处理（控制）系统操作（事件）呢？或者说，当触发一个系统事件时，应该把对事件的处理职责分配给UI层之外的哪个层呢？ Controller模式所提倡的解决方案

把系统事件的处理职责分配给Controller（控制器）类。担当Controller（控制器）类角色的候补类可能为：

-系统全体，设备，子系统等的表现类（Facade Controller）

-系统事件发生的用例的控制类，通常被命名为Handler，Coordinator，Seion等（用例或Seion的控制器）。整个系统事件都使用同一个控制器。

Controller模式相当于著名的MVC设计模式的C（Controller）部分。

类似于J2EE核心模式中的Front Controller模式（我们会在其它文章中介绍Front Controller模式）。

Controller模式提倡用一个专门的类来处理所有的系统事件。或者说Controller模式把所有系统事件的处理职责分配给一个专门的类集中处理。应用Controller模式的好处

应用Controller模式的系统，对系统事件进行集中处理，所以：有利于共通处理（前处理，后处理等）。

-变化的高适应能力。能够把变化的修改范围控制在最小范围（控制器）之内。

Controller模式的应用例 MVC模式。

MVC模式

MVC模式Model-View-Controller头字母的缩写，中文翻译为“模型-视图-控制器”模式（或者模型）。该模式把一个GUI应用划分为业务逻辑处理（M），画面表示（V），控制（C）三部分，并以此为基础进行设计和开发。

在设计和开发应用系统时，往往需要考虑系统的可维护性，可扩展性，可重用性等；而且，一个大规模的系统开发，往往都是多人分工合作，为了开发上的效率性考虑，一般都安排不同的专家（开发人员）负责不同的领域担当不同的工作。MVC的构成要素：

MVC模式有Model，View，Controller三部分构成。Model 模型。主要用来负责业务逻辑的处理，数据的保持。Model是MVC模式的核心部分，它也是一个应用需要实现的最主要的部分：进行业务逻辑的处理。View 视图。负责数据的输出，画面的表示。Controller 控制器。负责接收从视图发送过来的数据，同时控制Model与View部分。它的主要任务是控制Model与View，所以被称为控制器。

MVC模式输入输出流程图： 1，Controller接收用户输入

2，Controller调用Model进行业务逻辑处理（控制）3，Controller通知/调用View进行画面描画处理（控制）4，View根据需要适当参照Model的值 5，View进行画面描画处理

使用MVC模式，分离模型、视图与控制器，使得这三部分功能相对独立，一方面可以让系统的设计开发工作分工明确，方便开发人员的互相合作；另一方面，按照MVC模式划分的系统的各部分功能保持独立，有利于组件复用，例如，一个模型可以对应多个显示视图，也就是说，同一套业务逻辑只要改变视图便可对应不同的用户界面。

GRASP Polymorphism Pattern避免重复代码

-避免重复的分歧条件

-易扩展。只要实现了统一的通用接口，便可实现行为的扩展

Polymorphism模式的应用例

上面的例子：物体的移动行为，应用Polymorphism设计模式，它的类图便是：

如果我们需要扩展“移动”行为，只需简单地创建一个实现IRunner接口的类。其他应用Polymorphism模式的例

设计模式之Command策略模式 [GoF] Dependency Inversion Principle(DIP)GRASP之纯虚构模式

纯虚构模式（Pure Fabrication）是GRASP扩展模式之一，它把非问题领域中的职责分配给人工定义的类。问题

非问题领域中的职责应该分配给谁？或者说，按照信息专家等模式分配职责时，存在某些不恰当的职责时，应该怎么做？

所谓不恰当的职责，是指难以分配的职责：在保证高内聚，低耦合的条件下，某些职责难以分配给现存的任何问题领域里的类。Pure Fabrication模式所提倡的解决方案 Pure Fabrication模式提倡把那些非问题领域的职责分配给那些人工生成的或者容易此类职责的概念类。

Domain Cla的概念

我们设计对象的时候应该尽量保持与现实世界里的对象一致。这种与现实世界里的对象保持一致的从业务分析中抽象出来的类叫做“Domain Cla”。它相当于上述问题领域里的类。比如一个简单的用例：用户注册。用户就是一个“Domain Cla”，它是现实世界里的业务对象。相当于这里的“问题领域里的类”。

用户注册需要操作数据库，【数据库操作】是系统功能实现的一个必需功能，它不是现实世界里存在的业务对象，它是一个非Domain Cla。如果把【数据库操作】看作一个行为职责，它就相当于这里所说的“非问题领域里的职责”。一般来说，Domain Cla与非Domain Cla的功能如果聚集在一个类里，就破坏了“高内聚”原则。

应用Pure Fabrication模式的好处

-高内聚。不必分配问题领域以外的职责给各Domain类，从而保证各Domain类内部功能上的高度聚集性。

-低耦合。问题领域以外的职责被分配给第三方非Domain类，一方面可以降低各Domain类之间的关联程度，另一方面可以比较漂亮地整合系统的各方面的职责。

-重用性。各Domain类由于功能上的聚集与关联度的降低，可以更容易地得到重用。

Pure Fabrication模式的应用例

以上述“用户注册”的用例为例，对于问题领域里的类“用户（User）”，如果把“数据库操作的职责”分配给“用户（User）”，那么User类的内聚性大大降低。

应用Pure Fabrication模式，应该人工定义一个数据库管理的概念类UserDbMgr，把数据库操作的功能分配给它完成。如图：

如图，分离Domain类User与非Domain类UserDbMgr，User类只保持问题领域中的信息。保证了高内聚性，和易重用性。

GRASP Indirection Pattern中介者模式[GoF]

GRASP Protected Variations Pattern高内聚。具体的功能在各子类中实现，各类的内部功能具有高度聚集性。

-低耦合。用户类只跟稳定接口通信，减少了跟其它陌生对象的关联的机会，降低了类之间的耦合性。

Protected Variations模式的应用例

例：把一段字符串保存到文件，打印机等输出设备。应用Protected Variations模式的类图：

GoF的23种模式

1．创建型模式

前面讲过，社会化的分工越来越细，自然在软件设计方面也是如此，因此对象的创建和对象的使用分开也就成为了必然趋势。因为对象的创建会消耗掉系统的很多资源，所以单独对对象的创建进行研究，从而能够高效地创建对象就是创建型模式要探讨的问题。这里有6个具体的创建型模式可供研究，它们分别是：

简单工厂模式（Simple Factory）；

工厂方法模式（Factory Method）；

抽象工厂模式（Abstract Factory）； 创建者模式（Builder）；

原型模式（Prototype）；

单例模式（Singleton）。

说明：严格来说，简单工厂模式不是GoF总结出来的23种设计模式之一。2．结构型模式

在解决了对象的创建问题之后，对象的组成以及对象之间的依赖关系就成了开发人员关注的焦点，因为如何设计对象的结构、继承和依赖关系会影响到后续程序的维护性、代码的健壮性、耦合性等。对象结构的设计很容易体现出设计人员水平的高低，这里有7个具体的结构型模式可供研究，它们分别是：

外观模式（Facade）；

适配器模式（Adapter）；

代理模式（Proxy）；

装饰模式（Decorator）；

桥模式（Bridge）；

组合模式（Composite）；

享元模式（Flyweight）。

3．行为型模式

在对象的结构和对象的创建问题都解决了之后，就剩下对象的行为问题了，如果对象的行为设计的好，那么对象的行为就会更清晰，它们之间的协作效率就会提高，这里有11个具体的行为型模式可供研究，它们分别是：

模板方法模式（Template Method）；

观察者模式（Observer）；

状态模式（State）；

策略模式（Strategy）；

职责链模式（Chain of Responsibility）； 命令模式（Command）；

访问者模式（Visitor）；

调停者模式（Mediator）；

备忘录模式（Memento）；

迭代器模式（Iterator）；

解释器模式（Interpreter）。

敏捷开发以用户的需求进化为核心，采用迭代、循序渐进的方法进行软件开发。在敏捷开发中，软件项目在构建初期被切分成多个子项目，各个子项目的成果都经过测试，具备可视、可集成和可运行使用的特征。换言之，就是把一个大项目分为多个相互联系，但也可独立运行的小项目，并分别完成，在此过程中软件一直处于可使用状态。