test
-
Upload
alex-roland -
Category
Technology
-
view
188 -
download
0
Transcript of test
![Page 1: test](https://reader036.fdocuments.in/reader036/viewer/2022082705/55b53ce7bb61eb2d558b457d/html5/thumbnails/1.jpg)
![Page 2: test](https://reader036.fdocuments.in/reader036/viewer/2022082705/55b53ce7bb61eb2d558b457d/html5/thumbnails/2.jpg)
Define?In software engineering, an anti-pattern (or
antipattern) is a design pattern that appears obvious but is ineffective or far from optimal in practice
![Page 3: test](https://reader036.fdocuments.in/reader036/viewer/2022082705/55b53ce7bb61eb2d558b457d/html5/thumbnails/3.jpg)
Project management anti-patterns Death march: Everyone knows that the project is
going to be a disaster - except the CEO. However, the truth remains hidden and the project is artificially kept alive until the Day Zero finally comes ("Big Bang").
Smoke and mirrors: Demonstrating how unimplemented functions will appear
Software bloat: Allowing successive versions of a system to demand ever more resources
Groupthink: During groupthink, members of the group avoid promoting viewpoints outside the comfort zone of consensus thinking.
![Page 4: test](https://reader036.fdocuments.in/reader036/viewer/2022082705/55b53ce7bb61eb2d558b457d/html5/thumbnails/4.jpg)
Software design anti-patterns
Abstraction inversion: Not exposing implemented functionality required by users, so that they re-implement it using higher level functions
Ambiguous viewpoint: Presenting a model (usually OOAD) without specifying its viewpoint
Big ball of mud: A system with no recognizable structure Blob: Generalization of God object from object-oriented
design Gas factory: An unnecessarily complex design Input kludge: Failing to specify and implement handling
of possibly invalid input
![Page 5: test](https://reader036.fdocuments.in/reader036/viewer/2022082705/55b53ce7bb61eb2d558b457d/html5/thumbnails/5.jpg)
Object-oriented design anti-patterns Anemic Domain Model: The use of domain model
without any business logic which is not OOP because each object should have both attributes and behaviors
BaseBean: Inheriting functionality from a utility class rather than delegating to it
Call super: Requiring subclasses to call a superclass's overridden method
Circle-ellipse problem: Subtyping variable-types on the basis of value-subtypes
Empty subclass failure: Creating a class that fails the "Empty Subclass Test" by behaving differently from a class derived from it without modifications
God object: Concentrating too many functions in a single part of the design (class)