Skip to content

Commit e3db6c1

Browse files
committed
Changes made :
1)Reverted back the top level information 2)Shortend the wordings as mentioned 3)Rephrased the lines 4)Mirrored the mentioned section as said
1 parent 82c8635 commit e3db6c1

File tree

1 file changed

+9
-24
lines changed

1 file changed

+9
-24
lines changed

src/content/effective-dart/design.md

Lines changed: 9 additions & 24 deletions
Original file line numberDiff line numberDiff line change
@@ -519,24 +519,9 @@ class in a single library.
519519

520520
## Classes and mixins
521521

522-
**Note:** As of Dart 3.0, class modifiers (e.g., `final`, `base`, `interface`)
523-
enforce restrictions on extending and implementing classes at the language level
524-
(see [modifier reference](https://dart.dev/language/modifier-reference)).
525-
Previous guidelines advising users to "avoid extending a class that isn’t intended to be subclassed"
526-
and "avoid implementing a class that isn’t intended to be an interface" are now obsolete,
527-
as the compiler prevents misuse when API authors use these modifiers appropriately.
528-
529-
- **DO use class modifiers to control if your class can be extended**
530-
Since Dart 3.0, class modifiers like `final`, `base`, or `sealed` allow you to enforce whether
531-
- a class can be extended directly in code. For example, use `final class A {}` to prevent extension,
532-
- or `base class B {}` to allow extension only within the same library. Rely on these modifiers rather
533-
- than documentation to communicate and enforce your intent.
534-
535-
- **DO use class modifiers to control if your class can be used as an interface**
536-
With Dart 3.0’s class modifiers, you can restrict implementation using `final`, `base`, or `interface`.
537-
- For example, `final class A {}` prevents implementation, while `interface class C {}` allows it explicitly.
538-
- Use these modifiers to enforce your design intent instead of relying solely on documentation.
539-
522+
Classes. But Dart does not require all code to be defined inside a
523+
class—you can define top-level variables, constants, and functions like
524+
you can in a procedural or functional language
540525

541526
### AVOID defining a one-member abstract class when a simple function will do
542527

@@ -637,20 +622,20 @@ Otherwise, later changes to it may break your code.
637622

638623
### DO use class modifiers to control if your class can be extended
639624

640-
Since Dart 3.0, class modifiers like `final`, `base`, or `sealed`
625+
Class modifiers like `final`, `base`, or `sealed`
641626
allow you to enforce whether a class can be extended directly in code.
642627
For example, use `final class A {}` to prevent extension,
643628
or `base class B {}` to allow extension only within the same library.
644629
Rely on these modifiers rather than documentation to communicate and
645630
enforce your intent.
646631

647632

648-
### DO use class modifiers to control if your class can be used as an interface
633+
### ### DO use class modifiers to control if your class can be an interface
649634

650-
With Dart 3.0’s class modifiers, you can restrict implementation using
651-
`final`, `base`, or `interface`. For example, `final class A {}`
652-
prevents implementation, while `interface class C {}` allows it explicitly.
653-
Use these modifiers to enforce your design intent instead of relying solely
635+
you can also restrict implementation using
636+
`final`, `base`, or `interface`. For example, `final class C {}`
637+
prevents implementation, while `interface class D {}` allows it explicitly.
638+
Use these modifiers to enforce your design intent instead of relying solely
654639
on documentation.
655640

656641

0 commit comments

Comments
 (0)