SOLID Design Rules In Kotlin | by Abhishek Saxena | Dec, 2022 | Tech Zen

B.Earlier than we bounce into the subject of SOLID design ideas, it is advisable to perceive why we want them within the first place. Should you’re listening to the time period SOLID for the primary time, sit again as you may be studying an entire new technique to design your lessons.

Let me attempt to reply a very powerful query.

What number of of you might have been slowed down by actually unhealthy code? All of us sooner or later.

If we all know that unhealthy code slows us down, why can we write unhealthy code?
We do it as a result of we needed to go quick… and we let that sink in.

As Uncle Bob says, Robert C. Martin

You do not go quick in a rush.

You do not go quick simply making it work and releasing it as quick as you’ll be able to.

Do you wish to go quick? You probably did a superb job.

You sit down fastidiously, take into consideration the issue, write somewhat, clear it up, and repeat. So that you go quick.

What are the signs of unhealthy code?

• Code rigidity
  Code that has dependencies in so many instructions that it can not make a change in isolation.
  You modify part of the code and it breaks the calling/dependent class and it’s important to repair it there. In the long run, due to that one change, you find yourself making modifications to 10 totally different lessons.
• code fragility
  Whenever you make a change and an unrelated piece of code breaks.
• tight coupling
  Happens when a category depends upon one other class.

Should you can relate to any of the above points, then this text is for you!

On this article, we’ll discover ways to overcome these issues utilizing SOLID design ideas.

We’d like them to put in writing.

• Versatile Code
• Maintainable Code
• comprehensible code
• The code can tolerate modifications

SOLID is an acronym that stands for five design ideas.

• S — Single Duty Precept (SRP)
• O — Open/Closed Precept (OCP)
• L — Liskov Substitution Precept (LSP)
• I — Interface Segregation Precept (ISP)
• D — Dependency Inversion Precept (DIP)

A module will need to have one and just one motive to alter.

What’s a module?

The best definition is only a supply file.

Nevertheless, some languages ​​and growth environments don’t use supply recordsdata to include their code. In these instances, a module is only a cohesive set of capabilities and information buildings.

Supply: Clear Structure, Robert C. Martin

Earlier than we perceive how SRP is adopted/carried out/used, we have to perceive how it’s not used.

SRP Violation

Can you notice the violation?

The violation is that the Order You deal with multiple accountability which suggests you might have multiple motive to alter.

Resolution

Create a Order who’s chargeable for sustaining the order information.

To create OrderNotificationSender which is chargeable for sending replace notifications to the consumer.

To create OrderInvoiceGenerator which is chargeable for producing the order bill.

To create OrderRepository which is chargeable for storing the order within the database.

We’ve got extracted totally different tasks from the Order class into separate lessons and every class has a single accountability.

Optionally, you’ll be able to even go a step additional and create a OrderFacade which delegates tasks to particular person lessons.

As we will see that every class has just one accountability, thus following the Single accountability precept.

The OCP was coined in 1988 by Bertrand Meyer as

A software program artifact have to be open for extension however closed for modification.

In different phrases, the conduct of a software program artifact must be extensible with out having to switch that artifact.

Supply: Clear Structure, Robert C. Martin

OCP Violation

To know OCP violation, let’s take an instance of a notification service which sends various kinds of notifications: push notifications and e mail notifications to recipients.

As an example I get a brand new requirement and now we assist SMS notifications, which it means i’ve to replace the Notification enumeration and the NotificationService to assist SMS notifications.

So he Notification Y NotificationService it will likely be like that

Because of this each time we modify the notification kind, we should replace the NotificationService to assist the change.

This can be a clear violation of the OCP. Let’s have a look at how one can adjust to the OCP.

Resolution

create an interface Notification.

Create the implementations Notification of every kind – PushNotificationY EmailNotification.

To create NotificationService.

Now you NotificationService follows OCP as you’ll be able to add/take away various kinds of notifications with out modifying the NotificationService.

To create SMSNotification which implements Notification.

As you’ll be able to see, I’ve added SMSNotification unmodified NotificationService thus following the Open/closed precept.

Marginal notice:

That is the one precept that’s actually troublesome to observe and one can not absolutely fulfill it alone in a perfect world.

Since 100% closure can’t be achieved, closure have to be strategic.

In 1988, Barbara Liskov wrote the next as a technique to outline subtypes.

Sure for every object o1 of kind S there may be an object o2 of kind you such that for all applications P outlined by way of youthe conduct of P doesn’t change when o1 is changed by o2 then S is a subtype of you.

In different phrases, it signifies that the kid kind ought to have the ability to change the guardian with out altering the conduct of this system.

Let’s attempt to perceive the precept by wanting on the violation of the notorious Sq./Rectangle downside.

