Simplify the mixin code of enhanced enum with extension

Hi I believe that the mixin code in the last part of Chapter 9: enhanced enum can be simplified using an extension:

enum Fruit{

enum Vegetable{

extension on Enum {
  void describe() {
    print('This $runtimeType is a $name.');

This make me think more deeply about the difference between mixin and extension and I find the following:

  • If you extend a parent class with abstract method, adding an extension with concrete method to the child class will not be recognized as implementing the abstract method, while using mixin can do that.
  • You can not give extension to multiple classes at the same time. (code like extension on class1, class2 will raise an error.) You can give mixin to different classes using the with keyword.
  • Multiple mixins and extensions can be applied to the same class.
  • You give mixin while writing the code of the class. You give extension AFTER defining the class.

As a sidetracked note, chatGPT reply me with the following:

The main difference between the two versions is the use of a mixin versus an extension to add the describe method to the Enum class.

Version 1 uses a mixin Describer that extends Enum to add the describe method. This approach allows for code reusability since Describer can be used on any class that extends Enum. However, this approach can lead to a more complex inheritance hierarchy and potential naming conflicts if multiple mixins are used.

Version 2 uses an extension on Enum to add the describe method. This approach is more concise and avoids inheritance complexity. Additionally, extensions are more flexible since they can be added to existing classes without modifying the original class hierarchy.

In terms of maintainability, Version 2 is generally easier to maintain since it is more concise and flexible. However, the choice between using a mixin or an extension depends on the specific use case and coding standards of the project.

Overall, both versions achieve the same goal of adding a describe method to the Enum class, but the approach used in Version 2 is more concise and flexible, making it easier to maintain.

Good observations. I think your last point is the most important: “You give mixin while writing the code of the class. You give extension AFTER defining the class.” Specifically, I mainly use extensions when I don’t control the code, like for extending Dart classes or third-party packages.

This example was rather contrived. My point was to illustrate that it’s technically possible to use mixins (and methods and implementation) with enums similarly to how you would with classes. I’ve never actually needed to write an enum with a mixin in a real project before.

I don’t think I disagree with ChatGPT. I’m not sure that being a few words shorter makes it much easier to maintain, but all other things being equal, conciseness is generally desirable.


Hi @suragch I understand your point. I also think that there is nothing wrong to make up some artificial examples for pedagogical purpose.

May be add a small section extension on Enum after the mixin section in third edition?

My reasons below:

  • I feel more complete on illustrating the class feature of enum.
  • Illustrate to the readers that different approaches are possible for the same problem.
1 Like

Thank you for the suggestion. I’ve opened an issue in the book repo to revisit this topic when we do the update.