两个角度实现一个简单的直播间功能

面向过程的使用

面向过程适合注重性能的，不注重拓展性的，看重当前的，不看重未来的场景。

现在让我们写一个具体需求：我要开发一个直播间，直播间有很多消息，我需要将这些消息进行唯一标记，为了避免刷屏，对同一个人的消息，如果消息的内容相同，那就将它们视为同一个消息。

OK，需求有了。消息要有唯一标记，这就要用到发消息人的 id，以及消息的内容了。需要将这两个属性进行合并，合并成一个属性，那我们可以尝试获取消息内容的长度，然后加上消息的 hashcode，最后再拼上发消息人的 id，以此作为唯一的 key，将整个消息放在一个哈希表里面去（哈希表自带去重功能）。

我们开始写代码：

private Map msgMap = new HashMap<Long,String>();

public void save(int uid, String msg){
    msgMap.put(genID(uid,msg),msg);
}

private long genID(int uid, String msg) {
    // 获取消息的长度
    int size = msg.length;
    // 获取消息的hashcode
    int hash msg.hashCode();
    // 将消息的长度和hashcode合并生成消息id
    int msgId = hash+size;
    // 将用户id作为高32位，消息的id作为低32位
    long onlyID = uid << 32 + msgId;
}

代码仅做个演示。这里只是实现功能性，而不是写架构

算法要求的是啥？是正确性，时间复杂度，空间复杂度，简单来说就是性能。而不是看你用了什么设计模式，好不好改。这你还纠结有几个类型、几个对象吗？

而且，这个需求是你自己的内在需求，又不是那些产品经理提出的，难不成你今天用 uid 算，明天吃饱了撑得慌，就想改成用名字的 hashcode 来算吗？肯定不会啊，我又不傻。

所以说，追求性能的、可变性低的需求，就用面向过程的思维即可。

比如上述需求，第一是追求性能的，第二是我自己提出的，我也肯定不会瞎改，就满足了这两个特点，我就使用面向过程来写了，只追求当前的需要，只注重当前的结果。

如果你在开发中遇到这类问题，代码直接梭哈到一个文件里也是没错的。比如：工具类、配置类、自定算法等。其实，很多人也都是这么做的，只不过不知道这是面向过程一样，这就是人的应激性，现在你知道了。

面向对象的使用

面向对象适合注重拓展性的、看重未来的场景。

假如现在我要写一个直播间功能，产品说：第一版只需要有观众，能发消息、连麦聊天就行。

嗯，第一版只需要这些，那就是后面还有其他版本要加功能了。

好，我们就先来写第一版的代码。核心功能就是两个：发消息和连麦。我们知道，发消息是需要展示在 UI 上的，而连麦则不需要展示在 UI 上，只需要听到就行了。

那么，我们就写两个类来负责这两块功能，如下：

// 负责消息管理的MsgManager
class MsgManager {
    private String[] msgs = new String[1000](); // 用来存放消息，最多存放1000条。
    private int curIndex = 0;
    public void addMsg(String msg) {
        msgs[curIndex++] = msg;
    }
}
// 负责声音管理的AudioManager
class AudioManager {
    public void openMic() {
        // 打开mic
    }
    
    public void closeMic() {
        // 关闭mic
    }
    
    ....其他代码
}

我们为啥用面向对象的呢？为啥不用面向过程的呢？直接代码梭哈到一个文件里不行吗？

当然可以！不过如果后面产品要改需求的时候，遇到的麻烦就很大。

过了一个月，产品来了，我们要添加一个小窗功能，小窗出去的时候，消息不用展示了，但是要能听到声音。

哦，不要消息了，要声音。如果前面把代码都梭哈到一个文件里，这里的扩展就需要一次极大的代码更迭。

其实这里我们应该反思下，我们的代码逻辑可以分为两大类：UI 相关的和 UI 无关的。

我们需要把 UI 相关的写成一大部分，把 UI 无关的写成另一大部分。这样，当我们的 UI 销毁时（比如小窗时），只需要把 UI 相关的销毁即可，而 UI 无关的（比如声音）则继续执行，这就是 MVC 架构的雏形。

