Mastering SOLID Principles with a Simple Kotlin Validator Example

Mastering SOLID Principles with a Simple Kotlin Validator Example

Hey Kotlin devs! ?? Ever wondered why some code might work today but become a headache tomorrow? Let’s explore why this seemingly simple Validator code isn't scalable and how applying SOLID principles can save the day


? S — Single Responsibility Principle (SRP)

  • Each unit of code should have only one responsibility.
  • A unit can be a class, module, function, or component.
  • Keeps code modular and reduces tight coupling.


? O — Open/Closed Principle (OCP)

  • Units of code should be open for extension

  • but closed for modification.

  • Extend functionality by adding new code,

  • not modifying existing code.

  • Useful in component-based systems like a React frontend.


? L — Liskov Substitution Principle (LSP)

  • Subclasses should be substitutable for their base classes.
  • Functionality in the base class should be usable by all subclasses.
  • If a subclass can’t use the base class functionality,

  • it shouldn’t be in the base class.


? I — Interface Segregation Principle (ISP)

  • Provide multiple specific interfaces rather

+?than a few general-purpose ones.

  • Clients shouldn’t depend on methods they don’t use.


? D — Dependency Inversion Principle (DIP)

  • Depend on abstractions, not concrete classes.
  • Use abstractions to decouple dependencies

  • between parts of the system.

  • Avoid direct calls between code units

  • use interfaces or abstractions.


Not Scalable Approach without Solid Principles


?? Why This Code Is Not Scalable:

  1. Adding More Logic Requires Modifications: Want to add "phone number" or "username" validation? You'd have to modify the validate method, making the class grow in complexity. ???
  2. Violates SOLID Principles:Single Responsibility Principle (SRP) ??: This method handles multiple types of validation, so it has more than one reason to change. This makes the code harder to maintain.Open/Closed
  3. Principle (OCP) ?: FormValidator should be open for extension but closed for modification. Constantly editing the class to add new logic breaks this principle.
  4. Testing Challenges: Bundling all logic in one place makes it harder to isolate and test individual validation logic. ????

?? Solution for Scalability: Refactor by creating separate Validator classes that implement a common Validator interface. This makes FormValidator rely on abstractions (following the Dependency Inversion Principle (DIP)) and keeps the code modular, testable, and easy to extend.


? What This Looks Like with SOLID Principles:

Applying Solid Principles


Benefits of Applying SOLID Principles:

  • SRP: Each validator class has one job.
  • OCP: Add a UsernameValidator or PhoneNumberValidator without touching existing code.
  • DIP: FormValidator depends on the Validator interface, not specific implementations.


Kotlin's Modern Approach Explained:

  1. Typealias for Simplicity:
  2. Lambda Functions for Validation Logic:

Benefits of This Approach:

  • Reduced Boilerplate: You don't need to create multiple classes or implement interfaces.
  • Readability and Conciseness: The logic is easier to read and maintain due to its functional nature.
  • Flexibility: It’s easier to create and modify simple validators on the fly without needing to refactor class structures.

When to Use:

  • Ideal for simpler validation logic where defining full-fledged classes or objects might be overkill.
  • Great for projects that use functional programming principles and want more concise code.


Explanation:

  • emailValidator(emailInput): Calls the emailValidator lambda function with emailInput as an argument and stores the result in isEmailValid.
  • phoneValidator(phoneInput): Calls the phoneValidator lambda function with phoneInput as an argument and stores the result in isPhoneValid.
  • The println statements print whether the inputs pass the validation checks.


Summary:-

While using typealias and lambda functions makes the code concise and functional, it doesn’t strictly follow all SOLID principles, especially OCP and DIP. For projects that need more maintainability and scalability, it might be better to use interfaces and class-based implementations to ensure full compliance with SOLID principles.


?? What’s Your Take? Do you use SOLID principles in your projects, or do they sometimes feel like overkill for smaller codebases? Share your thoughts and experiences below in comments! ????


#Kotlin #SOLIDPrinciples #CleanCode #CodingTips #DevLife

要查看或添加评论,请登录

社区洞察

其他会员也浏览了