Best Practices for Class Declarations
Applies To: Microsoft Dynamics AX 2012 R3, Microsoft Dynamics AX 2012 R2, Microsoft Dynamics AX 2012 Feature Pack, Microsoft Dynamics AX 2012
Prefix: Module short name, for example InventUpdate.
Infix: Logical description of action performed or type of contents, for example InventUpdate.
Follow the general Naming Conventions.
Avoid naming classes that are the basis for a subsystem hierarchy with a Base suffix if the class is intended for use in public APIs. This practice follows the design guidelines for the .NET Framework. For more information, see Base Classes for Implementing Abstractions.
If you try to create a class with a name that has already been used for a class in the previous version of Microsoft Dynamics AX, you will get an error.
Class Declaration Layout
[public] [final] class ClassName [extends SuperClassName] [implements interface1[, interface2 ..]]
Object Member Variables
Object member variables are variables in the class declaration. Create them only if the variable cannot be created in a method. Object member variables must be the variables holding the state of the object.
Do not create object member variables that do not hold the state of the object. Pass these values as arguments.
Do not create an object member only because a variable of that type and name is needed in more than one method in the object. Create the variable in each place it is needed.
Clean Up Unused Variables
Clean up unused variables in your class declaration. Right-click the class in the application object tree (AOT) and choose Add-Ins > Check Best Practices.
If you have to declare some constants that will be used in more than one method in the class or its subclasses, declare these constants in the class declaration (by using the #define technique).
Best Practices for Constructors
Best Practice for Destructors (finalize)
Announcements: New book: "Inside Microsoft Dynamics AX 2012 R3" now available. Get your copy at the MS Press Store.