Applying SOLID principles in Flutter

Introduction:

In software development, it’s important to write code that is easy to understand, maintain, and extend. One way to achieve this is by following the SOLID principles, which are a set of guidelines for object-oriented programming. In this blog post, we’ll explore how you can apply the SOLID principles in Flutter development.

Single Responsibility Principle (SRP):

The SRP states that a class should have only one responsibility. In other words, a class should only have one reason to change. This makes it easier to maintain and extend the code.

Let’s consider an example in Flutter. Suppose you have a screen that displays a list of items. The screen has a StatefulWidget, and the items are stored in a database. You might be tempted to put the database logic in the StatefulWidget, but that would violate the SRP. Instead, you should create a separate class for the database logic, and inject it into the StatefulWidget. This way, if you need to change the database logic, you only have to change it in one place.

Here’s an example:

class ItemListScreen extends StatefulWidget {
  final ItemDatabase database;

  ItemListScreen({required this.database});

  @override
  _ItemListScreenState createState() => _ItemListScreenState();
}

class _ItemListScreenState extends State<ItemListScreen> {
  @override
  Widget build(BuildContext context) {
    // use widget.database to retrieve items from the database and display them
  }
}

class ItemDatabase {
  Future<List<Item>> getItems() async {
    // database logic to retrieve items
  }
}

Open-Closed Principle (OCP):

The OCP states that a class should be open for extension but closed for modification. In other words, you should be able to add new functionality to a class without modifying its existing code. This makes it easier to maintain and extend the code.

Let’s consider an example in Flutter. Suppose you have a screen that displays a list of items. You want to add a search feature to the screen. You might be tempted to modify the existing StatefulWidget to add the search functionality. However, that would violate the OCP. Instead, you should create a new class for the search functionality, and inject it into the StatefulWidget. This way, you can add the search functionality without modifying the existing code.

Here’s an example:

class ItemListScreen extends StatefulWidget {
  final ItemDatabase database;
  final ItemSearcher searcher;

  ItemListScreen({required this.database, required this.searcher});

  @override
  _ItemListScreenState createState() => _ItemListScreenState();
}

class _ItemListScreenState extends State<ItemListScreen> {
  @override
  Widget build(BuildContext context) {
    // use widget.database and widget.searcher to retrieve and search items
  }
}

class ItemSearcher {
  Future<List<Item>> search(String query) async {
    // search logic to retrieve items that match the query
  }
}

Liskov Substitution Principle (LSP):

The LSP states that a subclass should be able to replace its parent class without affecting the correctness of the program. In other words, you should be able to use a subclass wherever you use its parent class. This makes it easier to maintain and extend the code.

Let’s consider an example in Flutter. Suppose you have a screen that displays a list of items. You want to add a feature that allows the user to sort the items. You might be tempted to create a separate class for each type of sort, such as PriceSorter and NameSorter. However, that would violate the LSP. Instead, you should create a common interface for sorting, and have each sorting class implement that interface. This way, you can use any sorting class wherever you need to sort items, without affecting the correctness of the program.

Here’s an example:

class ItemListScreen extends StatefulWidget {
  final ItemDatabase database;
  final ItemSorter sorter;

  ItemListScreen({required this.database, required this.sorter});

  @override
  _ItemListScreenState createState() => _ItemListScreenState();
}

class _ItemListScreenState extends State<ItemListScreen> {
  List<Item> _items = [];

  @override
  void initState() {
    super.initState();
    _loadItems();
  }

  Future<void> _loadItems() async {
    List<Item> items = await widget.database.getItems();
    setState(() {
      _items = items;
    });
  }

  void _sortItems() {
    setState(() {
      _items = widget.sorter.sort(_items);
    });
  }

  @override
  Widget build(BuildContext context) {
    // use _items to display the list of items, and call _sortItems to sort them
  }
}

abstract class ItemSorter {
  List<Item> sort(List<Item> items);
}

class PriceSorter implements ItemSorter {
  @override
  List<Item> sort(List<Item> items) {
    // sorting logic to sort items by price
  }
}

class NameSorter implements ItemSorter {
  @override
  List<Item> sort(List<Item> items) {
    // sorting logic to sort items by name
  }
}

Interface Segregation Principle (ISP):

