¿Cómo se modifican las clases y los objetos existentes?

I disagree with a blanket "No" to inheritance/polymorphism. I think, like everything, encountering issues here can be a symptom of misuse. I believe the mantra is "composition over inheritance" rather than "inheritance is bad" because inheritance/polymorphism were never meant to be their/its own standalone design model, hence being a part of OOD. Without properly applying the rest of the paradigm, for example isolation, single-responsibility, separation of concerns, etc, you end up with a tightly coupled, hot mess. Maybe the better questions are: Is OOD too complex for whatever the current definition of "engineer" is? Is expecting architecture from a generalist (engineer) vs a specialist (architect) appropriate?

No! Once you get past a few levels of inheritance/polymorphism, this is a support nightmare and a breeding ground for defects.

In my experience, inheritance is one of the features of object-oriented languages that is most often misused. It's very convenient to inherit, but this comes at the cost of tight coupling between the classes in the hierarchy. As always – context is king. For example, if I were building a framework, I would provide its clients with an interface allowing them to conveniently inherit the public classes. Inside the framework implementation, however, I would prefer composition to achieve greater flexibility.

Inheritance can lead to tight coupling and inheritance hierarchies that are difficult to maintain and extend, particularly in complex systems. Instead, employing a protocol-oriented approach allows for greater flexibility and modularity by defining behavior through protocols and conforming types. Composition, on the other hand, promotes code reuse by assembling objects with different behaviors rather than relying on class hierarchies, resulting in more scalable and adaptable codebases. Overall, while inheritance has its place, leveraging protocols and composition can often lead to cleaner, more maintainable code in intricate scenarios.

"If all you have is a hammer, everything looks like a nail," a concept often associated with Abraham Maslow. A few general lessons I've learned while creating games with the C# language: Use interfaces (contracts) to define how objects should be interacted with. This adds clarity to the required properties and methods an object must have for effective communication. Prefer composition over inheritance to extend behaviors. Remember, the relationship between objects can be "has" as well as "is." Explore the functional programming paradigm. Even if you don't fully adopt it, understanding functional programming can provide a broader perspective and new approaches to problem-solving.

The most common code smells leading to violations of the Open-Closed Principle: - Switch statements: Unless you are absolutely sure you’re not going to add new case statements to a switch, this could pose problems. To address this, use the Strategy design pattern. - Creating dependencies inside a class: This practice not only violates the Open-Closed Principle but also several others. To address this, apply Abstract Factory and Factory Method.

The Open/Closed Principle (OCP) states that classes should be open for extension but closed for modification. This means that you should be able to extend the behaviour of a class without changing its existing source code.You can top up it functionality but not change the existing. To modify existing classes and objects while adhering to the Open/Closed Principle, you typically use techniques such as inheritance, composition, and polymorphism. This promotes code stability, reusability, and maintainability.

I often find engineers don't delete enough code. I think it is a very useful skill set to learn to remove unused and unneeded code during refactors.

Refactoring does to code what Yoga does to your body: it increases both its lifespan and quality. And if done regularly it reduces the software development and maintenance costs in the long term. Less time to build new features, less time to market. And totally selfish reason: It enhances the developers programming skills... and it's gold.

Refactoring is the process of restructuring existing code without changing its external behaviour. When modifying existing classes and objects using refactoring techniques, you aim to improve the design, readability, and maintainability of the code. You can "Extract Method" Identify a cohesive piece of functionality within a method and move it to its own method. You can "Extract Class" Identify a subset of properties and methods within a class that can be logically grouped together. Identify code where behaviour varies based on conditional statements. Refactor this code to use polymorphism instead, by defining a hierarchy of classes or interfaces.

SOLID is like a cookbook for OOP and OOD. Following it ensures doing things right: writing a structured, maintainable, scalable, and flexible code.

A simple tip: Paste SOLID principles sheet on your desk. And before committing your code check if you are following all of them... and trust me in the beginning it will force you to write good code and later writing good will become your habit.

Unit test cases are kind of a pre-requisite to refactor the code. Without unit test cases in place refactoring the code may break it unpredictable ways and build an experience in the team that refactoring is risky. Hence, the product may doom earlier than expected.

Make sure your code is tested before modifying it. If no tests are available, write them. Tests give you confidence that your new code does not break existing functionality.

Consider using the tools provided by your programming language. You could augment a class's functionality without changing its internal structure, employing methods that go beyond traditional polymorphism or inheritance: - Many languages support modifying classes dynamically at runtime. - Some languages offer special syntax for class extension (such as Mixins in Ruby, and extensions in Objective-C, Swift, and Kotlin), allowing for the addition of new features without direct inheritance.