When the code is tightly coupled together and the classes are large, it attracts more code that's also coupled together and badly designed. Imagine you have the code structure we described before. A large Payment class that's not specific and has many responsibilities. It handles the processing of various payment options in this method here. Now, let's say you're asked to extend this to enable another payment option, Wwise, for instance. You'd likely do this. Extend the switch case over here with something like this, processWwise, and then you would add another function over here.

Extend the switch case over here with something like this, process, Wwise, and then you would add another function over here. Now, your code is even more complex and the Payment class has many more responsibilities that concern the Wwise payment. You didn't test this new code because there's no test coverage at all for the Payment class, and even if you'd like to test it, it's difficult because everything is so coupled together. The issues with these are potential regression bugs where existing functionality is accidentally broken due to changes in the existing code, or potential side effects even for things that the application expected but you have accidentally removed, like changed behavior introduced by changing pieces of the old code.

the application expected but you have accidentally removed, like changed behavior introduced by changing pieces of the old code. In the next videos, we'll explore better ways to add new functionality to legacy code, whether you have some time to invest in refactoring or not.