The first of the SOLID principles is unfortunately violated quite often even though it is easy to understand why you want to maintain a separation of concerns. It is similar to the SQL injection vulnerabilities that show up on StackOverflow and other places even though the internet is flooded with warnings about how to avoid being pwnd by the easily escapable beast.
In the example repository, I give the example of a basketball player that is both a coach and a player. While there are several examples in NBA history of successful player coaches, none have won coach of the year and only two have won championships as player-coaches.
Since we are pursuing excellence, why would split our focus by being both a player and a coach? There are several examples of player-coaches going back to focusing on their playing career since it is very difficult to be great as both.
In warfare, it is a maxim to divide your enemies forces so that they cannot focus their strength. Thus it is so with player-coaches. They are at best a jack of all trades that has to deal with the politics of leading a team as well as the dynamics of winning basketball games on the court.
We should keep these principles in mind when we are designing objects and their interrelations. How does it make sense to have a player object that is also a coach object? As you can see from the example repository, the responsibilities that the PlayerCoach object takes on are contradictory in nature and would be confusing when utilized in code.
To sum up, don’t have your objects be a PlayerCoach. Have multiple objects: player and coach that can leverage their individual capabilities to their fullest.
To see if you are violating this principle, try extracting all of the interfaces that you can for a given class and see if they make sense to be utilized in the same class. Just make sure that your interfaces (or contracts) conform to the Interface Segregation Principle (ISP).