term1 Definition1term2 Definition2term3 Definition3
Please sign in to your Google account to access your documents:
Design principles
- SOLID
- DRY
- KISS
- YAGNI
- Worse is better
- convention over configuration
- separation of concerns
- principle of least knowledge
- tourist principle
- single source of truth
- single version of the truth
SOLID
Single responsibility principle
a class should have only a single responsibility (i.e. only one potential change in the software's specification should be able to affect the specification of the class)
Open/closed principle
“software entities … should be open for extension, but closed for modification.”
Liskov substitution principle
“objects in a program should be replaceable with instances of their subtypes without altering the correctness of that program.” See also design by contract.
Interface segregation principle
“many client-specific interfaces are better than one general-purpose interface.”
Dependency inversion principle
one should “depend upon abstractions, [not] concretions."
DRY: don't repeat yourself
KISS: keep it simple, stupid
YAGNI: "You aren't gonna need it", i.e. don't implement until needed.
Worse is better: It is the idea that quality does not necessarily increase with functionality—that there is a point where less functionality ("worse") is a preferable option ("better") in terms of practicality and usability. Software that is limited, but simple to use, may be more appealing to the user and market than the reverse.
convention over config: The phrase essentially means a developer only needs to specify unconventional aspects of the application. For example, if there is a class Sales in the model, the corresponding table in the database is called "sales" by default. It is only if one deviates from this convention, such as calling the table "product sales", that one needs to write code regarding these names.
separation of concerns: a design principle for separating a computer program into distinct sections, such that each section addresses a separate concern, e.g. HTML vs CSS vs JS
principle of least knowledge
- Each unit should have only limited knowledge about other units: only units "closely" related to the current unit.
- Each unit should only talk to its friends; don't talk to strangers.
- Only talk to your immediate friends.
Drawbacks of not using separation of concerns?
Adding new features will take an order of magnitude longer
Impossible to optimize
Extremely difficult to test
Fixing and debugging can be a nightmare (fixing something in one place can lead to something else breaking that seems completely unrelated).
Describe microservices and their pros
a style of software architecture that involves delivering systems as a set of very small, granular, independent collaborating services.
Pros: The services are easy to replace, Services can be implemented using different programming languages, databases, hardware and software environment, depending on what fits best
Need help typing ? See our FAQ (opens in new window)
Please sign in to create this set. We'll bring you back here when you are done.
Discard Changes Sign in
Please sign in to add to folders.
Sign in
Don't have an account? Sign Up »
You have created 2 folders. Please upgrade to Cram Premium to create hundreds of folders!