AntiPattern

Question 1

Anemic Domain Model

Answer 1

Refers to a design flaw in OOP where domain objects(objects repsrenting real-world concepts or entities) lack behavior or business logic and serve primarily as data containers.
In an Anemic DOmain Model, most of the behavior and business logic is implemented in separate service or utility classes rathern than encapsulated with the domain objects themselves

Question 2

Spaghetti Code

Answer 2

Is characterized by tangled and poorly stuctutured logic, often resulting from ad-hoc development w/o proper planning or design. It leads to convoluted control flow, making the code difficult to read, debug, and maintain.

Question 2

Anemic Domain Model Solution

Answer 2

Domain objects should encapsulate both data and behavior related to a specific domain concept, allowing them to enforce business rules and invariants internally. By focusing on rich domain models that encapsulate behavior, developers can create more expressive, maintainable, and reusable codebases that accurately represent the complexities of the domain they are modeling.

Question 3

Spaghetti Code Solution

Answer 3

Apply modular design principles and refactor the codebase to break it into smaller, more manageable modulesor components. Adopt design patterns such as MVC (Model-View-Controller) or MVP (Model-View-Presenter) to organize the code and separate concerns effectively.

Question 4

Copy-Paste Programming

Answer 4

Involves duplicating code instead of abstracting common fuctionaloty into reusable components.
It leads to code, redundancy, inconsistency, and increased maintenance overhead

Question 5

Copy-Paste Programming Solution

Answer 5

Identify duplicated code and refactor it into reusable functions, methods, or classes. Encourage code reuse by extracting common functionality into libraries or shared components. Maintain a codebase that adheres to the DRY (Don’t Repeat Yourself) principle

Question 6

Magic Numbers

Answer 6

Magic Numbers are hard-coded numerical values scattered throughout the codebase w/o explanation. They lack clarity and make the code difficult to understand and maintain.

Question 7

Magic Numbers Solution

Answer 7

Replace magic numbers with named constants or configuration parameters to improve code readability and maintainability. Use descriptive names for constants that convey their purpose and context within the code

Question 8

Constant Interface

Answer 8

The Constant Interface Antipattern is a design flaw in object-oriented programming where an interface is used solely to declare a set of constant variables instead of using a class to define constants. Interfaces in Java are meant to declare a contract for behavior, not for defining constants.
Using interfaces for constants misuses their intended purpose and can confuse developers who expect interfaces to define behavior.

Question 9

Constant Interface Solution

Answer 9

One commonly recommended solution is to use a “static” class with a private constructor to encapsulate the constants. Another approach is to leverage enums for defining constants, especially when the constants represent a finite set of related values. By adopting these solutions, developers can mitigate the issues associated with the Constant Interface Antipattern and create more maintainable and readable codebases that adhere to best practices in object- oriented design

Question 11

Dead Code

Answer 11

Refers to unreferenced or unreachable portions of the database that no longer serve a purpose. It clutters the database, increases its size, and can confuse the developer

Question 12

Dead Code Solution

Answer 12

Conduct regular code reviews and static code analysis to identify and remove dead code. Utilize version control systems to track changes and detect unused code. Ensure that developers are aware of the importance of maintaining a clean codebase

Question 13

Feature Creep

Answer 13

Occurs when new features are continuously added to a software project w/o proper prioritization or consideration of their impact.
It leads to bloated software w. Unnecessary complexity, longer development cycles, and increased maintenance costs.

Question 14

Feature Creep Solution

Answer 14

Conduct regular code reviews and static code analysis to identify and remove dead code. Utilize version control systems to track changes and detect unused code. Ensure that developers are aware of the importance of maintaining a clean codebase

Question 15

Golden Hammer

Answer 15

Occurs when developers over-rely on a familiar or preferred technology or tool for solving every problem, regardless of its suitability. It can lead to suboptimal solutions, missed opportunities, and resistance to adopting better alternatives.

Question 16

Golden Hammer Solution

Answer 16

Encourage a diverse toolkit and evaluate technologies based on their suitability for the problem at hand.Foster a culture of learning and experimentation to explore new technologies and approaches. Conduct regular technology evaluations and be open to adopting better alternatives

Question 17

Circular Dependency

Answer 17

Arises when 2 or more modules or components depend on each other directly or indirectly.
It creates tight coupling b/w components, making the codebase difficult to understand, test, and maintain.

Question 18

Circular Dependency Solution

Answer 18

Break circular dependencies by refactoring the codebase to introduce interfaces or abstract dependencies. Utilize dependency injection or inversion of control to decouple modules and promote modularity. Establish clear architectural guidelines to prevent the emergence of circular dependencies.

