设计模式

《架构中的物联网》文章主要是记录我在学习和思考物联网架构设计中的思路。主要从架构设计的角度解析物联网业务场景的解决方式。这些解决方式不仅仅局限于物联网领域，我希望能够透过这些设计来看到架构背后的思想。 业务场景 物联网领域中，设备的在线和离线是不可预知的。由于设备所在的网络环境复杂，甚至可能是极弱的网络条件。那么当我们需要读取当前的设备属性时，并不能保证一定可以读到。我们没有办法保证我们对设备的操作一定能够传达到设备中。那么在这种情况下如何保证我们服务的可靠性？ 思路 我们如果对设计模式有一些了解，我们会发现有一种设计模式的思路很适合这个业务场景，那就是代理模式。既然我们无法保证操作自己的操作一定生效，那么我们就创建一个设备的代理，在物联网领域中，一般称之为设备影子（Device Shadow）。 设计 那么我们如何来设计设备影子呢？或者说一个设备影子至少需要具备什么能力才能称之为设备影子？我们来梳理一下： 基本需求 设备影子至少要能缓存设备的状态，这个是基本的需求，也就是满足对设备“ 读 ”的需求。 设备影子需要能够处理针对设备的操作并保证最后生效，也就是满足对设备“ 写 ”的需求。 设备影子需要正确处理自身状态，保证和真实设备最终趋于一致。 架构 基于我们得到的需求，我们设计了四个模块： 同步器 ：负责与真实设备的同步，主要是解决设备状态的下发和设备状态的检测。 接口层

最近在看设计模式，感觉自己对java的三大特性的理解不够清晰，搞不清楚抽象类、接口、泛型的用处和优缺点。设计模式学了一半，想着还是停下来脑补一下java的基础，就从java对象开始吧。 一、java对象 记得刚开始学java对象的时候，老师给我们解释说“一切事物皆为对象”，即所有东西都是对象，对象就是可以看得到、感觉到、听到、触摸到、尝到、或者闻到的东西。准确地说，对象是一个自包含的实体，用一组可识别的特性和行为来标识。 二、java类 要解释java的类，我们先从一个小例子开始，生活中天气预报是我们经常关注的，把天气预报抽象成一个对象，它可能会有温度、湿度等信息，代码如下： //温度 private int temperature; //湿度 private int humidity; public int getTemperature() { return temperature; } public void setTemperature(int temperature) { this.temperature = temperature; }//加入Java开发交流君样：756584822一起吹水聊天 public int getHumidity() { return humidity; } public void setHumidity(int humidity) {

作者 | 杨长元 来源| 阿里巴巴云原生公众号 导读 ：数据结构、算法、设计模式被认为是程序员必修的三大内功，你对设计模式有什么理解？你是什么时候意识到自己需要好好学习设计模式的？本文将分享作者多年编程道路上的一些思考和心得，以及对如何提升设计能力的几点建议。 当我做完设计相关的培训分享过后，有同学来问我：如何才能快速提升自己的设计能力？我觉得这个问题非常有代表性，代表了一大波程序猿在艰辛的修炼路上的心声。现将我对这个问题的思考、心得体会分享出来，供大家参考，也欢迎提出不同的意见与看法，共同探讨。 编码历练 代码行经验是个非常重要的东西，当你还没有 1 万行代码经验的时候，你来问如何提升设计能力的问题，我只能告诉你不要太纠结，理论看看就好，老老实实写代码吧。 据说，一个程序员平均每天码代码的速度是 200~300 行，你可能会说，我一天怎么也要写上 1000 行吧，别忘了，当你码完代码后，你还需要测试、调试、优化、BUG Fix，这些时间你没法一直码代码的。 编码规范就不多说了，如果你的代码还是杂乱无章的状态，就先别谈什么设计与架构了，我会觉得有点扯淡。 另外，作为代码洁癖患者，推荐大家不要把代码写完后，批量格式化处理，或者手工再去整理代码，而是每敲一个字符上去，它都是符合规范的。习惯真的很重要，有时在招聘面试的时候，我真想添加一个环节，现场编写程序完成一个简单但容易出错的任务。

