Design principles Flashcards
Can you tell me 4 main design principles?
1) Separate out the things that change from those that stay the same.
2) Program to an interface, not an implementation.
3) Prefer composition over inheritance.
4) Delegate, delegate, delegate.
What is Single Responsibility Principle?
There should never be more than one reason for a class to change.
What is Open-Closed Principle?
The open-closed principle stipulates that a class should be open for extension, but closed for modification. An extension in Ruby’s case would be adding instance variables and methods, and modification would be modifying or removing existing instance variables
or methods.
What is Liskov Substitution Principle?
The Liskov substitution principle states that any place in the code where you can use an object of type T, you can also use an object of a subtype of T. In terms of Ruby, this means that any place in your code where you are using an instance of a class, you can also use an instance of a subclass without anything breaking.
What is Interface Segregation Principle?
Many client specific interfaces are better than one general purpose interface. Because Clients shouldn’t be forced to depend on methods they do not use. ( Break down modules to many interfaces and include only what you need)
What is Dependency Inversion Principle?
Depend upon Abstractions. Do not depend upon concretions.
What is high cohesion?
The elements within the module are directly related to the functionality that module is meant to provide. High cohesion means keeping parts of a codebase that are related to each other in a single place
When we don’t need to use Single responsibility principle?
We don’t use it for String class for example.
A good question to ask yourself when deciding whether to use the single-responsibility principle to split up a class is, “Would I be able to use any of the newly split classes in additional places in my application or library?” Another good question to ask yourself is, “Do I want to be able to easily replace certain parts of this class with alternative parts?”
Would be better to add a full approach or delay complexity?
As a general principle, you should delay increasing complexity in your class designs until you actually need the complexity. It is far easier to add complexity later if needed than to remove complexity later if not needed, at least if you care about backward compatibility.
Do we always use The open-closed principle in Ruby?
The open-closed principle was written mostly to address issues with compiled
software written in programming languages that are less expressive than Ruby. In Ruby, pretty much all classes are open for both extension and modification. Ruby itself completely ignores the open-closed principle, and actively works to make sure classes aren’t closed for modification.
What general approaches do you know to fight complexity?
- The first approach is to eliminate complexity by making code simpler and more obvious.
- The second approach to complexity is to encapsulate it, so that programmers can work on a system without being exposed to all of its complexity at once. This approach is called modular design
What symptoms of complexity do you know?
- Too difficult to change. Simple change requires code modifications in many different places.
- Cognitive load. How much a developer needs to know in order to complete a task.
- Unknown unknowns: The third symptom of complexity is that it is not obvious which pieces of code must be modified to complete a task, or what information a developer must have to carry out the task successfully.
What is Information Leakage?
Information leakage occurs when the same knowledge is used in multiple places. ( something like private methods, but for several files). You shouldn’t have access to low level files inside modules from another module ( for examples to action outside the unit where action was defined )
What is the Law of Defect Probability?
The chance of introducing a defect into your program is proportional to the
size of the changes you make to it. ( Don’t touch anything if you don’t need to touch it) This law is also sometimes stated more informally as “You can’t introduce new bugs if you don’t add or modify code.”
