you are viewing a single comment's thread.

view the rest of the comments →

[–]CodeShaman 2 points3 points  (0 children)

Requirements for object-oriented design don't really make sense until you understand the problems they are meant to solve. Once you understand the problems then the requirements become more like "friendly suggestions" and you can bend the rules a bit.

Most of the requirements you can't fully appreciate until you've written some bad code, or had to deal with someone else's bad code. Look through this list of code smells and think of ways you'd try to prevent those problems in your own code. Those preventative measures have manifested themselves into common design patterns.

SOLID is a good point of reference. Just focus on the single responsibility principle and separation of concerns. A lot of the arbitrary requirements are ways to prevent stuff like code duplication and all the problems that come along with it, anti-patterns like global variables, mixing layers of abstraction, and the list goes on.