Was sind einige der häufigsten OOP-Anti-Patterns und schlechten Gewohnheiten, die Sie in Ihrem Code vermeiden oder korrigieren?

I believe the intent of OOP is to hide the data in the object. In my opinion getters pulls the data out of the object and do some logic outside the object. The object is capable of doing the logic. The concept of object has been reduced to data structure, just a bag of data and the consequences are classes like utility classes, manager classes etc.

In OOP, anemic domain model may manifest in a class generic methods. Say, a class CashRegister has a getter() and setter() to manipulate the class attribute representing dollars in the register, regcash. The behavior of getting and setting attribute data isn't unique to a CashRegister. Instead, method such as make_change() that takes two parameters price of good, dollars paid, and that calculates change and checks if regcash is greater than change. If so, it returns the change value. This would be a step in the right direction.

The way to avoid anaemic classes (domain model) is avoiding the temptation to have setter methods for all attributes. Now the way to change / mutate an object will be through methods / behaviours only.Having default constructor and using setter methods will also lead to problems of improperly initialised objects when attributes are added.

Excessive use of macros as a means of avoiding creating specialized derived classes. This leads to technical debt because the code becomes unmanageable, un-scalable and unreadable.

At the lowest level of data, this is correct. It isnt until you get higher in the architecture of the model implementation that actual methods will be abstracted enough to manipulate groups of objects, vs individual data elements.

Before we even get to the topic of the separation of concerns, consider that a god object is very hard to maintain, i.e. to extend, to debug and especially to test. Splitting it in smaller, testable units will make everyone's life easier in the long run.

God Object: Imagine you have a class that does everything in your program, like a "God" controlling everything. This is a bad practice because it violates the principle of separation of concerns. Instead, you should break down functionality into smaller, more focused classes.

A god object is a class that knows or does too much, violating principles of separation of concerns and single responsibility. Refactor into smaller, cohesive classes that collaborate through well-defined interfaces.

Class diagram, UML is excellent to designe and capture these. Principle in OOP. Just itself. It is just an starter point. I strongly recommend have a read and well understanding also to be clear that this is our tool to abstract tangible and not of everything into code well structured. Is a, has a etc. and a clear visualisation of the abstraction of reality. I believe is the best. I hope it is clear what’s my point.

For example, inheriting from a class just to reuse a small portion of its functionality, rather than representing a genuine "is-a" relationship. This can result in a complex and fragile inheritance hierarchy. Composition or interfaces can be better alternatives in such cases.

Using inheritance for code reuse rather than expressing true “is-a” relationships can lead to rigid hierarchies and violates the Liskov substitution principle. Prefer composition over inheritance and use interfaces or abstract classes to define contracts.

This one goes back WAY further than OOP. My instructors hammered this one home in my first Pascal and FORTRAN CSCI classes back in the late 1970s/early 80s.

I agree with other contributors that avoiding magic numbers and literal values isn't a OOP-specific best practice. Code needs to be written so that it can be interpreted by other developers who will contribute to or maintain the project. One of the easiest and most intuitive ways to do this is to not hardcode any values and to write descriptive meaningful variable names. Avoid naming variables "x," acronyms, or other indecipherable shorthand.

Enums and Classes! Magic strings are like if a method asked you "what's the passcode" every time you needed to pass something to it. When we specify arguments using Enums we make our code much more intentional. Beyond that, we can even make simple classes that can perform computations on its members. An example in the Unity Engine for games is that we can use the built in .StringToHash function on strings. Doing so, we can make public members which resemble the string but have a much quicker lookup time as well as no magic strings.

Literal values scattered throughout code without context or explanation make it less readable and maintainable. Replace magic numbers and strings with named constants or variables that clarify their purpose.

Classes should be akin to a curated package of functionality, rather than a warehouse for all of your code. Not only is this then impacting legibility, but testability of code. Refactoring any units of code into functions that can exist independently outside of your classes will reduce the overhead of asserting the logic is working correctly. For example, if your classes are performing steps upon initialisation, or functions have requirements on parts of it's internal state, all of this needs to be prepared for (or mocked) in your testing. While there is benefit in testing these layers, you also want to be able to test smaller units that do not depend on this complexity.

Tight Coupling: When classes have strong dependencies on each other, it becomes difficult to change or replace one class without affecting others. Loose coupling is preferred, achieved by using abstractions, interfaces, and dependency injection to reduce direct dependencies between classes.

Another one that precedes the OOP paradigm by decades. Early programming languages (FORTRAN, BASIC, I'm looking at you) had few features to encourage good programming style (most control structures were originally implemented with only IF and GOTO statements). A premium was often placed on terseness (somewhat understandable given the hardware limitations of the time). Later languages (Algol, Simula, PL1) included features making modularization and code structure easier to implement. The "structured programming" movement of the 1970s delineated how logical flow should work.

Spaghetti code refers to tangled and unstructured code that is difficult to understand, maintain, and extend. This often occurs when developers neglect proper encapsulation and modularization principles, leading to tightly coupled classes and methods with excessive dependencies. To mitigate spaghetti code, it's crucial to adhere to the principles of object-oriented design, such as encapsulation, inheritance, and polymorphism. By organizing code into cohesive and loosely coupled modules, developers can enhance readability, maintainability, and scalability, fostering a more robust and flexible codebase.

Poorly structured, formatted, and documented code that lacks organization or follows standards is termed spaghetti code. Improve readability and maintainability by adhering to coding standards, using meaningful names, and organizing code into modular components.

Code is written once but read a lot more - so optimising for readability is important. Method size is a key metric here, but there is no magic answer. Blocks of code that are too granular make a reader jump around a file and lose their flow. Equally, having one long method that does too many things violates single responsibility and makes it harder to test or reason about behaviour.

Don't use OOP just for the sake of using OOP when you are working on small projects. You don't need a samurai sword to cut vegetables, a sharp knife does the job.

Not following the SOLID principles can harm your OOP code. These principles, like Single Responsibility, Open-Closed, Liskov Substitution, Interface Segregation, and Dependency Inversion, help keep your code clean. If you ignore them, your code can become hard to work with. For example, not sticking to the Single Responsibility Principle means your classes might do too many things, making them messy and prone to errors. Ignoring the Open-Closed Principle can make your code resistant to change, meaning you'll have to keep changing existing parts instead of adding new ones. So, remember these SOLID principles to keep your code flexible and healthy as it evolves.

Encapsulation and Cohesion: Ensure classes have clear responsibilities and encapsulate related behavior and data. Composition over Inheritance: Prefer composition to build flexible and maintainable code. Clear Naming and Documentation: Use meaningful names and document code to enhance readability and understanding. Modularization: Organize code into smaller, manageable modules or classes to facilitate testing and debugging. Design Patterns: Apply design patterns where appropriate to solve common problems and promote code reusability.

One of the killer of good OOP practice is tight coupling. Classes that are highly dependent on one another can make code difficult to maintain and test. Aim for loose coupling by using dependency injection, interfaces, and design patterns like the Dependency Inversion Principle.