Hello everyone, I am han Cao 😈, a grass code ape 🐒 who has been working for more than a year. If you like my article, you can follow ➕ to like it and grow up with me. Add my wechat: Hancao97, invite you to join the group, learn and communicate together, and become a better engineer

“This is the 11th day of my participation in the First Challenge 2022. For details: First Challenge 2022.”

background

This is the ninth in my Architectural Cleanliness series, in which we will learn about ISP interface isolation principles

Clean Architecture Series:

  • Hancao’s column on the Way to Neat architecture

ISP interface isolation rules

Let’s take a look at the following software structure:

Multiple users need to manipulate the OPS class. Now, let’s assume that User1 here only needs to use OP1, User2 only needs to make op2, and User3 only needs to use OP3.

Obviously, User1 does not need to call OP2 and OP3, but it also has a dependency on them at the source level. This dependency means that any changes we make to OP2 in the OPS code, even if they do not affect User1’s functionality, will cause it to need to be recompiled and deployed.

This problem can be solved by isolating the different operations into interfaces:

Now User1’s source code will depend on U1Ops and OP1, but not OPS. As a result, any subsequent changes we make to OPS that do not affect User1’s functionality do not require recompiling and deploying User1.

In general, software design at any level can be harmful if it relies on what is not needed. At the source code level, such dependencies lead to unnecessary recompilation and redeployment, and the problem is similar at higher levels of software architecture design. Now let’s take an example:

Let’s say a software architect is designing system S and wants to introduce a framework F into the system. If the authors of framework F bind it to a particular database D, then S depends on F and F depends on D.

In this case, if D contains functions that F does not need, then these functions are also not needed by S. Our changes to these functions in D will result in F needing to be redeployed, which in turn will result in S being redeployed. Worse, an error in an unrelated function in D can also cause F and S to fail.

conclusion

Any level of software design that relies on something it doesn’t need can cause unexpected problems.

The last

✨ ✨ ✨ ✨ ✨ ✨ ✨ ✨ ✨ ✨ ✨ ✨ ✨ ✨ ✨

Youth never knows heaven and earth

Conceit and talent are everywhere you look

Pretentious as it is

I was honest

I love such a boy

Humble and arrogant

Proud and calm ☀️

✨ ✨ ✨ ✨ ✨ ✨ ✨ ✨ ✨ ✨ ✨ ✨ ✨ ✨ ✨

Your likes and attention are my constant motivation, you can add my wechat: HancAO97, invite you to join the group, learn and communicate together, become a better front-end engineer ~