前言 首先说明这里的后台开发指的就是 Linux 上的 C+ +编程 。因为很多人对后台开发有误解,通常人们说前端后台,后台就马上联想到web后台, java、php和各种web框架横飞的既视感。 web后台属于后台,但后台却不只有web后台。两者是包含关系。 从网络协议的角度分析, web后台聚焦的是HTTP ,而C+ +后台更多聚焦的是TCP。web后台可 以看作是一个大后台最 靠前的东西,它解析了HTTP请求,然后可能层层转发给了后面整个分布式系统的许多组件,然后调用他们的服务。公司内部服务器主机之间绝大部分是通过TCP来通信额。具体来说C+ +后台关注的是socket ,也就是网络编程,还有并发的知识。 因为大公司的server一般都是Linux ,所以应聘C+ +后台,一定要会Linux ,这里的会Linux操作大 致分为两类: 一类是Linux基本操作,包括常用Linux命令和工具的使用、shell脚本的编写 ,能通过脚本完成一 些日常任务。 另一类才是重点一Linux环境编程,你需要对Linux/Unix环境下各种环境编程的API要熟悉 ( POSIX那些函数,当然ANSI标准库的函数也要熟)。经常考察的就是I0、各类IPC的操作方式、socket通信的流程、select/poll/epoll 等I0多路复用模型。socket和IO多路复用是网络编程 的重点。

1.网络排错常用诊断工具介绍 主流网络设备产品提供了一套完整的命令集，可以用于监控网络互联环境的工作状况和解决基本的网络故障。主要包括以下命令： Ping命令 Traceroute命令 Show命令 Clear命令 Debug命令 1.1 Ping命令 1.原理： “ping”这个词源于声纳定位操作，指来自声纳设备的脉冲信号。Ping命令的思想与发出一个短促的雷达波，通过收集回波来判断目标很相似；即源站点向目的站点发出一个ICMP Echo Request报文，目的站点收到该报文后回一个ICMP Echo Reply报文，这样就验证了两个节点间IP层的可达性－－表示了网络层是连通的。 2.功能 Ping命令功能用于检查IP网络连接及主机是否可达。 3.RGNOS平台的ping命令 在RG系列设备上，Ping命令的格式如下： ping ip-address 例如，向主机10.15.50.1 Ping报文 RG # ping 10.15.50.1 //ping通的情况 Switch>PING Target IP address or host: 10.15.50.1 //目的IP Repeat count [5]: 2 //执行次数 Datagram size [100]: 8100 //数据包大小 Timeout in milliseconds [2000]: 5000 //延迟时间

一，前言 ​ 本篇博客分享一些关于Spring中一个核心概念，IOC。 ​ IOC： Inversion of Control ，控制反转。 ​ 通常情况下对于实例化一个对象，我们会通过关键字new创建出来。但是在实际项目开发中不可能有一个实例化对象，而多个对象就需要多个new创建。显然，这势必造成多个对象之间的耦合，以及对程序的维护性带来困难。 ​ 控制反转 ，顾名思义就是将控制权力交给Spring容器。简单理解就是将创建bean的工作交给Spring来做，对于开发人员来说就不需要再手动创建。并且Spring容器会自动维护bean之间的关系，及bean的生命周期等，大大降低了程序之间的耦合。 ​ 接着再说说和IOC相关的另一个概念： ​ DI： Dependency Injection，依赖注入。 ​ 依赖注入 ，在程序运行时，动态的向对象中注入它所依赖的对象。举例，A对象依赖B对象中的某些属性或方法，但是在Spring容器创建A对象之前，并不知道A的依赖关系。因此在真正创建A对象时，发现依赖了B对象，则此时也会将B对象创建出来并注入到A中，这就是依赖注入。 ​ 我个人的理解就是DI是IOC的一种体现方式，这也是DI和IOC两者的区别。 二，IOC核心接口 ​ BeanFactory 和 ApplicationContext 是IOC容器体现形态的两大核心接口