Question 19

Big Ball of Mud

Answer 19

Is a Large, sprawling and unstructured codebase lacking clear architecture or design.
It accumulates technical debt and complexity over time w/o proper planning or refactoring.

Question 20

Big Ball of Mud Solution

Answer 20

Introduce architectural patterns such as layered architecture or microservices to promote modular design and separation of concerns. Refactor the codebase incrementally, focusing on extracting cohesive modules and enforcing architectural boundaries.

Question 21

Reinventing the Wheel

Answer 21

Occurs when developer attempt to solve problems that already have existing, effective solutions.
It leads to wasted time and resources, increased complexity, and inferior implementations.

Question 22

Reinventing the Wheel Solution

Answer 22

Encourage developers to research existing solutions before attempting to build their own. Maintain a curated list of libraries, frameworks, and best practices that address common problems. Foster collaboration and knowledge sharing within the development team to leverage existing expertise.

Question 23

Not Invented Here (NIH)

Answer 23

The NIH antipattern refers to the tendency of developers to reject existing solutions or libraries in favor of building their own from scratch.
While reinventing the wheel is about solving problems that already have solutions, NIH is more about refusing to use those solutions due to a lack of trust or a desire for control.
It can lead to wasted time and resources, as well as inferior implementation.

Question 24

Not Invented Here Solution

Answer 24

Foster a culture of openness to external solutions and encourage developers to evaluate existing libraries, frameworks, and tools before considering building custom solutions. Establish criteria for evaluating third-party dependencies based on factors such as community support, documentation, and compatibility with existing systems.

Question 25

Overengineering

Answer 25

Occurs when developers add unnecessary complexity or features to a system beyond what is required for its current needs. This can lead to bloated meeting current requirements and anticipating future needs w/o overrcomplicationg the solution

Question 26

Overengineering Solution

Answer 26

Emphasize simplicity and focus on meeting the current requirements without adding unnecessary complexity. Conduct regular design reviews to identify overengineered components and refactor them to simplify the design. Prioritize features based on their value and avoid speculative or premature optimization.

Question 27

Single Point of Failure (SPoF)

Answer 27

SPoF refers to a design flaw where a system component relies on a single point that, if it fails, can cause the entire system to fail.
It could be a critical server, network component, or dependency. Lack of redundancy or failover mechanisms increases the risk of system downtown and data loss.

Question 28

Single Point of Failure (SPoF) Solution

Answer 28

Design the system w. Redundancy and failover mechanism to eliminate single points of failure. Utilize load balancing, replication, and clustering techniques to distributes workload and increase fault tolerance. Implement health checks and monitoring to detct and mitigate failures proactively.

Question 29

Feature Envy

Answer 29

Occurs when a method or function in one class excessively access the data or method of another class, rather than relying on its own data and behavior.
This violates the principles of encapsulation and can lead to tight coupling b/w classes, making the code harder to maintain and refactor.

Question 30

Feature Envy Solution

Answer 30

Refactor the code to move methods or functionality closer to the data they operate on, adhering to principles of encapsulation and cohesion. Use techniques such as method extraction or introducing intermediary objects to eliminate feature envy and promote better object-oriented design.

Question 31

Concurrency Issues

Answer 31

Arises when multiple threads or processes access shared resources concurrently w/o proper synchronization or coordination.
This can leads to race condition, deadlocks, and data corruption.

Question 32

Lava Flow

Answer 32

Refers to obsolete or redundant code that is retained in the codebase because developers are reluctant to remove it, fearing it might break something. This can result in cluttered code, increased maintenance effort, and confusion for new developers.

Question 33

Concurrency Issue Solution

Answer 33

Apply synchronization mechanisms such as locks, semaphores, or monitors to coordinate access to shared resources and prevent race conditions. Utilize thread-safe data structures and libraries to minimize the risk of data corruption. Design concurrent system w. Clear boundaries and minimize share mutable state.

Question 34

Code Smells

Answer 34

Are subjective indications of potential problems in the codebase, such as long methods, large classes, or excessive comments.
While not necessarily antipatterns themselves, code smells often signal areas that may benefit from refactoring or further investigation to improve code quality and maintainability.

Question 35

Lava Flow Solution

Answer 35

Conduct regular code reviews and refactoring sessions to identify and remove obsolete or redundant code. Utilize version control systems to track changes and identify code that hasn’t been touched or referenced in a long time. Establish policies for code cleanup and removal of unused features

Question 36

Code Smells Solution

Answer 36

Educate developers on common code smells and their implications for code quality and maintainability. Conduct regular code reviews to identify and address code smells early in the development process. Utilize automated code analysis tools to detect and flag potential code smells in the codebase