那么现在，我们的代码就变成了如下这样：

// 负责UI相关的逻辑
class UIManager {}
// 负责UI无关的逻辑
class DataManager {}

又因为，我们的 UI 需要使用数据来绘制，所以我们的UIManager需要持有DataManager，也就是：

class UIManager {
    DataManager dataManager;
    void displayUI() {
        // 使用dataManager来渲染
    }
}

而且，我们前面章节说过，成员变量的生命周期和对象的生命周期同步，也就是说，当UIManager被销毁后，它持有的dataManager也不存在了，那么，这个dataManager就不应该在UIManager中创建，否则它也会随着UIManager的销毁而销毁。所以，我们应该在一个生命周期更长的地方创建出dataManager，然后在UIManager被创建的时候传给它让它使用。所以，我们的代码就变成了：

// 这是生命周期更长的类
class GlobalManager {
    DataManager dataManager = new DataManager();
}
// 管理UI的类
class UIManager {
    DataManager dataManager;
    
    public void setData(DataManager dataManager) {
        this.dataManager = dataManager;
    }   
}

好，现在，我们的大概框架就搭建好了。当 UI 创建的时候，我们就给它传递dataManager让它渲染 UI；当 UI 销毁的时候，我们的数据在生命周期更长的GlobalManager中继续执行，保证逻辑不断，比如消息还在接收，声音还在传递。这样，下一次你从小窗口回来的时候，你看到的消息、听到的声音，都是最新的，就跟在直播间里面没区别，就像直播间根本就没断开过一样，这也正是我们需要的。

其实，GlobalManger就相当于我们的进程，就像Android中的AppAplication，就像系统中的服务一样，生命周期跟整个应用的生命周期同步。

有人说，这不对啊，你这把数据存放在应用进程一级的了，那不就意味着除非应用退出，否则你的直播间一直在运行吗？那我要退出直播间怎么办？

还记得我们前面讲过的提前结束对象的生命周期吗？没错，就是将它设置为 null！

我们可以改造我们的GlobalManager代码，如下：

// 这是生命周期更长的类
class GlobalManager {
    DataManager dataManager;
    
    // 创建直播间
    public void createLiveRoom() {
        dataManager = new DataManager();
    }
    
    // 销毁直播间
    public void destroyLiveRoom() {
        dataManager = null;
    }
}

这样，我们直播间的生命周期就比我们的应用短了，完全由我们自己来控制。

又有人说了，那我要有两个直播间呢？比如说一个只听声音，一个只打字的，你要怎么实现呢？

我们可以用类似的方法实现，我们修改我们的代码，如下：

// 定义直播间类型
enum RoomType {
    SOUND_ROOM, // 声音直播
    MSG_ROOM, // 消息直播
}
// 定义直播间顶层数据
interface RoomData {}

// 声音直播间数据
class SoundRoomData implements RoomData {}

// 消息直播间数据
class MsgRoomData implements RoomData{}
// 这是生命周期更长的类
class GlobalManager {

    // 用来存放所有的直播间数据
    private Map roomDatas = new HashMap<RoomType, RoomData>();
    
    // 创建直播间
    public void createRoom(RoomType type) {
        if(type == SOUND_ROOM) {
            roomDatas.put(type,new SoundRoomData())
        }else if(type == MSG_ROOM) {
            roomDatas.put(type,new MsgRoomData())
        }
    }
    
    // 销毁直播间
    public void destroyRoom(RoomType type) {
        roomDatas.remove(type);
    }
    
    // 获取直播间数据
    public RoomData getRoomData(RoomType type) {
        return roomDatas.get(type);
    }
}

上述代码逻辑就用一个 map 保存了所有直播间的数据，并且可以多个直播间并存，生命周期也靠自己控制，当然，这只是简单的 demo。

总之，面向对象远比面向过程要复杂，因为它要考虑未来的各种可能性，而未来又是不可预测的，所以我们要写出尽可能多变的、拓展性强的代码，说白了就是：面向拓展编程，或者说是面向未来编程。