思考题 有如下类设计： 如果牛奶的价钱上扬，怎么办？新增一种焦糖调料风味时，怎么办？ 造成这种维护上的困难，违反了我们之前提过的哪种设计原则？ P82 取出并封装变化的部分，让其他部分不收影响 多用组合，少用继承 思考题 请为下面类的 cost() 方法书写代码。 P83 抽象类：Beverage public class Beverage { public double cost() { double totalCost = 0.0; if (hasMilk()) { totalCost += milkCost; } if (hasSoy()) { totalCost += soyCost; } if (hasMocha()) { totalCost += mochaCost; } if (hasWhip()) { totalCost += whipCost; } return totalCost; } } 具体类：DarkRoast public class DarkRoast extends Beverage { public DarkRoast() { description = "Most Excellent Dark Roast"; } public double cost() { return baseCost + super.cost(); } } 思考题

在 vi 编辑器中，光标可以按行移动，一次性移动一行或者多行。 1. H 命令 H 命令将光标移至当前屏幕的第 1 行，而不是整个文件的第 1 行。若在 H 命令之前加 上数字 n，则将光标移至第 n 行的行首。下面实例演示了使用 H 命令快速移动光标。 1) 在 vi 编辑器中编辑以下代码： #include <stdio.h>int add(int a, int b){ return a + b;}int main (void){ int i; int sum; for (i = 0; i < 3; i++){ sum = add(i, i + 1); printf("%d\n", sum); }} 2) 在命令行模式下，输入 H 命令，光标位于第一行开头，如下所示： #include <stdio.h>int add(int a, int b){ return a + b;}int main (void){ int i; int sum; for (i = 0; i < 3; i++){ sum = add(i, i + 1); printf("%d\n", sum); }} 3) 在命令模式下输入 4H 命令后，光标移到第 4 行的 return 的 r 字符之上： #include <stdio.h>int add(int a, int b){ return a + b;

————— 第二天 ————— ———————————— 装饰器模式都包含哪些核心角色呢？ 1. Component接口 在我们上面的例子中，Component接口相当于汽车接口，所有的被包装类、包装类，都继承于这个接口。 2. ConcreteComponent类 ConcreteComponent类是被包装的实现类。在例子中，奔驰汽车、宝马汽车、特斯拉汽车都属于这个角色。 3 . Decorator抽象类 所有的包装类，都继承自Decorator抽象类，而Decorator类又实现了Component接口，这么做是为了实现多层嵌套包装。 4 . Concrete Decorator类 具体的包装类，用于扩充被包装类的功能，比如例子中的自动驾驶功能、飞行功能扩展。 这四大核心角色的关系是怎样的呢？我们可以用装饰器模式的UML类图来表达： 首先是汽车接口，也就是Component这个角色，里面定义了run这个行为： public interface Car { void run(); } 接下来是各种汽车的实现类，也就是ConcreteComponent角色，不同的汽车对于run行为有着不同的实现： public class BenzCar implements Car{ @Override public void run() { System.out.println("奔驰开车了

导读 ：数据结构、算法、设计模式被认为是程序员必修的三大内功，你对设计模式有什么理解？你是什么时候意识到自己需要好好学习设计模式的？本文将分享作者多年编程道路上的一些思考和心得，以及对如何提升设计能力的几点建议。 当我做完设计相关的培训分享过后，有同学来问我：如何才能快速提升自己的设计能力？我觉得这个问题非常有代表性，代表了一大波程序猿在艰辛的修炼路上的心声。现将我对这个问题的思考、心得体会分享出来，供大家参考，也欢迎提出不同的意见与看法，共同探讨。 编码历练 代码行经验是个非常重要的东西，当你还没有 1 万行代码经验的时候，你来问如何提升设计能力的问题，我只能告诉你不要太纠结，理论看看就好，老老实实写代码吧。 据说，一个程序员平均每天码代码的速度是 200~300 行，你可能会说，我一天怎么也要写上 1000 行吧，别忘了，当你码完代码后，你还需要测试、调试、优化、BUG Fix，这些时间你没法一直码代码的。 编码规范就不多说了，如果你的代码还是杂乱无章的状态，就先别谈什么设计与架构了，我会觉得有点扯淡。 另外，作为代码洁癖患者，推荐大家不要把代码写完后，批量格式化处理，或者手工再去整理代码，而是每敲一个字符上去，它都是符合规范的。习惯真的很重要，有时在招聘面试的时候，我真想添加一个环节，现场编写程序完成一个简单但容易出错的任务。 理论学习 简单说就是看书，看博客