Differences

This shows you the differences between two versions of the page.

--- sad [2014/01/22 07:45] – yann
+++ sad [2025/01/15 21:40] (current) – external edit 127.0.0.1
@@ Line 9: / Line 9: @@
 | BaseClassKnowsDerivedClass | A class that invokes or has at least binary-class relationship pointing to one of its subclasses. |
 | BaseClassShouldBeAbstract | A class that has many subclasses without being abstract. |
-| Blob | The Blob (also called God class) corresponds to a large controller class that depends on data stored in surrounding data classes. A large class declares many fields and methods with a low cohesion. A controller class monopolises most of the processing done by a system, takes most of the decisions, and closely directs the processing of other classes. Controller classes can be identified using suspicious names such as Process, Control, Manage, System, and so on. A data class contains only data and performs no processing on these data. It is composed of highly cohesive fields and accessors. |
+| Blob | A large controller class that depends on data stored in surrounding data classes. A large class declares many fields and methods with a low cohesion. A controller class monopolises most of the processing done by a system, takes most of the decisions, and closely directs the processing of other classes. Controller classes can be identified using suspicious names such as Process, Control, Manage, System, and so on. A data class contains only data and performs no processing on these data. It is composed of highly cohesive fields and accessors. |
 | ClassDataShouldBePrivate | A class that exposes its fields, thus violating the principle of encapsulation. |
 | ComplexClass | A class that has (at least) one large and complex method, in terms of cyclomatic complexity and LOCs. |
-| FunctionalDecomposition | The Functional Decomposition antipattern may occur if experienced procedural developers with little knowledge of object-orientation implement an object-oriented system. Brown describes this antipattern as "a 'main' routine that calls numerous subroutines". The Functional Decomposition design smell consists of a main class, i.e., a class with a procedural name, such as Compute or Display, in which inheritance and polymorphism are scarcely used, that is associated with small classes, which declare many private fields and implement only a few methods. |
+| FunctionalDecomposition | A main class, i.e., a class with a procedural name, such as Compute or Display, in which inheritance and polymorphism are scarcely used, that is associated with small classes, which declare many private fields and implement only a few methods. |
 | LargeClass | A class that has grown too large in term of LOCs. |
 | LazyClass | A class that has few fields and methods. |
@@ Line 20: / Line 20: @@
 | MessageChains | A class that uses a long chain of method invocations to realise (at least) one of its functionality. |
 | RefusedParentBequest | A class that redefines inherited method using empty bodies, thus breaking polymorphism. |
-| SpaghettiCode | The Spaghetti Code is an antipattern that is characteristic of procedural thinking in object-oriented programming. Spaghetti Code is revealed by classes with no structure, declaring long methods with no parameters, and utilising global variables. Names of classes and methods may suggest procedural programming. Spaghetti Code does not exploit and prevents the use of object-orientation mechanisms, polymorphism and inheritance. |
+| SpaghettiCode | A class with no structure, declaring long methods with no parameters, and utilising global variables. The names of the class and methods may suggest procedural programming. It does not exploit and prevents the use of object-orientation mechanisms, polymorphism, and inheritance. |
 | SpeculativeGenerality | A class that is defined as abstract but that has very few children, which do not make use of its methods. |
-| SwissArmyKnife | The Swiss Army Knife refers to a tool fulfilling a wide range of needs. The Swiss Army Knife design smell is a complex class that offers a high number of services, for example, a complex class implementing a high number of interfaces. A Swiss Army Knife is different from a Blob, because it exposes a high complexity to address all foreseeable needs of a part of a system, whereas the Blob is a singleton monopolising all processing and data of a system. Thus, several Swiss Army Knives may exist in a system, for example utility classes. |
+| SwissArmyKnife | A complex class that offers a high number of services, for example, a complex class implementing a high number of interfaces. A Swiss Army Knife is different from a Blob, because it exposes a high complexity to address all foreseeable needs of a part of a system, whereas the Blob is a singleton monopolising all processing and data of a system. Thus, several Swiss Army Knives may exist in a system, for example utility classes. |
 | TraditionBreaker | A class that inherits from a large parent class but that provides little behaviour and without subclasses. |
+===== Anti-patterns Generation =====
+The generation of code and design smell identification algorithms is straightforward. Class ''sad.rule.creator.RULECreator'' expects to find rule cards, i.e., files with extensions ''.rule'' in the ''rsc'' directory of project ''SAD Rules Creator''. It provides a main method that iterates through all the rule cards and generates the corresponding identification algorithms into the ''SAD'' project. Once the generation process done, refresh and compile the ''SAD'' project and the new identification algorithms are available.
 ===== Anti-patterns Identification =====
+Identifying code and design smells using PADL is made easy by the helper class ''sad.helper.SmellsIdentifier''. After having installed CPL, PADL, and POM, just go into the ''SAD Tests'' project and have a look at this class. It provides a main method with snippets of code to call the method ''analyseIdiomLevelModel(String[], String, IIdiomLevelModel, String)'', which handles all the details. Also have a look at the constant array listing the smells that must be identified or avoided: ''SMELLS_TO_IDENTIFY''.
+SAD requires [[POM]] to compute various metrics involved in the definitions of the code and design smells. These metrics are referenced by name in the rule cards, for example:
+<code>
+RULE_CARD : ComplexClass {
+   RULE : ComplexClass { UNION LargeClassOnly ComplexClassOnly } ;
+   RULE : LargeClassOnly { (METRIC: NMD + NAD, VERY_HIGH, 0) } ;
+   RULE : ComplexClassOnly { (METRIC: McCabe, VERY_HIGH, 20) } ;
+};
+</code>