Saurabh Dhingra's Blog

SOLID principles in UI Development

Upcoming Calendar View in EaseMyDeal

Saurabh Dhingra's photo
Saurabh Dhingra
·

4 min read

SOLID principles in UI Development

In building scalable and maintainable applications, adhering to SOLID principles is a cornerstone of good software design. The Calendar Model and Calendar View in our project serve as prime examples of how SOLID principles can be applied to create a clean, modular, and testable structure.

Let's take a look at how each SOLID principle is implemented and provide brief code snippets to highlight the functionality, while keeping the actual business logic abstracted.

1. Single Responsibility Principle (SRP)

The Single Responsibility Principle states that a class should have only one reason to change. In our Calendar system, we separate the logic that handles calendar dates from the presentation of those dates.

  • Calendar Model deals with fetching and manipulating dates.

  • Calendar View is responsible for displaying the dates.

This separation ensures that each class has a well-defined responsibility.

Code Snippet:

// CalendarModel.dart
class CalendarModel {
  List<DateTime> getNext12Months() {
    // Logic to calculate and return dates for the next 12 months.
    return [];
  }
}

// CalendarView.dart
class CalendarView {
  final CalendarModel model;

  CalendarView(this.model);

  void displayCalendar() {
    List<DateTime> months = model.getNext12Months();
    // Logic to display months in the UI.
  }
}

Here, the CalendarModel only handles the data (dates), while CalendarView focuses on the UI. Changes in the date-fetching logic won’t affect how the calendar is displayed, and UI changes won’t disturb the date logic.

2. Open/Closed Principle (OCP)

The Open/Closed Principle states that software entities should be open for extension but closed for modification. Our Calendar Model allows us to extend functionality, such as adding new features (e.g., holidays or custom events), without modifying the core date-fetching logic.

Code Snippet:

// Extending CalendarModel without modifying it
class HolidayCalendarModel extends CalendarModel {
  @override
  List<DateTime> getNext12Months() {
    List<DateTime> months = super.getNext12Months();
    // Additional logic to mark holidays.
    return months;
  }
}

In this example, we extend the functionality of the CalendarModel by creating a HolidayCalendarModel without changing the original class. This allows us to add holiday-specific logic while keeping the base class unchanged.

3. Liskov Substitution Principle (LSP)

The Liskov Substitution Principle ensures that subclasses should be able to replace their base classes without altering the correctness of the program. Our design ensures that any derived class of CalendarModel can be used in place of the original CalendarModel without causing issues.

Code Snippet:

// Both CalendarModel and HolidayCalendarModel can be used interchangeably
CalendarModel model = HolidayCalendarModel();
CalendarView view = CalendarView(model);

view.displayCalendar();  // Works the same for both base and derived classes

By adhering to LSP, we ensure that the CalendarView can work with both CalendarModel and its subclass HolidayCalendarModel without any additional changes to the view.

4. Interface Segregation Principle (ISP)

The Interface Segregation Principle suggests that a class should not be forced to implement interfaces it doesn't use. Instead of a large interface for all calendar functionality, we break it into smaller, more specific ones, ensuring each class only implements what it needs.

Code Snippet:

abstract class ICalendar {
  List<DateTime> getNext12Months();
}

abstract class IEventCalendar {
  List<DateTime> getEvents();
}

class EventCalendarModel implements ICalendar, IEventCalendar {
  @override
  List<DateTime> getNext12Months() {
    // Logic for calendar months
    return [];
  }

  @override
  List<DateTime> getEvents() {
    // Logic for events
    return [];
  }
}

Here, we define separate interfaces (ICalendar and IEventCalendar), allowing models to implement only what is necessary. For instance, EventCalendarModel handles both months and events, but another class could implement just one of these interfaces.

5. Dependency Inversion Principle (DIP)

The Dependency Inversion Principle emphasizes that high-level modules should not depend on low-level modules; both should depend on abstractions. In our system, the CalendarView depends on the abstract ICalendar interface rather than directly on the concrete CalendarModel.

Code Snippet:

class CalendarView {
  final ICalendar calendarModel;

  CalendarView(this.calendarModel);

  void displayCalendar() {
    List<DateTime> months = calendarModel.getNext12Months();
    // Logic to display months in the UI.
  }
}

By depending on the ICalendar interface rather than a specific implementation of the model, the view can now work with any model that adheres to the ICalendar interface, ensuring flexibility and reducing tight coupling between modules.

Conclusion

The implementation of the SOLID principles in our Calendar Model and Calendar View not only results in clean and modular code but also improves maintainability and scalability. Each principle plays a crucial role in making sure that the system is easy to extend and adapt to new requirements without breaking existing functionality.

By adhering to these principles, we ensure that the code is easier to test, extend, and manage in the long term, making it a solid foundation for further development.

FlutterSOLID principles