There are absolutely no any cookbook recipes to be used to identify design problems. Perhaps except one: take the whole problem to be solved from scratch and try to sketch some best designs you can invent. If your plan looks much better than existing design, that existing design flawed. But be careful: it's easy to make a mistake due different reasons, such as: you did not understand that design, underestimated the problem, and so on.
Don't make the worse mistake one can probably make: compare design in question with some set of known
design patterns. Design patterns can be useful, but not for this purpose. Main thing to remember is:
using design patterns is not one of the goals. Yes, they can be very useful, but in real-life practice I more often see the opposite situation: they distract inexperienced designers from understanding the real development goals. Remember: people share design pattern to help you with you project, it's not that your project has the purpose of pleasing the author of a design pattern.
Now, there are many indirect signs of bad design: poor reuse, strong coupling (as opposed to
loose coupling), other issues of design
rigidity leading to problems of maintainability, and a lot more.
I would say: why analyzing some bad design? Better create a good one. People collected a lot of knowledge of bad design. Here is my idea: before you get familiar with design patterns and design in general,
learn design anti-patterns. Learn them, understand perfectly and try to avoid.
See also:
https://en.wikipedia.org/wiki/Anti-pattern#Software_design[
^],
https://en.wikipedia.org/wiki/Loose_coupling[
^] (but don't focus on just this aspect, there are many more).
—SA
Submit an article or tip