Question 37

Hardcoding Configuration

Answer 37

Hardcoding configuration settings, such as database connection strings of API endpoints, directly into the codebase makes in inflexible and difficult to manage across different environment.

Question 38

Hardcoding Configuration Solution

Answer 38

Externalize configuration settings using configuration files, environment variables, or configuration management tools. Utilize configuration frameworks or libraries to manage configuration dynamically and support different environments. Follow the principle of separating configuration from code to promote flexibility and maintainability

Question 39

Cargo Cult Programming

Answer 39

Cargo Cult programming refers to the practice to blindly following certain coding practice or patterns w.o understanding their underlying principles or rationale.
Developers may mimic code snippets or design patterns w.o considering whether they are appropriate for the problem at hand.
It can leads to suboptimal solutions and hinder the development or critical thinking and problem-solving skills.

Question 40

Cargo Cult Programming Solution

Answer 40

Encourage developers to understand the underlying principles and rationale behind coding practices or design patterns before applying them. Foster a culture of learning and knowledge sharing within the development team. Conduct code reviews and pair programming sessions to promote understanding and critical thinking

Question 41

Analysis Paralysis

Answer 41

Occurs when developers spend an excessive amount of time analyzing and planning w.o making progress on actual development tasks.
It stems from a fear of making the wrong decisions or a desire for perfection.
This delays project timelines, increases costs, and may result in missed opportunities

Question 42

Analysis Paralysis Solution

Answer 42

Break down development tasks into smaller, manageable units and set time-boxed deadlines for decision-making. Emphasize rapid prototyping and experimentation to validate assumptions and gather feedback early in the development process. Adopt agile methodologies such as Scrum or Kanban to promote iterative development and continuous delivery.

Question 43

Boat Anchor

Answer 43

Refers to obsolete or outdates components, frameworks, or technologies that are retained in a project despite no longer serving a useful purpose.
They add unnecessary complexity, increase maintenance overhead, and hinder innovation.

Question 44

Boat Anchor Solution

Answer 44

Conduct regular technology audits to identify obsolete or redundant components in the system. Prioritize the removal or replacement of boat anchors based on their impact on the project and the availability of alternative solutions. Establish policies for sunsetting or decommissioning technologies that no longer provide value

Question 45

Parallel Inheritance

Answer 45

Occurs when the class hierarchy in an object-oriented system mirrors the hierarchy of another aspect of the system, such as database schema of file schema or file structure.
This leads to tight coupling b/w different parts of the system and increases the complexity of maintenance and evolution.
Decoupling the class hierarchy from other system structures improve flexibility and maintainability

Question 46

Parallel Inheritance Solution

Answer 46

Decouple the class hierarchy from other system structures by using composition over inheritance where appropriate. Apply design patterns such as Strategy or Bridge to separate the concerns of inheritance and system structure. Refactor the codebase to eliminate tight coupling between class hierarchies and other system elements.

Question 47

Stovepipe System

Answer 47

Is characterized by isolated and independent components or subsystems that lack integration and communication mechanisms.
This leads to duplication of functionality, inconsistent data, and difficulties in sharing information b//w different parts of the system.

Question 48

Stovepipe System Solution

Answer 48

Integrate isolated subsystems through well-defined interfaces and communication channels. Implement integration patterns such as ESB (Enterprise Service Bus) or event-driven architecture to facilitate data exchange and communication between subsystems. Foster collaboration between teams responsible for different subsystems to promote shared understanding and alignment

Question 49

Swiss Army Knife

Answer 49

Occurs when a software component of module is designed to be overly general-purpose and flexible, trying to accommodate various use cases and requirements.
This results in bloated code, increased complexity, and decreased performance.

Question 50

Swiss Army Knife Solution

Answer 50

Refactor the overly general-purpose component into smaller, specialized components with clear responsibilities. Follow the single responsibility principle (SRP) to identify and extract cohesive functionality into separate modules or services. Utilize dependency injection or modular design patterns to compose functionality from smaller, reusable components.

Question 51

Vendor Lock-in

Answer 51

Occurs when a software project becomes heavily dependent on proprietary technologies, frameworks, or services from a specific vendor.
This limit flexibility, increases costs, and reduces the ability to switch to alternative solutions

Question 52

Vendor Lock-in Solution

Answer 52

Adopt open standards and interoperable technologies to minimize dependencies on proprietary solutions. Utilize abstraction layers or adapter patterns to encapsulate vendor-specific functionality and facilitate switching to alternative providers. Negotiate contract terms with vendors to ensure flexibility and portability of the solution.