Idiomatic Dart: Effective Dart and patterns

Which classic design patterns does Dart code still need, once the language has sealed classes, function types and immutable values? The answer starts with Effective DartEffective Dart: The Dart team's style guide, in four parts (Style, Documentation, Usage, Design), written as DO, DON'T, PREFER, AVOID and CONSIDER rules; package:lints encodes many of them for the analyzer., the style guide the Dart team writes against its own libraries, where every rule starts with one of five words: DO, DON’T, PREFER, AVOID or CONSIDER. Two tools apply much of it for you: dart format fixes the layout, and dart fix rewrites code to follow rules the analyzer knows.

This lesson runs the tools on code that breaks the rules, then writes Strategy and Repository the Dart way. Later parts cover State, immutable values, the constructs to stop reaching for, and patterns that build objects.

The style guide, and the tools that apply it

Effective Dart’s four guides cover layout and naming (Style), doc comments (Documentation), everyday code (Usage) and public APIs (Design). A few rules you meet at once: class names are UpperCamelCase and other identifiers lowerCamelCase; every flow-control statement uses curly braces; and dart: imports come before package: imports. The lints that encode many of these rules are turned on by one line in analysis_options.yaml: include: package:lints/recommended.yaml. The session runs dart analyze and dart fix on a file that breaks several rules.

// Before: against Effective Dart. dart fix rewrites the parts a lint can.
class box {
  var value;
  box(this.value);
  int get doubled {
    return value * 2;
  }
}

void main() {
  var b = new box(21);
  print(b.doubled);
}

"""Shows dart analyze naming Effective Dart problems, then dart fix applying the rules it can."""

from session import files, run

files("style")
run("""
cd style
dart pub get --offline | tail -1
# The lints name the style and usage problems
dart analyze
# dart fix applies the fixes that lints provide
dart fix --apply
sed -n 2,12p bin/box.dart
""", pub=True)

$ cd style
$ dart pub get --offline | tail -1
Changed 1 dependency!
# The lints name the style and usage problems
$ dart analyze
Analyzing style...

   info - bin/box.dart:2:7 - The type name 'box' isn't an UpperCamelCase identifier. Try changing the name to follow the UpperCamelCase style. - camel_case_types
   info - bin/box.dart:3:7 - An uninitialized field should have an explicit type annotation. Try adding a type annotation. - prefer_typing_uninitialized_variables
   info - bin/box.dart:3:7 - Missing type annotation. Try replacing 'var' with a type annotation. - strict_top_level_inference
   info - bin/box.dart:11:11 - Unnecessary 'new' keyword. Try removing the 'new' keyword. - unnecessary_new

4 issues found.
# dart fix applies the fixes that lints provide
$ dart fix --apply
Computing fixes in style...
Applying fixes...

bin/box.dart
  unnecessary_new - 1 fix

1 fix made in 1 file.
$ sed -n 2,12p bin/box.dart
class box {
  var value;
  box(this.value);
  int get doubled {
    return value * 2;
  }
}

