|
List Of Software Anti-patterns
Anti-patterns are commonly used ways of doing software engineering that are not useful or cause more issues than they solve. See design patterns for the opposite. There are many diverse types of software anti-patterns. Some relate to software design, object-oriented programming, computer programming, methodological, configuration management, DevOps, and other aspects of software engineering. Several books have popularized the idea and teaching of anti-patterns. Anti-patterns can be found in anything that has organization, from project management to cultures, but this list focuses solely on software and computer science anti-patterns. List of generic software design anti-patterns * Abstraction inversion * Ambiguous viewpoint * Big ball of mud * Database-as-IPC * Inner-platform effect * Input kludge * Interface bloat * Magic pushbutton * Race hazard * Stovepipe system List of object-oriented anti-patterns * Anemic domain model * Call super * Circle–ellipse proble ... [...More Info...] [...Related Items...] OR: [Wikipedia] [Google] [Baidu] |
Anti-pattern
An anti-pattern in software engineering, project management, and business processes is a common response to a recurring problem that is usually ineffective and risks being highly counterproductive. The term, coined in 1995 by computer programmer Andrew Koenig (programmer), Andrew Koenig, was inspired by the book ''Design Patterns'' (which highlights a number of design patterns in software development that its authors considered to be highly reliable and effective) and first published in his article in the ''Journal of Object-Oriented Programming''. A further paper in 1996 presented by Michael Ackroyd at the Object World West Conference also documented anti-patterns. It was, however, the 1998 book ''AntiPatterns'' that both popularized the idea and extended its scope beyond the field of software design to include software architecture and project management. Other authors have extended it further since to encompass environmental, organizational, and cultural anti-patterns. Definiti ... [...More Info...] [...Related Items...] OR: [Wikipedia] [Google] [Baidu] |
Stovepipe System
In engineering and computing, "stovepipe system" is a pejorative term for a system that has the potential to share data or functionality with other systems but which does not do so. The term evokes the image of stovepipes rising above buildings, each functioning individually. A simple example of a stovepipe system is one that implements its own user IDs and passwords, instead of relying on a common user ID and password shared with other systems. Stovepipes are A stovepipe system is generally considered an example of an anti-pattern, particularly found in legacy systems. This is due to the lack of code reuse, and resulting software brittleness due to potentially general functions only being used on limited input. However, in certain cases stovepipe systems are considered appropriate, due to benefits from vertical integration and avoiding dependency hell.''Joel on Software,''In Defense of Not-Invented-Here Syndrome, by Joel Spolsky, October 14, 2001 For example, the Microsoft Exce ... [...More Info...] [...Related Items...] OR: [Wikipedia] [Google] [Baidu] |
Action At A Distance (computer Science)
Action at a distance is an anti-pattern in computer science in which behavior in one part of a program varies wildly based on difficult or impossible to identify operations in another part of the program. The way to avoid the problems associated with action at a distance is a proper design, which avoids global variables and alters data only in a controlled and local manner, or usage of a pure functional programming style with referential transparency. The term is based on the concept of action at a distance in physics, which may refer to a process that allows objects to interact without a mediator particle such as the gluon. In particular, Albert Einstein referred to quantum nonlocality as "spooky action at a distance". Software bugs due to action at a distance may arise because a program component is doing something at the wrong time, or affecting something it should not. It is very difficult, however, to track down which component is responsible. Side effects from innoce ... [...More Info...] [...Related Items...] OR: [Wikipedia] [Google] [Baidu] |
Accidental Complexity , which often is used incorrectly where ''accidental'' or ''adventitious'' would be appropriate
{{disambiguation ...
Accidental may refer to: * Accidental (music), a symbol which changes the pitch of a note * ''Accidental'' (album), by Fred Frith * Accidental (biology), a biological phenomenon more commonly known as vagrancy * ''The Accidental'', a 2005 novel by Ali Smith * The Accidental (band), a UK folk band * Accidental property, a philosophical term See also * Accidence (or inflection), a modification of a word to express different grammatical categories * Accident (other) * Adventitious, which is closely related to "accidental" as used in philosophy and in biology * Random In common usage, randomness is the apparent or actual lack of definite pattern or predictability in information. A random sequence of events, symbols or steps often has no order and does not follow an intelligible pattern or combination. ... [...More Info...] [...Related Items...] OR: [Wikipedia] [Google] [Baidu] |
Yo-yo Problem
In software development, the yo-yo problem is an anti-pattern that occurs when a programmer has to read and understand a program whose inheritance graph is so long and complicated that the programmer has to keep flipping between many different class definitions in order to follow the control flow of the program. It is most often seen in the context of object-oriented programming. The term comes from comparing the bouncing attention of the programmer to the up-down movement of a toy yo-yo. Taenzer, Ganti, and Podar described the problem by name, explaining: "Often we get the feeling of riding a yoyo when we try to understand one of these message trees." Most practices of object-oriented programming recommend keeping the inheritance graph as shallow as possible, in part to avoid this problem. The use of composition instead of inheritance is also strongly preferred, although this still requires that a programmer keep multiple class definitions in mind at once. Deep hierarchies are ... [...More Info...] [...Related Items...] OR: [Wikipedia] [Google] [Baidu] |
Sequential Coupling
In object-oriented programming, sequential coupling (also known as temporal coupling) is a form of coupling where a class requires its methods to be called in a particular sequence. This may be an anti-pattern, depending on context. Methods whose name starts with Init, Begin, Start, etc. may indicate the existence of sequential coupling. Using a car as an analogy, if the user steps on the gas without first starting the engine, the car does not crash, fail, or throw an exception - it simply fails to accelerate. Sequential coupling can be refactored with the template method pattern to overcome the problems posed by the usage of this anti-pattern An anti-pattern in software engineering, project management, and business processes is a common response to a recurring problem that is usually ineffective and risks being highly counterproductive. The term, coined in 1995 by computer programmer An .... References {{Reflist Anti-patterns ... [...More Info...] [...Related Items...] OR: [Wikipedia] [Google] [Baidu] |
Poltergeist (computer Science)
In computer programming, a poltergeist (or gypsy wagon) is a short-lived, typically stateless object used to perform initialization or to invoke methods in another, more permanent class. It is considered an anti-pattern. The original definition is by Michael Akroyd at the 1996 Object World West Conference: A poltergeist can often be identified by its name; they are often called "manager_", "controller_", "supervisor", "start_process", etc. Sometimes, poltergeist classes are created because the programmer anticipated the need for a more complex architecture. For example, a poltergeist arises if the same method acts as both the ''client'' and ''invoker'' in a command pattern, and the programmer anticipates separating the two phases. However, this more complex architecture may actually never materialize. Poltergeists should not be confused with long-lived, state-bearing objects of a pattern such as model–view–controller, or tier-separating patterns such as business delegate p ... [...More Info...] [...Related Items...] OR: [Wikipedia] [Google] [Baidu] |
Object Orgy
In computer programming, an object orgy is a situation in which objects are insufficiently encapsulated via information hiding, allowing unrestricted access to their internals. This is a common failure (or anti-pattern) in object-oriented design or object-oriented programming, and it can lead to increased maintenance needs and problems, and even unmaintainable complexity. Consequences The results of an object orgy are mainly a loss of the benefits of encapsulation, including: * Unrestricted access makes it hard for a reader to reason about the behaviour of an object. This is because direct access to its internal state means any other part of the system can manipulate it, increasing the amount of code to examine, and creating means for future abuse. * As a consequence of the difficulty of reasoning, design by contract is effectively impossible. * If much code takes advantage of the lack of encapsulation, the result is a scarcely maintainable maze of interactions, commonly known a ... [...More Info...] [...Related Items...] OR: [Wikipedia] [Google] [Baidu] |
Object Cesspool
The object pool pattern is a software creational design pattern that uses a set of initialized objects kept ready to use – a "pool" – rather than allocating and destroying them on demand. A client of the pool will request an object from the pool and perform operations on the returned object. When the client has finished, it returns the object to the pool rather than destroying it; this can be done manually or automatically. Object pools are primarily used for performance: in some circumstances, object pools significantly improve performance. Object pools complicate object lifetime, as objects obtained from and returned to a pool are not actually created or destroyed at this time, and thus require care in implementation. Description When it is necessary to work with numerous objects that are particularly expensive to instantiate and each object is only needed for a short period of time, the performance of an entire application may be adversely affected. An object pool desi ... [...More Info...] [...Related Items...] OR: [Wikipedia] [Google] [Baidu] |
God Object
In object-oriented programming, a god object (sometimes also called an omniscient or all-knowing object) is an object that references a large number of distinct types, has too many unrelated or uncategorized methods, or some combination of both. The god object is an example of an anti-pattern and a code smell. Characteristics A common programming technique is to separate a large problem into several smaller problems (a divide and conquer strategy) and create solutions for each of them. Once the smaller problems are solved, the big problem as a whole has been solved. Therefore a given object for a small problem only needs to know about itself. Likewise, there is only one set of problems an object needs to solve: its ''own'' problems. This also follows the single-responsibility principle. In contrast, a program that employs a god object does not follow this approach. Most of such a program's overall functionality is coded into a single "all-knowing" object, which maintains ... [...More Info...] [...Related Items...] OR: [Wikipedia] [Google] [Baidu] |
Constant Interface
In the Java programming language, the constant interface pattern describes the use of an interface solely to define constants, and having classes implement that interface in order to achieve convenient syntactic access to those constants. However, since constants are very often merely an implementation detail, and the interfaces implemented by a class are part of its exported API, this practice amounts to putting implementations details into the API, which was considered inappropriate by, e.g., Java designer Joshua Bloch. In general, collecting system constants into classes independent of behaviour might create a poor object-oriented design because it is often a sign of low cohesion. For these reasons, constant interfaces may be considered an anti-pattern. Use of this pattern has a few other downsides: # It pollutes the class namespace with read-only variables that may not be of use. # Contrary to the compile-time tactical utility of implementing a constant interface, the inciden ... [...More Info...] [...Related Items...] OR: [Wikipedia] [Google] [Baidu] |
Circular Dependency
In software engineering, a circular dependency is a relation between two or more modules which either directly or indirectly depend on each other to function properly. Such modules are also known as mutually recursive. Overview Circular dependencies are natural in many domain models where certain objects of the same domain depend on each other. However, in software design, circular dependencies between larger software modules are considered an anti-pattern because of their negative effects. Despite this, such circular (or cyclic) dependencies have been found to be widespread among the source files of real-world software. Mutually recursive modules are, however, somewhat common in functional programming, where inductive and recursive definitions are often encouraged. Problems Circular dependencies can cause many unwanted effects in software programs. Most problematic from a software design point of view is the ''tight coupling'' of the mutually dependent modules which reduces o ... [...More Info...] [...Related Items...] OR: [Wikipedia] [Google] [Baidu] |