本文将向大家介绍一个代码结构检查的神器 - - ArchUnit。在正式介绍ArchUnit之前,先请大家思考一下:
ArchUnit是一个基于 Java 的测试库,用于检查代码的结构特性,如包和类的依赖关系、注解验证,甚至还能检查代码分层是否一致。我们很喜欢 ArchUnit 的地方是,它可以在现有的测试环境中以单元测试的方式运行,尽管只支持基于 Java 的架构。在CI环境或部署流水线中集成ArchUnit 测试套件,可以方便地在演进式架构中实现架构适应度函数。
最近在做一个新项目的时候引入了一个架构方面的需求,就是需要检查项目的编码规范、模块分类规范、类依赖规范等,刚好接触到,正好做个调研。
在今年的敏捷团队建设中,我通过Suite执行器实现了一键自动化单元测试。Juint除了Suite执行器还有哪些执行器呢?由此我的Runner探索之旅开始了!
Archunit是什么,官网的英文介绍很好,建议阅读原文,"ArchUnit is a free, simple and extensible library for checking the architecture of your Java code using any plain Java unit test framework. That is, ArchUnit can check dependencies between packages and classes, layers and slices, check for cyclic dependencies and more"。
作者 | Michael Redlich 译者 | 平川 策划 | 晓昀 本期 Java 近期新闻综述内容主要涉及 OpenJDK、JDK 20、Spring 里程碑更新、Eclipse Tumerin 19、OmniFaces 4.0、PrimeFaces 12.0、OmniFish 简介、Quarkus 2.13.1、Oracle 加入 Micronaut 基金会、Eclipse Vert.x 4.3.4、JobRunr 5.3、Apache Tomcat 9.0.68、Apache Came
Code Review总是让人又爱又恨,它可以帮助我们在提测之前发现很多代码中比较“丢人”的问题,但是,Code Review通常会比写代码更加耗费精力,因为你需要理解别人的代码,而为了这一目的,往往需要很多次的沟通。
依赖反转原则:(DIP :Dependency Inversion Principle)。
YAGNI 跟 KISS 说的是一回事吗?YAGNI 原则的英文全称是:You Ain’t Gonna Need It。直译就是:你不会需要它。这条原则也算是万金油了。当用在软件开发中的时候,它的意思是:不要去设计当前用不到的功能;不要去编写当前用不到的代码。实际上,这条原则的核心思想就是:不要做过度设计。
一种流行的方法是通过技术层面对项目进行分包。但是这种方法有一些缺点。相反,我们可以按功能分包并创建独立自治的程序包。结果是一个易于理解且不易出错的代码库。
几天前,我发表了文章《Twitter的问题说明再好的软件也会腐化》,文中提到避免软件腐化的三种有效手段,其中之一是持续测试。
在依赖注入框架中,字段注入是一种非常流行的做法,例如Spring。然而,它有几个严重的权衡因素,一般来说应该避免。
● 1)单一职责原则 ● 2)接口隔离原则 ● 3)依赖倒转原则 ● 4)里氏替换原则 ● 5)开闭原则 ● 6)迪米特法则 ● 7)合成复用原则
依赖倒置原则(Dependency Inversion Principle,DIP)是SOLID原则中的第五条原则,用于指导面向对象编程中的依赖关系管理。DIP的核心思想是“高层模块不应该依赖于低层模块,它们都应该依赖于抽象”,并且“抽象不应该依赖于细节,细节应该依赖于抽象”。本文将深入探讨DIP的概念、原则、应用、示例和最佳实践。
Keep It Simple and Stupid 这个原则听起来比较简单,重点是理解什么样的代码是简单的,代码行数少就是简单的代码吗???还是说当程序的逻辑十分复杂不容易理解时就是一个复杂的代码呢???
1.“基于接口而非实现编程”,这条原则的另一个表述方式,是“基于抽象而非实现编程”。后者的表述方式其实更能体现这条原则的设计初衷。我们在做软件开发的时候,一定要有抽象意识、封装意识、接口意识。越抽象、越顶层、越脱离具体某一实现的设计,越能提高代码的灵活性、扩展性、可维护性。
从1995年GoF提出23种设计模式到现在,25年过去了,设计模式依旧是软件领域的热门话题。设计模式通常被定义为:
架构即代码,是一种架构设计和治理的思想,它围绕于架构的一系列模式,将架构元素、特征进行组合与呈现,并将架构决策与设计原则等紧密的与系统相结合。 如我的上一篇文章《为“架构”再建个模:如何用代码描述软件架构?》中所说,要准确描述软件的架构是一件颇具难度的事情。仅就实现的层面来说,也已经很难通过一个标准模型来让所有人达成一致,“哦,这就是架构”。也因此,在无法定义架构的情况下,也很难无法给出一个让所有人信服的架构治理模型。毕竟:模型只有合适的,永远没有对的。 ( 示例代码见:https://github.com
PS:本文只是先开个头,思考如何应对这种挑战。 如果只是从系统来考虑,标题里虽然说的是 “分布式” 规范治理,但是更多的时候是指多仓库的规范治理。而多仓库本身也充斥着一些不合理性,诸如于一个代码仓库内,可能包含着多个模块,如 monorepo。从这个角度来看,只是讨论分布式系统,可能有一些单薄。但是呢,我们在写规范,针对的是系统吗?难道不是团队中的开发人员?所以,我们所想的治理的是分布式协作的规范性问题。 回顾开发规范及其工具化 对于软件研发来说,效能的提升是一个非常宏大的史诗级话题,在这个话题里,规范的建
如果没有没有亲自做过一些项目,直接上手就学spring那样的框架,你可能会觉得莫名其妙,有java就够了呀,为什么要学习这么一个陌生的东西。框架其实是软件的半成品,他提供的一些接口、功能,让你可以在他的基础上方便高效地开发,spring的ioc容器即是一例。 Ioc即控制反转,在spring中其实就是依赖注入。一个对象不可能单打独斗,它总要和其他对象进行交互合作,它通过构造参数,工厂方法参数或者对象属性定义其依赖关系,然后通过第三方容器(如spring ioc)在创建该对象时注入这些依赖,这就是控制反转,该
应对于这些问题,其中的一个解决方案就是:自动化的工具,有些人喜欢称之为器。支撑这些工具的便是一系列的原则与模式,将它们融入到工具之中。另外一个解决人成长的方案就是:元元(meta-meta),这是另外一个故事。
上面的问题都来源于对方法的改写动作。如果你在扩展一个类的时候,仅仅是增加新的方法,而不改写已有的方法,你可能会认为这样做是安全的,但是也并不是完全没有风险。
所以后续的设计模式之美会比较偏向笔记风格,课程中的实战篇也不会写出来,感兴趣的可以自行查看原文章。
关于spring bean三种注入方式的优缺点对比,翻译自Spring DI Patterns: The Good, The Bad, and The Ugly,水平有限,如有错误请指正。 Spring开发者会很熟悉spring强大的依赖注入API,这些API可以让你用@Bean的注解让Spring实例化和管理Bean。Bean之间的任何依赖都会被spring解析和注入。
作者 | Karsten Silz VMware 推出了一个实验性的项目 Spring Modulith,以便于通过模块和事件更好地组织 Spring Boot 3 应用。该项目引入了新的类和注解,但并不会生成代码。它的模块没有使用 Java Platform Module System(JPMS),而是映射到了普通的 Java 包。模块有 API,但是 Spring Modulith 鼓励使用 Spring 应用事件作为“主要的交互方式”。这些事件可以自动持久化到事件日志中。Spring Modulit
实际的系统几乎不可能仅有单一的bean,都是很多个bean协作提供服务。本文目标也就是讨论如何冲破单一 bean 定义而让多 bean 协作实现系统。
这是设计模式系列开篇的第一篇文章。也是我学习设计模式过程中的总结。这篇文章主要讲的是面向对象设计中,我们应该遵循的六大原则。只有掌握了这些原则,我们才能更好的理解设计模式。 我们接下来要介绍以下6个内容。
在 一文get到SOLID原则的重点 和 SOLDI原则之DIP:依赖倒置原则 里提到过DIP (依赖倒置原则)里提到过接口所有权的问题。今天再次聊下接口所有权。
正常都能写出这段代码,因为在同一模块下大多数代码都是同一个人写的,所以Book和Author两个类都清楚里面的细节。但如果是不同人写的呢?至少得问下别人,作者名字在哪个类?或者翻阅类中实现细节。
早先呢,我只是因为使用 Java 编写的 ArchUnit 不支持其它语言,而在其它语言的生态里呢,也没有这样的合适的工具。所以呢,我就想着在 Uncode 里设计一个全新的架构守护工具,也就是 Inherd 开源小组里的 Guarding:https://github.com/inherd/guarding/,一个多语言的架构守护工具 —— 基于 Tree Sitter 解析各类编程语言。它设计了一套外部 DSL,其借鉴于 ArchUnit 设计的内部 DSL 语法。
面向对象设计的六大原则 : 单一职责原则, 里氏替换原则, 依赖倒置原则, 接口隔离原则, 迪米特法则, 开闭原则;
在数据库事务中,快照隔离(Snapshot Isolation, SI)是一种已被广泛使用的弱隔离级别,它既避免了可串行化带来的性能损失,又能防止多种不希望出现的数据异常。然而,近期的研究指出,一些声称提供快照隔离级别保证的数据库会产生违反快照隔离的数据异常。在本工作中,我们设计并实现了快照隔离检测器PolySI。PolySI 能够高效地判定给定数据库的执行历史是否满足快照隔离,并在检测到数据异常时提供易于理解的反例。PolySI的性能优于目前已知的最好的黑盒快照隔离检查器,并且可以扩展到包含百万级别事务数量的大规模数据库执行历史上。
依赖反转原则 DIP, Dependency inversion principle
其实这也是我们研究软件架构的根本目的。如果对原始需求的小小延伸就需要对原有的软件系统进行大幅修改,
观察者(Observer)模式的定义:指多个对象间存在一对多的依赖关系,当一个对象的状态发生改变时,所有依赖于它的对象都得到通知并被自动更新。这种模式有时又称作发布-订阅模式、模型-视图模式,它是对象行为型模式。
主要对目前市面上常见的23种设计模式进行逐一分析和总结,希望有兴趣的小伙伴们可以看一下,会持续更新的。希望各位可以监督我,我们一起学习进步,加油,各位。
虽然这些架构在细节上各有不同,但总体是相似的,它们都有一个共同的目标,按照不同的关注点对软件进行切割分层,并且至少有一层是只包含该软件的业务逻辑的,而用户接口,系统接口属于其他层。
new代码味道——狎昵(xia ni)关系:过分亲近 这个主题是我比较想重点聊聊的,因为我个人的理解是依赖注入思想最终想解决的问题就是消除对象之间的耦合,再通俗一点讲就是消除new代码味道,解决的指导思想是将组件的配置和使用分离。 什么是代码味道? 如果某段代码可能存在问题,就可以说有代码味道。这里使用“可能”是因为少量的代码味道并不一定就是问题。 代码味道还可能表明有技术债务存在,而技术债务的修复是有代价的。背负技术债务越久,债务修复就会越难。 代码味道有许多分类。 思考一下为什么除了一些特殊情况外
1.单一职责原则:比如说一个ImageLoader,需要加载图片的缓存图片,此时如果将这两个功能都放在一个类中,就违反了这个原则, 我们需要将不同的功能用类精细组织起来,然后通过成员变量的形式将功能组合起来。 2.开闭原则:如果我们要在1的基础上增加更多的硬件缓存或者双缓存,此时如果只是在原来的类中使用if进行判断那么就违反了这个原则,因为对于一个类我们需要的是对于修改是关闭的,对于扩展是开发的,此时我们就可以将缓存类定义成抽象的接口,然后将各个缓存的实现,以多态的形式设置在ImageLoader之中,此
设计模式是针对软件开发过程中遇到的一些设计问题,总结出来的一套解决方案或者设计思路。
一个类,只有一个引起它变化的原因。应该只有一个职责。每一个职责都是变化的一个轴线,如果一个类有一个以上的职责,这些职责就耦合在了一起。这会导致脆弱的设计。当一个职责发生变化时,可能会影响其它的职责。另外,多个职责耦合在一起,会影响复用性。例如:要实现逻辑和界面的分离。
本文继续来介绍接口隔离原则(ISP)和依赖倒置原则(DIP),这两个原则都和接口和继承有关。文章最后会简单介绍几个除了 SOLID 原则之外的原则。
编写软件过程中,程序员面临着来自 耦合性,内聚性以及可维护性,可扩展性,重用性,灵活性 等多方面的挑战,设计模式是为了让程序(软件),具有如下特征:
之前文章说过, DI其实是一个过程。该过程中,bean可通过如下方式定义它们之间的依赖关系:
候选码通常有一个或多个,用于唯一确定一个元组(行,对象)。举例:主键,唯一索引都可以是候选码。
Java 9引入了一项重要的功能:模块化(Module System)。模块化是一种将代码和资源封装到可重用和独立的单元中的方法,它有助于改善代码的可维护性、可重用性和安全性。本文将介绍Java模块化的基本概念、如何创建和使用模块以及一些最佳实践。
如果明确一个 project 无论出于什么原因考虑都不可能继续分割成子项目,则其依赖可以使用 optional。 如果其他 project 依赖了 使用 optional 的 project, 则他们需要自主选择该依赖,亦即是说,该 optional 依赖不会通过传递性依赖传递给上层的 project。
设计模式和性能优化有没有关系?最近,我看到有人再讲性能优化的时候,讲到了“有些设计模式可以做到一定程度的性能优化”。
最近在读《架构整洁之道》这一本书,这本书的确写得不错,最近也没有更新文章,一方面再忙工作,另一方面也再啃一些书。当然文章还是得更新,《架构整洁之道》里面有些有意思的内容我会提取出来外加自己的思考。在这本书里面的第三章介绍了设计原则,这部分我觉得对于大家的平时工作都比较有用。
领取专属 10元无门槛券
手把手带您无忧上云