The ISP states that a class should not be forced to implement methods it does not need. In other words, you should create small and focused interfaces, rather than large and general interfaces. This makes it easier to maintain and extend the code.

Let’s consider an example in Flutter. Suppose you have a screen that displays a list of items. You want to add a feature that allows the user to edit items. You might be tempted to create a single interface for all item editing functionality, including methods for creating, updating, and deleting items. However, that would violate the ISP. Instead, you should create separate interfaces for each type of item editing functionality, and have each class implement only the interfaces it needs. This way, you can add or remove editing functionality without affecting the other editing functionality.

Here’s an example:

class ItemListScreen extends StatefulWidget {
  final ItemDatabase database;
  final ItemEditor itemEditor;

  ItemListScreen({required this.database, required this.itemEditor});

  @override
  _ItemListScreenState createState() => _ItemListScreenState();
}

class _ItemListScreenState extends State<ItemListScreen> {
  List<Item> _items = [];

  @override
  void initState() {
    super.initState();
    _loadItems();
  }

  Future<void> _loadItems() async {
    List<Item> items = await widget.database.getItems();
    setState(() {
      _items = items;
    });
  }

  void _editItem(Item item) {
    setState(() {
      _items = widget.itemEditor.edit(item, _items);
    });
  }

  @override
  Widget build(BuildContext context) {
    // use _items and _editItem to display and edit the list of items
  }
}

abstract class ItemEditor {
  List<Item> edit(Item item, List<Item> items);
}

class ItemCreator implements ItemEditor {
  @override
  List<Item> edit(Item item, List<Item> items) {
    // editing logic to create a new item and add it to the list of items
  }
}

class ItemUpdater implements ItemEditor {
  @override
  List<Item> edit(Item item,List<Item> items) {
// editing logic to update an existing item in the list of items
}
}

class ItemDeleter implements ItemEditor {
@override
List<Item> edit(Item item, List<Item> items) {
// editing logic to delete an item from the list of items
}
}

Dependency Inversion Principle (DIP) :

The DIP states that high-level modules should not depend on low-level modules. Instead, both should depend on abstractions. Abstractions should not depend on details, but details should depend on abstractions.

This allows for flexibility and modularity in the code. In Flutter, the DIP can be applied by using dependency injection. Dependency injection means that a class should not create its dependencies, but should be provided with them from the outside. This allows for easy testing and flexibility in the code.

Here’s an example:

class ItemListScreen extends StatefulWidget {
  final ItemRepository repository;

  ItemListScreen({required this.repository});

  @override
  _ItemListScreenState createState() => _ItemListScreenState();
}

class _ItemListScreenState extends State<ItemListScreen> {
  List<Item> _items = [];

  @override
  void initState() {
    super.initState();
    _loadItems();
  }

  Future<void> _loadItems() async {
    List<Item> items = await widget.repository.getItems();
    setState(() {
      _items = items;
    });
  }

  void _editItem(Item item) {
    setState(() {
      _items = widget.repository.editItem(item, _items);
    });
  }

  @override
  Widget build(BuildContext context) {
    // use _items and _editItem to display and edit the list of items
  }
}

abstract class ItemRepository {
  Future<List<Item>> getItems();
  List<Item> editItem(Item item, List<Item> items);
}

class ItemRepositoryImpl implements ItemRepository {
  final ItemDatabase _database;
  final ItemEditor _editor;

  ItemRepositoryImpl({required ItemDatabase database, required ItemEditor editor})
      : _database = database,
        _editor = editor;

  @override
  Future<List<Item>> getItems() async {
    return await _database.getItems();
  }

  @override
  List<Item> editItem(Item item, List<Item> items) {
    return _editor.edit(item, items);
  }
}

In this example, the ItemListScreen depends on the ItemRepository abstraction, which defines the methods needed to get and edit items. The ItemRepositoryImpl class implements the ItemRepository interface and provides the implementation details, such as using ItemDatabase and ItemEditor. The ItemListScreen does not need to know about these details, as it only depends on the abstraction.

Conclusion:

By following the SOLID principles, you can create clean, maintainable, and flexible code in your Flutter projects. You can apply these principles in many different areas of your code, including UI design, data management, and business logic. Remember to always keep the principles in mind when designing and implementing your code, and to refactor as needed to ensure that your code adheres to the principles.