Some notes on object oriented software development.
A use case describes what your system does to accomplish a particular customer goal. It is a technique for capturing potential requirements of a new system or software change.
Usually the nouns in a use case will become classes, but not every noun will be a class. Some nouns may be external agents, and thus not need a class.
A condition or capability that must be met or possessed by a system to satisfy a contract, standard, specification, or other formally imposed document.
These questions help one determine to which parts of the system one should dedicate more attention on the initial stages of the development process.
Development should always aim to reduce the risk of a project succeeding. The question you need to be always asking yourself is “Will this reduce the risk to my project succeeding?” If the answer is negative, you probably can leave the task for a later stage of the project.
This principle states that software entities should be open for extension, but closed for modification.
This is about having each piece of information and behavior in your system in a single, sensible place. This is not just about removing duplication; it is also about making good decisions about how to break up the functionality of a system.
Each object should have a single responsibility and all its services should be focused on carrying out that single responsibility.
Subtypes should be substitutable for their base types.
A good design helps one to maintain speed in software development. Refactoring thus sometimes helps one develop software faster, because it keeps the quality of the design of the system.
A good advantage of refactoring away technical debt in a gradual manner, only changing the parts of the codebase that you have to touch for some reason, is that the investment made in modernizing and cleaning up code is only thrown into regions which have to potential to actually pay it off.
Designers of object-oriented systems should avoid class proliferation. Such proliferation creates management problems and hinders software reusability, because it is difficult to locate the most appropriate classes in a huge library. The alternative is to create fewer classes that provide more substantial functionality, but such classes might prove cumbersome to read and understand.