我的世界服务器怎么进入观察者模式或者其他的适合录制的模式也可以，gm3，gmsp都没用，主要是用来录制mc的情景剧... 我的世界服务器怎么进入观察者模式或者其他的适合录制的模式也可以，gm 3，gm sp都没用，主要是用来录制mc的情景剧
可选中1个或多个下面的关键词，搜索相关资料。也可直接点“搜索资料”搜索整个问题。
可选中1个或多个下面的关键词，搜索相关资料。也可直接点“搜索资料”搜索整个问题。
“天宇游”是湖南天宇游网络科技有限公司旗下运营的一个手游平台，我们旨为游戏玩家提供手游下载和游戏礼包领取等服务，发布精品的游戏资讯和游戏攻略信息。
输入/gamemode 2进入观看者模式，1.9以上有效 喜欢这个回答就关注下我吧，好看的游戏原创内容和活动等你哟！
模式的秘密——观察者模式
定义对象间的一种一对多的依赖关系。当一个对象的状态发生改变时，所有依赖于它的对象都得到通知并被自动更新。
目标与观察者之间是一对多的关系，当然观察者只有一个也是合理的。
观察者和目标是单向依赖的关系，只有观察者依赖目标，而不是目标依赖观察者，只有目标知道什么时候通知观察者，整个过程中观察者都是被动的，被动的等待目标的通知。
第一，目标接口的定义，建议在名称后面跟上Subject；
第二，观察者接口的定义，建议在名称后面跟上Observer；
第三，观察者接口的更新方法，建议名称为update，参数可以根据需要自己定义。
一般情况是在完成状态维护后触发通知，因为通知会传递数据，不能够先通知再改变数据。
多个观察者之间的通知顺序是不确定的，彼此之间是平行的，观察者之间不应该有相互依赖的关系。
我们以天气状况为例，不同的观察者会根据天气情况选择做不同的事情。
* 观察者接口，定义一个更新的接口给那些在目标发生改变的时候被通知的对象
* 具体的观察者对象，实现更新的方法，使自身的状态和目标的状态保持一致
// 天气内容的情况，这个消息从目标处获取
* 目标对象，它知道观察它的观察者，并提供注册（添加）和删除观察者的接口
* 具体的目标对象，负责把有关状态存入到相应的观察者对象中
观察者模式的实现有两种方式：推模型和拉模型。
推模型：目标对象主动向观察者推送目标的详细信息，推送的信息通常是目标对象的全部或部分数据。
拉模型：目标对象在通知观察者的时候，只传递少量信息。如果观察者需要更具体的信息，由观察者主动向目标对象中获取，相当于是观察者从目标对象中拉取数据。一般这种模型的实现中，会把目标对象自身通过update方法传递给观察者。
上面的实例，我们就使用的是拉模型，接下来我们对上面的实例进行小小的修改，实现推模型。
1、首先，我们需要将Observer.java中的update方法进行修改，如下所示：
5、我们来运行一下，看看结果
推模型和拉模型的比较：
推模型是假定目标对象知道观察者需要的数据。推模型会使观察者对象难以复用。
拉模型是目标对象不知道观察者具体需要什么数据，因此把自身传给观察者，由观察者来取值。拉模型下，update方法的参数是目标对象本身，基本上可以适应各种情况的需要。
使用Java提供的方法有以下四点好处：
第一，不需要再定义观察者和目标的接口了，JDK帮忙定义了
第二，具体的目标实现里面不需要再维护观察者的注册信息了，这个在Java中的Observable类里面已经帮忙实现好了。
第三，触发通知的方式有一点变化，要先调用setChanged方法，这个是Java为了帮助实现更精确的触发控制而提供的功能。
第四，具体观察者的实现里面，update方法其实能同时支持推模型和拉模型，这个是Java在定义的时候，就已经考虑进去了。
* 目标天气的具体实现类
第一，观察者模式实现了观察者和目标之间的抽象耦合；
原本目标对象在状态发生改变的时候需要直接调用所有的观察者对象，但是抽象出观察者接口之后，目标和观察者之间就只是抽象层面上的耦合，目标只是知道观察者的接口，并不知道观察者的类，从而实现了目标与具体的观察者之间的解耦。
第二，观察者模式实现了动态联动；
由于观察者模式对观察者注册实行管理，那就可以在运行期间，通过动态的控制注册的观察者来控制某个动作的联动范围，从而实现动态联动。
第三，观察者模式支持广播通信。
目标发送通知给观察者是面向所有注册的观察者，所以目标每次通知的信息就要对所有注册的观察者进行广播，也可以在目标上添加新的方法来限制广播的范围。
第一，可能会引起无谓的操作；
由于观察者模式每次都是广播通信，不管需不需要每个观察者都会被调用update方法。如果观察者不需要执行相应的方法，调用了方法导致误更新那就麻烦了。
第一，当一个抽象模型有两个方面，其中一个方面的操作依赖于另一个方面的状态改变；
第二，如果在更改一个对象的时候，需要同时连带改变其他的对象，而且不知道究竟应该有多少对象需要被连带改变；
第三，当一个对象必须通知其他的对象，但是你又希望这个对象和其他被通知的对象是松散耦合的。
在使用观察者模式解决实际问题的时候，不同的观察者可能对于同一个目标关注的内容并不相同，比如：同样是天气信息，观察者1只关注下雨的天气情况，而观察者2只关注下雨和下雪的天气情况，那么怎么处理这样的场景呢，我们只有区别对待观察者场景问题，通过下面的例子我们来看看，如何处理上述场景的问题。
//定义一个更新的接口方法给那些在目标发生改变的时候被通知的观察者对象调用
需要“下雨”或者“下雪”的条件通知，其他条件不通知
以上就是观察者模式的基本内容，希望小伙伴们提出问题，我们共同探讨。
观察者模式又称为发布-订阅（Publish/Subscribe）模式，是23种设计模式之一。DP中是这么定义观察者模式的：
观察者模式定义了一种一对多的依赖关系，让多个观察者对象同时***某一个主题对象。这个主题对象在状态发生变化时，会通知所有的观察者对象，使它们能够自动更新自己。
举个生活中的例子，例如在某班级里，几个同学都在某个网站上订阅了一本连载的漫画。当漫画更新时，就会通知这几位同学，同学收到通知后就可以去下载漫画的最新篇章。这就是一个典型的观察者模式，在这里同学都是观察者，而漫画则是他们共同***的一个主题，而漫画更新时也就是主题对象发生变化时，就会通知所有订阅该漫画的同学，所以漫画也就是通知者。同学们收到通知后就可以去下载漫画的新篇章了，这就是主题对象会通知观察者对象让他们进行更新。
我们使用简单的代码，来尝试实现一下这个场景：
学生类，也就是观察者：
// 得到通知时，就去下载新漫画 // 订阅该漫画的学生 // 订阅的漫画更新了您订阅的XXX漫画更新啦, 小明请下载漫画的新篇章！
您订阅的XXX漫画更新啦, 小红请下载漫画的新篇章！以上的代码实现了一个简单的观察者模式，当漫画这个主题对象的状态发生改变时，就会通知所有的订阅者。
我们编写的代码虽然可以实现以上所说到的场景，但是代码的耦合性很高，不能完全符合观察模式的设计理念。例如，我要增加一个订阅的是小说类型的学生，那么就得去修改 “漫画” 通知者的代码了。如果我还要增加一个 “小说” 通知者，让 小说” 通知者也能通知所有学生的话，也需要去修改学生类的代码，这就不符合开-闭原则了，而且对象之间互相依赖也违背了依赖倒转原则，以及以上的代码中没有编写取消订阅的方法也就是减少观察者的方法。
既然知道代码有哪些问题了，那么我们就来把这些代码重构一下：
// 通知者/主题接口2.然后才是具体的实现类：
// 添加订阅该漫画的学生 // 漫画更新时通知学生 // 得到通知时，就去下载新漫画 // 得到通知时，就去下载小说的新篇章 // 取消订阅，减少订阅的学生 // 订阅的主题更新了您订阅的XXX更新啦, 小明请下载漫画的新篇章！
您订阅的XXX更新啦, 小刚请下载小说的新篇章！从客户端的代码可以看到，抽象了两个类之后，即便是只有一个 ”漫画“ 通知者也能够通知订阅不同类型主题的观察者，而不需要去修改任何的代码。同样的，我把 ”漫画“ 通知者换成 “小说” 通知者也丝毫不会受到影响：
// 取消订阅，减少订阅的学生 // 订阅的主题更新了您订阅的XXX更新啦, 小明请下载漫画的新篇章！
您订阅的XXX更新啦, 小刚请下载小说的新篇章！这样的设计就满足了依赖倒转原则以及开-闭原则，算得上是一个完整的观察者模式设计的代码了。
我们再来看看观察者模式（Observe）的结构图：
我们来使用代码实现这个结构：
Subject类。该类通常被称为主题或抽象通知者，一般使用一个抽象类或者接口进行声明。它把所有对观察者对象的引用保存在一个集合里，每个主题都可以有任何数量的观察者。抽象主题提供一个接口，可以增加和删除观察者对象：
Observer类，抽象观察者，为为所有的具体观察者定义一个接口，在得到主题的通知时更新自己。这个接口叫更新接口。抽象观察者一般用一个抽象类或者一个接口实现。更新接口通常包含一个update方法，这个方法叫更新方法：
ConcreteSubject类，叫做具体的主题或具体的通知者，该类将有关状态存入具体的观察者对象。在具体主题的内部状态改变时，给所有登记过的观察者发出通知。具体主题角色通常用一个具体的子类来进行实现：
ConcreteObserver类，具体的观察者类，实现抽象观察者角色所要求的更新接口，以便使本身的状态与主题的状态相协调。具体观察者角色可以保存一个指向具体主题对象的引用。具体观察者角色通常用一个具体的子类进行实现：
将一个系统分割成一系列互相协作的类有一个很不好的副作用，那就是需要维护相关对象之间的一致性。我们不希望为了维持一致性而使各类紧密耦合，这样会给维护、扩展和复用都带来不便。而观察者模式的关键对象是主题 Subject 和观察者Observer ，一个 Subject 可以有任意数目的依赖它的 Observer ，一旦Subject的状态发生了改变，所有的Observer 都可以得到通知。Subject发出通知时并不需要知道谁是它的观察者，也就是说，具体观察者是谁，它根本不需要知道。而任何一个具体观察者不知道也不需要知道其他观察者的存在，这样降低了子类之间的耦合。
什么时候考虑使用观察者模式？
1.当一个对象的改变需要同时改变其他对象的时候，而且它不知道具体有多少个对象有待改变时，应该考虑使用观察者模式
2.当一个抽象模型有两个方面，其中一方面依赖于另一方面，这时用观察者模式可以将这两者封装在独立的对象中使它们各自独立地改变和复用。
观察者模式所做的事情其实就是解耦合，让耦合的双方都依赖于抽象，而不是依赖于具体，从而使得各自的变化都不会影响另一边的变化。
我们没办法让每个控件都是实现一个 “Observer” 接口，因为这些控件都早已被它们的制造商封装好了。而且我们上面的例子，尽管已经用了依赖倒转原则，但是 “抽象通知者” 还是依赖 ”抽象观察者“ ，也就是说，万一没有了 ”抽象观察者“ 这样的接口，那么通知功能就无法完成了。既然 ”通知者“ 和 ”观察者“ 之间根本就互相不知道，那么我们就换另一种方式，让客户端来决定通知谁，这就是接下来要提到的事件委托模式。
事件委托模式在Java的Swing图形化中经常使用，但是在Java语言中没有对其做一定的封装，因此实现起来没那么容易，不过反射机制学得还不错的话，其实很好理解实现原理。相比之下C#就容易了很多，C#里有一个delegate关键字，只需要声明一个委托器就可以了。在Java中我们需要自己通过反射机制去实现，正好把上面演示的例子使用事件委托模式进行重构，一会再说明什么是事件委托：
1.去掉观察者Observer接口，把两个具体的观察者类的代码修改为如下内容：
// 得到通知时，就去下载新漫画 // 得到通知时，就去下载小说的新篇章2.定义一个事件类，该类通过反射机制完成对观察者对象方法的调用：
* 事件类，通过反射机制调用观察者对象的方法 // 要执行方法的对象 // 要执行的方法名称 // 要执行的方法的参数 // 要执行方法的参数类型 // 根据参数数组生成参数类型数组 // 通过反射机制执行该观察者对象的方法3.事件处理类，该类将事件源信息收集给事件类：
* 事件处理类，收集事件信息交给事件类执行 // 添加某个观察者对象要执行的方法，以及方法所需要的参数 // 通知所有的观察者对象执行指定的方法 // 通知者、主题接口 // 增加观察者，也就是订阅的学生 // 通知学生订阅的内容更新了 // 转发到事件处理类上Story类的代码也是一样的，忽略。
// 添加观察者，或者说添加订阅学生，把两个不同的类以及不同的方法委托给事件处理类以上客户端的代码可以看到，为了方便演示，我们是通过字符串来传递需要执行的方法的名称。还有另一种方式就是可以通过接口去定义方法的名称，就像Swing中添加点击事件一样，需要实现ActionListener接口里定义的actionPerformed方法，这样我们就只需要传递观察者对象即可，然后反射机制就扫这个对象是否有实现接口中定义的方法就可以了。不过如果不是像点击事件那种固定不变的方法的话，还是使用字符串来传递需要执行的方法的名称会好一些，这样便于修改。
21:10:30 您订阅的XXX更新啦, 小明请下载漫画的新篇章！
21:10:30 您订阅的XXX更新啦, 小红请下载小说的新篇章！现在就可以来解释一下，事件委托是什么了。这就好比我是班长你是班主任，你让我通知某几个学生去办公室，然后我就去通知那几个学生办公室，这就是一个委托，你委托的事情是让我去通知你指定的那几个学生。而我就是通知者，与观察者模式不同的是，我是因为有你的委托才能去通知学生，而观察者模式是当主题状态发生变化时通知观察者。上面的客户端代码里，我们将订阅了相关内容的学生，委托给了通知者，所以通知者就可以对这些学生发出通知，但实际调用观察者方法的是Event类，不是通知者了。
而且一个委托可以搭载多个方法，这些方法可以是不同类的方法，当发送通知时所有的方法会被依次调用。这样我们就不需要在通知者上用一个集合存储观察者了，增加、减少观察者的方法也不需要编写了，而是转到客户端来让给委托搭载多个方法，这就解决了本来与抽象观察者耦合的问题。也就是说观察者模式是由抽象的观察者来决定调用哪个方法，而事件委托模式是由客户端决定调用哪个方法，这样通知者就不需要依赖抽象观察者了。