LSP Violation

We all know {that a} rectangle is a 4-sided polygon the place reverse sides are equal and 90°.

A sq. could be outlined as a particular kind of rectangle that has all sides of the identical size.

If squares and rectangles adopted LSP, then we must always have the ability to change one with the opposite.

Please notice: The Sq. and the Rectangle they’re written in Java, as Kotlin code would clearly present the violation with out me testing it

Create a Rectangle

To create Sq.

To create Driver to run the movement.

Within the above code, Driver we will clearly see that Rectangle Y Sq. they can’t change one another. Due to this fact, LSP is clearly violated.

Not at all will the above downside observe LSP. So, for the LSP resolution/instance, we’ll have a look at one other downside.

LSP Instance

Allow us to contemplate a Waste Administration Service that processes various kinds of waste — Natural waste and Plastic waste.

To create Waste Interface

To create OrganicWaste Y PlasticWaste which implements Waste Interface.

To create WasteManagementService

To create LSPDriver

Within the LSPDriver we will clearly see that we will change various kinds of waste, i.e. Natural and Plastic, with one another with out affecting the conduct of this system. Following the Liskov substitution precept.

The interface segregation precept states that builders shouldn’t be compelled to rely on interfaces they don’t use.

In different phrases, the category that implements the interface shouldn’t be compelled to make use of strategies it would not want.

ISP violation

Suppose we’re making a UI library which has parts and the parts can have totally different UI interactions like click on occasions: single click on and lengthy click on.

now we have an interface OnClickListener which has totally different click on behaviors, for a UI part to have this conduct it should implement the OnClickListener Interface.

To create OnClickListener

To create CustomUIComponent

We will clearly see that the CustomUICompoenent is compelled to cancel onLongClick technique regardless that based on the necessities we do not need the CustomUICompoenent to have lengthy click on conduct.

This can be a clear violation of the LSP.

Resolution

This resolution is straightforward, we will separate the OnClickListener interface into two totally different interfaces: OnClickListener Y OnLongClickListenerthey deal with single click on conduct and lengthy click on conduct respectively.

To create OnClickListener

To create OnLongClickListener

To create CustomUICompoenent which implements OnClickListener

Now him CustomUIComponent you aren’t required to cancel onLongClick technique. Therefore, following the Interface segregation precept.

the Dependency inversion precept states that essentially the most versatile techniques are these during which code dependencies refer solely to abstractions, not concretizations.

To know this precept, you should know what I imply once I say that Class A depends upon Class B.

Let’s go a bit out of the best way to know the above line.

As an example I’ve two lessons. ClassA Y ClassBthe code is written as follows

You’ll be able to see on line 9 that an object of ClassA is created and on line 10 the tactic doSomething() is called. What ClassB want an object ClassA to perform appropriately, we will say that ClassA depends upon ClassB.

With the assistance of DIP, we’ll reverse this dependency.

The above diagram exhibits DIP in motion, since now we have reversed the dependency between ClassA Y ClassBthe identical could be seen within the above diagram.

Now let’s examine the instance to know DIP.

An instance the place lessons rely on one another

to illustrate now we have a NotificationService which sends just one kind of notification i.e. e mail notifications as it’s carefully associated to the EmailNotification class.

To create EmailNotification

To create NotificationService

To create NotificationDriver

The issue is NotificationServicedepends upon EmailNotification to ship notifications. That is the place dependency is available in.

We’ve got to take away the dependency in such a approach that NotificationService it doesn’t rely on the kind of notification and will have the ability to ship various kinds of notifications.

Resolution

The answer is sort of easy, since now we have already solved this downside after we mentioned OCP.

To NotificationService to be impartial of the notification kind, then it ought to rely on the summary class or an interface as an alternative of the concrete class, i.e. EmailNotification.

To create Notification Interface.

Create the notification kind — EmailNotification Y SmsNotification

To create NotificationService

To create NotificationDriver

You’ll be able to see that the NotificationService now it depends upon the Notification interface as an alternative of implementation, i.e. e mail servicewe will simply interchange the implementation of the Notification make the system extra versatile. Following the Dependency inversion precept.

All SOLID ideas could be outlined on a single line as follows.

SRP: Each software program module will need to have one, and just one, motive to alter.

OCP – Software program techniques have to be simple to alter, they have to be designed to permit the conduct of these techniques to be modified by including new code, slightly than altering current code.

LSP: To construct a software program system from interchangeable elements, these elements should adhere to a contract that permits these elements to be substituted for each other.

ISP: Software program designers ought to keep away from being depending on issues they do not use.

DIP: The code that implements the high-level coverage should not rely on the low-level particulars.

Supply: Clear Structure, Robert C. Martin