At first glance the question title and first paragraph screams “too broad”. But they also contribute almost nothing to the question and could be edited away (might invalidate the answers, though).
I see some more sensible questions that could be edited into more prominence:
“Should every class implement exactly one interface?” That's not OP's main question but received one answer. I think it wouldn't be a great question and sounds opinion-based, but it's actually on-topic and answerable because there's a professional consensus on this matter.
“How should I write event handlers in C#? Should I declare this kind of interface?” On topic, and answerable iff the language's ecosystem has a clear convention. Otherwise that might still be opinion based.
“Should I dumb down my code for novice programmers, at the cost of writing less idiomatic code?” I'm not sure though if that would be on topic and objectively answerable. Opinions will usually fall in between “Yes – write for the lowest common denominator” and “No – lift your juniors to the level of the code”. With the occasional “it depends”. None of these contradictory opinions is per se invalid, I'd therefore close as too broad or too opinion based.
Asking about maintainability and best practices in general really doesn't work. This is not necessarily a problem of topicality but of answerability – Robert's comment is on point, see also my opinions below. The question is not necessarily sufficiently limited by focusing on one language and one subject matter for these best practices: as long as the question is more of a discussion prompt, it doesn't work in the Stack Exchange model.
It can be expected that questions clearly work out a focused, answerable question, and don't just present an amorphous blob of confusion. Unfortunately, writing good questions is a difficult skill. In some cases, more experienced community members can seek to clarify the question in the comments and suggest edits.
This question saw substantial discussion in the comments that did unearth helpful insights about OP's understanding, but none that could be used to improve the question. OP's real problem was that they lacked first-hand experience that would allow them to contextualize advice they read on some blog, and that they were deeply confused about maintainability. But those are not software engineering problems that could be solved by one answer on this site.
Background on figuring out whether a question is answerable.
Many good questions are answerable because they pose a concrete, real-world problem.
Here, the problem must fall within the area of Software Engineering, excluding code-level problems.
Problems have possible solutions. A solution either works or it doesn't.
- Hypothetical problems cannot be solved.
Questions generally benefit from showing attempted solutions and explaining why they fail to solve the problem.
- If the question already shows a working solution to the problem, no problem remains. In particular, asking for feedback about a particular solution is not a workable problem statement.
- I think it is fine if a question asks whether some approach will successfully solve a real problem, for example where OP lacks the professional experience to understand the implications of the approach. For example: “will this design make it easy to add new event handlers, or would a different design be better?”
It is fine if solutions are based on professional opinion or industry consensus.
Sometimes a particular sliver of the industry has a clear convention like where to put braces in a C# program, sometimes it doesn't like whether to use tabs or spaces.
If any possible “solution” is equally valid, the question is too broad or too opinion based. In particular, if the “best” solution is a matter of opinion, or if answers are likely to voice personal opinions.
- Sometimes, a great answer is able to summarize and contrast different standpoints in the context of the problem statement.
The problem must be reasonably scoped so that a solution can be described in an answer. Otherwise, it is too broad.
The problem must effectively be answerable by a mainstream professional developer. This excludes cutting edge research topics or problems that require inside knowledge to answer (like: “Why did James Gosling decide to design Java this way or that?”).
If reasonably scoped, “What is X?” or “How does X work?” can be answerable questions: the problem is in OP's understanding. However, the question must still describe a clear problem statement.
- These questions are often too broad unless OP describes their current understanding. Frequently, the issue is a misunderstanding that can be easily resolved.
- Otherwise, such questions tend to be unanswerable and require more extensive discussion, which doesn't work here.
Problem statements are usually timeless. The opposite is something like “what is the best JS frontend framework in 2019?”
To decide whether a question is on topic, I consider the typical answers it is likely to receive. This doesn't preclude that off topic questions sometimes receive great, on-topic answers.
The question discussed here received multiple such great answers, but about completely different problems. That too indicates (but does not prove) that the question is too broad.
Asking about best practices in general like “what are the best practices around X?” fails to present a solvable problem, unless there happens to be an authoritative document describing the consensus on X. For example, official styleguides sometimes cover best practices. But that is dangerously close to resource requests. In absence of such a clear answer, best practice questions are almost universally to broad because any answer that mentions a best practice would be “valid”.
As mentioned above, this can be avoided by asking whether some approach solves a problem. “Does this design adhere to best practices?” is not a problem in this sense, but “Does this design successfully enable some particular aspect of maintainability?” is.
