型变 型变(variance)是类型系统里的概念,包括协变(covariance)、逆变(contravariance)和不变(invariance)。 如果 T[A] 是 T[B] 的子类,则这种关系是「逆变」,因为参数化类型 T 的父子类关系与类型参数的父子类关系是「相反方向的」。 类似地,如果 T[A] 和 T[B] 之间不存在父子类关系,那么这种型变就是「不变」1。 在 Scala 中在类型参数前添加 + 代表参数化类型在该类型参数上协变,添加 - 则代表逆变,什么都不加就是不变。 语义与协变的情况是类似的。 于是,Scala 和 Java 的型变标记可以进行如下总结 3: Scala Java 解释 +T ?
哲学上说变与不变,讲的是绝对运动与相对静止的道理,在代码设计中,也有许多变和不变之间的辩证故事。 当我们享受到代码变化带来的愉悦,也开始追求不变的代码,那一份古朴和单纯。 不变,引伸出对象复用的好处来。 无状态的单例,很多场景下可以看作简单的工具类;更多的对象在一定时期内无状态,比如 Prototype 模式,比如线程池、缓存,这些都将哲学中的变与不变最终结合到代码中去。 不变,是快速的、简单的、敏捷的,将变化的状态连结起来了。 程序=算法+数据,算法是不变的,数据是可变的。仿佛从软件的一开始,变与不变就给后续的万事万物埋下了伏笔,代码的世界围着这个特殊的视角旋转。 不变得再极致一点,我希望从编译之后它就是不变的,而不是对象创建之后不变,这就是方法。
无论它在内存中存储的状态如何变化,该实例的对象标识依旧是保持不变的。显然,变与不变是相对的。 切换到DDD的命题中,所谓“实体”就是那种具有唯一的可识别可跟踪ID的对象。 与之相对的是值对象。在DDD中,强调将领域对象严格区分为实体和值对象。一个指导原则是,当你无法分辨某个领域对象究竟是实体还是值对象时,应优先将其建模为值对象。这有助于我们更好地利用值对象的不可变性。 尤其在纯函数式编程的世界里,任何东西都应该是不变的。 这种不变意味着只要它存在,就不可修改,而且恒古不变。这种追究变化背后的不变性,一直是古希腊哲学乃至科学的基本原则。 我觉得函数式编程追求的不变性,可以划入这个范畴。 赫拉克利特说:“人不能两次踏进同一条河流”。这是赫拉克利特终极的哲学观,即万物随时在变。 这取决于组合子(Combinator)的设计与组合。只要我们找到万物的基本要素,继而设计出各种组合子,就可以演绎出世间不同的物。
这是第一篇:技术的变与不变 变与不变 首先,做为一个技术人员,你要明白一个道理: 对技术而言:唯一不变的事情就是变化 所以,想要成为一个优秀的程序员,你不能期望只精通一门语言或几种框架类库,就能成为你永恒的资本 因为这些人没有意识到技术在变的过程中,存在着『不变』的东西。一旦你掌握及理解了不变的东西,所谓的变化对你而言,可能就如同换肤一样轻易与简单。 这是非常我们反思与思考的一个现象。 我在2020年与前端的一些交集,让我意识到了技术的这种变与不变。对我而言,仿佛这是一个全新的世界。 这也是我想分享出来的原因所在。 这可能是我与前端的第一次相遇。 道与术 这就是我在2020年的感悟到的一个最大的事情 ,技术这个东西原来存在变与不变两方面的东西的。 这就是道与术 理解并掌握了这个,你就能成为一名优秀的程序员,不会害怕任何改变或新技术。
在类型参数前加out)(派生类只是用来输出值) “协变”是指能够使用与原始指定的派生类型相比,派生程度更大的类型。 “逆变”->”逆常的变”->”不正常的变化”->object->string 逆变。 协变(out)是将派生类对象的引用传入到基类对象,输出派生类的值 逆变(in)是将基类对象的引用传入到派生对象,派生对象只能操作基类部分 接口的协变和逆变 1️⃣ 接口的协变 using System 因此变化只是用于引用类型,不能从值类型派生其他类型 b、显式变化使用in和out关键字只适用于委托和接口,不适用于类、结构和方法 c、不包括in、out关键字的委托和接口类型参数叫不变。 这些类型参数不能用于协变或逆变 delegate T Factory< out R, in S, T >(); // 协变 逆变 不变 大家还有什么问题,欢迎在下方留言
PART ONE 开源多元化,国产开源的变局与发展 开源是软件产业的一大创举,也是软件理念的一大发展。以往的硬件时代,所有产品都是一种资源,用则少,不用则不变。 王巨宏表示,近几年国内开源产业热度逐渐提升,优质项目不断涌现,但参与贡献者与开源用户相比仍然偏少,而这与国内整体开源产业的发展历程息息相关。 长跑与短跑不同的地方在于,长跑不能仅仅只是一个人的狂奔。在腾讯内部,开源的流程非常明晰。 王巨宏表示腾讯会继续聚焦于社区开放治理,尤其是在大规模技术推广与应用、开发者生态体系构建、社区领袖与领导力培养、研发资源的优化配置这四个方面持续投入。 王巨宏希望作为一个普通的生态建设者,投入资金和资源,与行业的从业者共同将其生态构建完善。
数据权属与数据主权将得到进一步关注,所有权属和主权的利益冲突和争夺都是来自数据资源化、数据价值化。 大数据之变 根据2013年发布的大数据白皮书显示,十大关注点在于:数据的资源化,大数据的隐私问题突出,大数据与云计算等深度融合,基于大数据智能的出现,大数据分析的革命性方法,大数据安全,数据科学兴起,数据共享联盟 而2014年的十大关注点是:大数据从概念走向现实,大数据架构的多样化模式并存,大数据的安全和隐私,大数据的分析与可视化,大数据产业成为战略性产业,数据商品化与数据共享联盟化,基于大数据的推荐与预测流行, 深度学习与大数据智能成为支撑,数据科学的兴起与大数据生态环境逐步完善。 据CCF大数据专家组预测,2016年与城市、互联网交易和企业相关的三部分数据可能会取得突破性进展,未来一年的资本投入将对该趋势有所印证。 潘柱延透露,今年的大数据白皮书中重点讨论的是大数据开放共享。
目前来看,移动端跨平台需求主要集中在: 跨 PC 端与移动端:PC 向无线过渡的早期,希望 PC Web 与移动 Web 复用同一套代码 跨 Native 与 Web:商品详情页等要求有一套功能差不多的 能够相对容易地迁移过来,例如 Taro Next、kbone 等 P.S.当然,也可以有动静结合的思路,理想情况下,绝大多数基础业务走运行时平迁,个别高性能要求的部分走编译转换 三.重重变化之中,什么才是不变量 渠道/端/平台、业务代码、工程化配套设施似乎都在快速地发生变化,没有哪个是稳定不变的 既然全都在变,就换个角度看,哪个部分一定会发生变化? :大多与技术栈强相关,例如 Web App 的开发、调试、构建、发布、监控、运维与 Native App 存在诸多差异,但其中更基础的部分是技术无关,而流程相关的,例如构建-发布流程、监控运维服务等并不需要跟着变 那么,有没有办法把这些不应该跟着变的部分固定下来?
整体的拔高视角思考一下,我们将所有的状态数据首先进行了重组,有的属性可以在本地直接修改,也就说可以直接调用setState进行修改,但是有些状态属性不能这样做,需要前后端同步,这就需要做一下验证,比方说数量的修改,先与后端同步
与诸多企业家一样,宇视总裁张鹏国也有自己的带队哲学,其中很重要的一个方面,就是“变”。 在2022年的宇视AIoT峰会上,他向AI掘金志阐述了自己对于宇视变化的一些思考。 这对其它企业非常有借鉴意义,不论市场如何变,战略如何变,但企业要搞清楚自身能力、定位。 对于一家公司,知道自己不做什么,比要做什么,同等重要。 承诺永远不变。” 这是张鹏国的原话,目的就是给宇视画一个圈,让宇视在这个圈内做好业务,而不至于因为其它市场利益,而跨界去做一些能力之外或者吃别人的饭。 扩张可能带来好处,但同时会带来迷茫。 今年3月,宇视发布了“阿宇”品牌,深耕县镇村等下沉场景,为了建设下沉渠道生态体系,宇视先后在全国334个城市派出了城市代表,与阿宇合伙人开展市场共建工作;并且投入相应的品牌营销资源,提供金融支持与资金扶持方案 ,与合伙人共同构建覆盖县镇市场的渠道网络。
变与不变 程序员之间的分工协作方式有所变化,开发方式当然也会随着一起变化。但是这种变化其实是非常细微的,很容易上手的。 变 工作内容变 老实说,前后端分离之后,对 Java 程序员的要求变低了,以前大家大家出去面试 Java 工程师,如果是前后端不分的话,前端基本上也是必问的,常见的问题就是各种元素选择器,这也很好理解, 接口变 前后端不分的时候,很少会涉及到接口设计,以 SpringMVC 为例,你可能返回的始终是 ModelAndView 一类的东西,前后端分离之后,我们基本上不需要返回页面了,后端主要是返回 JSON 不变 其实除了前后端交互方式发生变化之外,其他的地方都是不变的。 另一方面,技术的根本不变,例如你做 Java 开发,该会的 SSM/SpringBoot/Redis/Nginx/Dubbo/SpringCloud/MySQL/MyCat/ELK/...等等,都还得会
乍一看,这个框架认为生物主体受最小化不确定性的唯一命令的支配,似乎与刚才描述的丰富审美体验的可能性完全不一致。事实上,它似乎与所有启发我们存在的艺术、有趣和创造性的追求背道而驰。 在神经生物学中,对不确定性消解的认识与多巴胺能放电(与奖励处理相关的那种)有关[18],并在情感推理的背景下以“情感电荷”的形式进行了解释[33]。 197]:“⼀件真正的艺术作品在接 受者的意识中摧毁了他⾃⼰与艺术家之间的分离,⽽且不仅仅如此[……] 在将我们的个性从分离和孤⽴中解放出来的过程中,在这个过程中与他 ⼈的结合,是艺术的主要特征和巨⼤吸引 更一般地说,发现的模式通常与明显的“错误”处于不同的水平。 与非我、尚未被塑造的事物的遭遇。与环境协调的过程感觉很好,但它需要这种遭遇,当它提出可克服的挑战(可减少的预测错误)时,就会建立信任。
以四大入口的变化,履行不变的使命 在“变化”上,2013年给外界留下最深刻印象的,是百度。百度是PC这个岸上的“入口”,现在,它正在过河:传统产业互联网化的大河、移动大河。 面对日新月异的科技浪潮,李彦宏说自己的手段和技术会不断变革,而百度的使命,也是他的使命,则永远不会变。 在BAT三巨头中, 使命不变的似乎只有百度,虽然,看上去2013年的百度与过去并不一样,但实际上依然是围绕着“让人们最平等便捷地获取信息,找到所求”。 不变的是百度的内核:始终站在流量和应用的入口,俯视整个产业,为产业链上的每个利益者输送源源不断的流量和平台支持,同时,其自身消化流量的能力也进一步上升,最终为百度的使命服务。 世界在变,产业环境在变,用户需求在变,游戏规则在变,对手也在变。企业时时刻刻都在选择:顺应什么,坚持什么;何处保守,何处激进;何时转弯,何时刹车……这些选择累加起来决定企业命运。船长为这些选择负责。
02 互联网时代,教育有哪些是不变的? 不变之一:教育的本质不会变 互联网使教育发生重大的,可以说是革命性的变革。 但教育的本质不会变,教育传承文化、创造知识、培养人才的本质不会变,立德树人的根本目的不会变。 教育的这个性质不会变。 ? 不变之二:学校和教师不会消失 有人认为,当今互联网时代,学生时时可学,处处可学,可以不需要学校了,也用不着教师了。这种观念已经被多教学者所否定。 儿童进入学校不仅学知识,重要的是要学做人,学会与人沟通与交往。 教师也不会消失。信息技术、互联网改变了教育环境和方式,但信息技术、互联网改变了教育环境和教育方式,但信息技术、互联网只是手段,不是目的。 关于作者:顾明远,系国家教育咨询委员会委员、北京师范大学资深教授 素材来源:根据2017年12月12日“eduTECH 2017今日头条教育行业未来峰会”现场顾老师制作PPT内容,由漫谈教与育(ID:mtjyy66
报告标题:人工智能背景下,职业教育的变与不变——洞察技术变革,坚守教育初心 发布机构:广州番禺职业技术学院(Guangzhou Panyu Polytechnic) 发布时间:2025年5月16日 行业标签 方法论说明 研究方法:结合定性分析(教育政策解读、案例研究)与定量分析(教学数据追踪),基于职业院校实际教学场景展开实证研究。 解决方案: 专业与课程重构:开设人工智能通识课程,将机器学习、数据分析融入专业教学(如物流专业引入智能仓储案例)。 评价体系改革:推行增值评价(追踪学生进步而非横向比较)与档案袋评价(多维度记录学习过程),依托智能测评系统动态调整题目难度。 资源建设:开发新形态教材(活页式、工作手册式)与智能化自适应学习资源,利用AIGC工具提升开发效率。
True t1 is t2 True 元组(1,2,3)只被创建一次,t1和t2同时指向这个元组,反正你看到copy.copy()就是两个True 这里有一个天天来骗小孩的东西,就是l1变了,l2变不变的问题 首先初始化一个列表l1,里面的元素是一个列表和元组,然后对l1执行浅拷贝,赋予了l2 ,但是l2中的元素和l1指向同一个列表和元组对象,只有列表对象变,你浅拷贝就要跟着我变。 我干嘛跟着你变。 l1.append(100)l1的列表新增元素100,不会对l2产生影响,l1和l2是两个不同的对象 如果我在元组加呢??? l1[1] += (50, 60) l1 [[1, 2, 3], (30, 40, 50, 60), 100] l2 [[1, 2, 3], (30, 40)] 竟然不会变,说白了只有列表对象变,难道元组不可变你不知道 深度拷贝 深度拷贝,就是你爱怎么变,就去哪里变,我就不变了。
不变/协变/逆变,4.0中的这几个概念越念越象绕口令,如果单纯死记硬背,就算记住了,时间长了还是会忘记的。 园子里已经有不少高手撰文写过这个话题:比如“装配脑袋”的NET 4.0中的泛型协变和反变 (2008年他就已经搞明白了这个概念)、偶像Artech的“C# 4.0新特性-"协变"与"逆变"以及背后的编程思想 中(返回)输出参数类型ArumentException继承自Exception,所以返回类型ArgumentException可以向上的转化为Exception不会有任何问题,所以说fn1中的参数类型与fn2 中的参数类型是安全兼容的,但是编译回不允许),这种不允许泛型参数类型变化的特点,称为不变性(invariant). 说穿了就是OOP中的一个常理:子类与父类的继承关系,其实就是is a的关系,所以任何能用父类做为输入参数的地方,当然也能用子类作为替换(子承父业);而任何返回子类的地方,当然也能安全的向上转行为父类.
作为一名程序员,Chris Kiehl 在工作 6 年后,他原有的许多想法有所改变,但也有一些保持不变的旧观点。 1我对这些事情的看法改变了 以下这些事情,在过去,我会争论不休,但现在相信了。 所谓的“最佳实践”是与实际情况相关的,并非广泛适用的。盲目追随它们会让你变成白痴。 在非必要的情况下去设计一个可伸缩的系统,这会让你成为一名糟糕的工程师。 静态代码分析非常有用。 直接与客户沟通总是能以更少的时间和更高的准确性揭示出更多的问题。 “可伸缩”这个词对于软件工程师来说有着一种神秘而令人震惊的力量,足以让他们陷入一种堕落的疯狂。 3那些保持不变的旧想法 那些强调代码风格、lint 规则或其他细节的人都是疯狂的怪人。 代码覆盖率与代码质量毫无关系。 在大多数情况下,使用单体系统就可以了。 TDD 纯粹主义者是最糟糕的。
1 架构十五年:改变的是形态,不变的是目的 业务驱动架构形态变化 过去十几年,随着互联网发展以及业务的多样化,系统的架构也在不断发生变化,总体上来说大体经历了从单体应用架构 - 垂直应用架构 - 分布式架构 这个时候业务架构就需要基于云原生进行改造,如何基于云组件做适配,如何合理使用云的弹性、计算存储分离等功能也变的至关重要。如果继续使用老的业务架构跑在云上,那无异于“拉着马车跑在高速公路上”。 以不变应万变 上面我们从业务的角度盘点了架构的一个大概演进史,过去十几年,软件架构发生了非常大的变化。 关于研发团队组织结构,诞生于 1964 年的康威定律现在依然在指导我们进行软件开发团队组织结构建设 -- 让团队结构与系统结构相匹配(如:与微服务匹配的 two-pizza team)。 另外,除了要勇于去关注技术上新的变化,同时还要有更多思考的角度,重点思考那些历经多年真正不变的技术和理念。
无论是快手与电商的结合,还是抖音开始在社交领域的尝试,我们都可以将它们归结为以短视频为核心的生态体系的搭建。 暗流涌动的调整下,短视频行业的变与不变 无疑,当下的短视频行业正在经历一场前所未有的调整。如果我们将上半场的短视频行业的关键看做是“站得稳”的话,那么,下半场的短视频行业的关键则是“活下去”。 无论短视频行业正在经历怎样的调整,我们依然可以通过窥探短视频行业的变与不变来找到应对当下变局的方式和方法。 短视频的“变化”。 短视频的“不变”。尽管我们看到了短视频行业正在发生的变化,但是,总是有一些元素在短视频行业里始终都是不变的。具体来看,短视频的“不变”主要包含如下几个方面。 1、优质内容的追求永远不变。 看似平静的市场背后暗流涌动,面对新的市场环境,短视频行业或许只有真正把握短视频行业的变与不变,才能真正应对行业变局,不断通过完善自身,获得长久发展。