This shows you the differences between two versions of the page.
sad [2014/01/22 07:34] yann |
sad [2018/03/04 02:53] |
||
---|---|---|---|
Line 1: | Line 1: | ||
- | ====== SAD ====== | ||
- | |||
- | SAD stands for Software Architectural Defects and is our implementation of DETEX, following the DECOR method to specify and identify occurrences of anti-patterns in PADL models. A paper introducing DETEX and DECOR has been published by [[http://www.ptidej.net/publications/Author/MOHA-N.php|Moha, Guéhéneuc, Duchien, and Le Meur]] and can be used as reference. | ||
- | |||
- | ===== Anti-patterns Definition ===== | ||
- | |||
- | ^ Names ^ Definitions ^ | ||
- | | AntiSingleton | TBD | | ||
- | | BaseClassKnowsDerivedClass | TBD | | ||
- | | BaseClassShouldBeAbstract | TBD | | ||
- | | 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. | | ||
- | | ClassDataShouldBePrivate | TBD | | ||
- | | ComplexClass | TBD | | ||
- | | 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. | | ||
- | | LargeClass | TBD | | ||
- | | LazyClass | TBD | | ||
- | | LongMethod | TBD | | ||
- | | LongParameterList | TBD | | ||
- | | ManyFieldAttributesButNotComplex | TBD | | ||
- | | MessageChains | TBD | | ||
- | | RefusedParentBequest | TBD | | ||
- | | 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. | | ||
- | | SpeculativeGenerality | TBD | | ||
- | | 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. | | ||
- | | TraditionBreaker | TBD | | ||
- | |||
- | ===== Anti-patterns Identification ===== | ||