里氏替换原则在1994年Barbara Liskov 和 Jeannette Wing发表论文中的描述是: If S is a declared subtype of T, objects of type S should behave as objects of type T are expected to behave, if they are treated as objects of t.
没有洗哦,只是你的理解能力较弱而已。 MIT 协议,允许任何人免费使用、复制、修改、合并、出版、分发、再许可和/或销售软件的副本,只要保留原始许可证中的版权声明和免责声明。 即使是软件作者,也无权阻止,就算发了声明也是无效的;如果作者以此起诉其他人,这种官司作者是必输的,被起诉者连律师都不需要请,还能要求起诉方承担误工费、交通费 ...等各种其他费用。
说句公道话,软件作者是有权修改的; 如果之前的文档也在库里,并且是 MIT 协议的;大家可以放心使用,并且有权公开到互联网中供大家使用,因为这符合 MIT 协议;如果作者明确说明了文档收费并且不使用 MIT 协议了,那么在这之后的文档就不能再以 MIT 协议使用,但在这之前的依旧是 MIT; 说白话一点就是,假设之前的文档有 11 篇,那么这 11 篇遵循的是 MIT 协议;如果作者宣布文档不再使用 MIT 协议后,又多加了几个新的文档,或者修改了之前的文档,那么这些新文档将不能随意传播;注意,之前以 MIT 发布的那些文档大家有权使用,并且有权公开,因为这符合 MIT 协议。 除了使用外,还能将其商业化,因为这也符合 MIT 协议;也就是说,如果大家有兴趣可以在 MIT 协议的文档上自己维护一份,实时地跟进框架源码来写一份属于自己的文档;在这之上新增、修改的文档版权属于维护者,因为这并没有破坏之前的 MIT 协议。 对于收费,如果还有其他做开源的作者,请提前规划好开源协议和发展路线;建议使用 GPL、AGPL 类似的开源协议,这种协议更符合开源精神和GCZY精神;对于想私有化项目的人,可以选择私有化授权。 通常来说,一些开源项目如果声称完全免费的,我都不会去关注,除非该项目得到了其他资金的支持;但如果有两个大致相同的开源项目,一个有商业性质,一个完全免费,我会更关注具备商业性质的开源项目。在 git 上有很多长年不更新的开源项目,通常是刚开始有激情,没多久就不再维护了。 收费并不一定是坏事,通常免费的才是最贵的。但大多数使用者没有计算时间成本,所以只关心是否免费。 大多数白嫖的想法是:你这产品不错、你这框架不错、你这项目不错,应该免费。 还有一些江湖侠客给你说各种大道理,让你免费提供劳动力;这些不过是慷他人之慨的白嫖的人,真让他们付出时,结局是真有一头牛。
开这个特性,不如多重继承。我现在都管不住自己两个儿子,累死了。。
Java:你可以不用,但是我必须要有,叉腰。
限定子类,以后可用于模式匹配,与kotlin的密封类作用类似吧
sealed有一个非常有用的功能就是限定当前类为一个密封类无法被子类的方法所重写。
简单来讲就是你写了一个超类或基类里面封装了一些基础方法,别人可以用,但不想别人去重写这个方法。因为你的父类方法在没有sealed的情况无法避免被子类override重写。这时你可以将你的父类加上sealed前缀,将其声明为密封类,这样别人还是可以用,但无法通过重写来修改同样的方法名称。
打比方有A类func方法,B类继承了A类,并可以重写A类的func方法。C类使用B类就可以调用实际是A类的设计者设计的func方法。但如果B类重写了这个方法,那C类实际调用的是B重写的方法。这是A的设计者不愿见的事情,这时A的设计者想其它通过继承的类无法重写自己的func方法,这时就需要用到sealed方法,而这个特点在工作中非常常见!
举个现实中的例子,张三发表了一篇文章,李四可以通过继承拿来用,但这时李四把文章的内容改了(重写)还打着张三的名义,这时如果文章改得不好,李四没什么,张三就可能被骂,张三想通过方法只让别人引用自己原文,而不能修改这时就可以使用sealed。
六大设计原则通常指SOLID+迪米特法则,这其中非常重要的设计原则就是里氏替代原则,这个原则讲的是一个超类中的共用方法,不能被其它子类重写!在日常工作中,如果两个类都需要一个同样的方法,我们的做法可能会设计一个超类,这两个类都会继承这个类,但是如果说有一个子类重写了这个共有的方法,那这个子类在实现的时候得到的结果和超类的原有方法会不同。而这样就不符合里氏替代原则了,这时sealed类的密封原则阻止了子类override行为,就维护了里氏替代原则不会被违反。所以说sealed这个关键字的设计是有意义的!