void main() {
  var b = box(21);
  print(b.doubled);

dart analyze named four problems: the lowercase class name (camel_case_types), the untyped field (prefer_typing_uninitialized_variables and strict_top_level_inference) and the redundant new (unnecessary_new). dart fix --apply repaired the one with an automatic fix, unnecessary_new, and left the name and the type, because renaming a class and choosing a type need a person. That is the split to remember: the tools settle the mechanical rules, and the style guide is worth reading for the ones that need judgement, such as a doc comment whose first sentence stands alone, starting with a noun phrase for a variable and with a third-person verb for a method that does something.

A pattern is often a language feature in Dart

Many of the classic design patterns were written for languages where a function is not a value and a type hierarchy is the only tool. Dart has first-class functions, so several patterns shrink to a few lines. The StrategyStrategy pattern: A design pattern that makes a behaviour interchangeable. In Dart it is usually a function type rather than an interface with a subclass for each behaviour. pattern, a family of interchangeable behaviours, is the clearest: instead of a Discount interface with a subclass each, a discount is a Discount function, and percent returns one.

// A discount is a function, not a subclass: the Strategy pattern, written the Dart way.
typedef Discount = int Function(int paise);

int none(int paise) => paise;
int flat50(int paise) => paise - 5000 < 0 ? 0 : paise - 5000;
Discount percent(int off) =>
    (paise) => paise - paise * off ~/ 100;

int priceWith(int paise, Discount discount) => discount(paise);

void main() {
  const cartPaise = 120000; // 1,200.00 in paise
  final rules = <String, Discount>{
    'no offer': none,
    'flat 50 off': flat50,
    '10 percent': percent(10),
    '20 percent': percent(20),
  };
  rules.forEach((name, discount) {
    print('$name: ${priceWith(cartPaise, discount)} paise');
  });
}

no offer: 120000 paise
flat 50 off: 115000 paise
10 percent: 108000 paise
20 percent: 96000 paise

Each rule is a function of one type, kept in a map and applied by calling it, with no class to implement; percent(10) is a closure over the rate. Observer is the same story told with Stream, and Command with a function you store and call later.

The RepositoryRepository pattern: A design that hides where data is stored behind an interface, so the code that uses it does not depend on a database; in Dart the interface is an abstract interface class. pattern does need a type, because it names a capability with several methods, and Dart’s way to name a capability is an abstract interface class. The service below depends on OrderStore, not on a database, and receives one through its constructor, which is dependency injectiondependency injection: Giving an object the things it depends on from outside, usually through its constructor, instead of letting it create them, so a test can pass a fake and production a real one. without a framework. A fake store with the same interface makes the service testable.

/// An order a service stores and reads back.
class Order {
  const Order(this.id, this.paise);
  final String id;
  final int paise;
}

/// What the service needs from storage, named as an interface class so callers depend on the shape, not a database.
abstract interface class OrderStore {
  Future<void> save(Order order);
  Future<Order?> byId(String id);
  Future<int> total();
}

/// The service takes its store as a constructor parameter: dependency injection, no global state.
class OrderService {
  OrderService(this._store);
  final OrderStore _store;

  Future<void> place(String id, int paise) {
    if (paise <= 0)
      throw ArgumentError.value(paise, 'paise', 'must be positive');
    return _store.save(Order(id, paise));
  }

  Future<int> totalFor(List<String> ids) async {
    var sum = 0;
    for (final id in ids) {
      final order = await _store.byId(id);
      if (order != null) sum += order.paise;
    }
    return sum;
  }
}

import 'orders.dart';

/// A fake store for tests: a Map instead of a database, with the same interface.
class InMemoryOrderStore implements OrderStore {
  final _orders = <String, Order>{};

  @override
  Future<void> save(Order order) async => _orders[order.id] = order;

  @override
  Future<Order?> byId(String id) async => _orders[id];

  @override
  Future<int> total() async =>
      _orders.values.fold<int>(0, (sum, order) => sum + order.paise);
}

import 'package:repo_demo/memory_store.dart';
import 'package:repo_demo/orders.dart';
import 'package:test/test.dart';

void main() {
  late OrderService service;
  late InMemoryOrderStore store;

  setUp(() {
    store = InMemoryOrderStore();
    service = OrderService(store);
  });

  test('place stores an order the service can total', () async {
    await service.place('a', 40000);
    await service.place('b', 25000);
    expect(await service.totalFor(['a', 'b']), 65000);
  });

  test('place rejects a non-positive amount', () {
    expect(() => service.place('c', 0), throwsArgumentError);
  });

  test('a missing id is skipped, not counted', () async {
    await service.place('a', 40000);
    expect(await service.totalFor(['a', 'missing']), 40000);
  });
}

"""Analyses and tests the repository package: an interface, a fake store and constructor injection."""

from session import files, run

files("repo")
run("""
cd repo
dart pub get --offline | tail -1
dart analyze
dart test
""", pub=True)

$ cd repo
$ dart pub get --offline | tail -1
Changed 49 dependencies!
$ dart analyze
Analyzing repo...
No issues found!
$ dart test
--:-- +0: loading test/orders_test.dart
--:-- +0: test/orders_test.dart: place stores an order the service can total
--:-- +1: test/orders_test.dart: place rejects a non-positive amount
--:-- +2: test/orders_test.dart: a missing id is skipped, not counted
--:-- +3: All tests passed!

The tests pass against the in-memory store, and a real store would implement OrderStore without changing a line of OrderService: the service is written and tested once, and storage is a parameter. abstract interface class says the type is meant to be implemented, not extended, which is one of the class modifiers Effective Dart’s Design guide recommends for a public API’s intent.

Practise

Start with dart create -t package patterns_practice, add lints and test as dev dependencies, and turn on package:lints/recommended.yaml in analysis_options.yaml.

1. Write three shipping rules as functions of one ShippingRule type, keep them in a map, and apply each to a cart.
2. Write a Clock interface with a now() method, a fake that returns a fixed time, and a function that takes a Clock and greets by the hour; test it with the fake.
3. Run dart analyze and dart fix --apply on code that uses new and misnames a class, and read what changed.

State as sealed classes, immutability by default, and what to stop reaching for Pro: opens with a Pro, Premium or Ultimate pass

Building, creating and adapting objects with the language instead of ceremony Pro: opens with a Pro, Premium or Ultimate pass

Interview questions

Three questions in the module’s bank ask you to weigh a pattern against a language feature and defend a style choice:

Key takeaways

• Effective Dart writes its rules as DO, DON’T, PREFER, AVOID and CONSIDER, and dart format and dart fix apply the mechanical ones.
• Strategy is a function type, Observer a Stream and Command a stored function.
• Repository stays an abstract interface class, injected through the constructor so a fake can stand in.