This is a quick guide for people who don’t feel confident with OOP concepts yet, but want to make first steps towards improving their code using OOP principles.
If you don’t know where to start, try to look for the following patterns and apply provided recipes. Here are some problem you can find and possible solutions:
| Problem | Recipes |
|---|---|
| Code repetition: literals (numbers, string) that you use more than once | Use power of constants: remove code repetition (less literals in code), reduce typing errors, get better IDE support. Bonus: document your code by giving meaningful names to values. |
| Code repetition: expressions | Look for repeated patterns and put them into functions. Same bonuses with documenting your code. |
| Code repetition: multiple objects containing related data and functions | Think of using classes |
| Hardly readable code due to deep nesting | When you have many nested methods calls (let’s say “many” starts with three), look for ways to extract the calls into separate functions to improve readability |
| Objects, which are generally similar but different in some aspects: you have an entity with set of functionality and another entity which does the same and some more stuff | Looks like inheritance |
| You have an object which does mostly what you need, but one or more methods do not exactly what you need |
|
- Don’t put more than one task into a method. How to check: try to explain what the method is doing. If you can’t explain it without using word “and”, than you need more than one method.
- When you redefine parent class method in child class, don’t break method signature (formal parameters and return type) or what the method does. You may add parameters, but don’t change types and order of existing ones.
- Child class should do more than parent class method, but not something completely different. If you need the method to do something completely different, define new method in child class.
- Distribute logic between parent class methods and child class method, but try to avoid duplication. Child class method should do only the part that differs, not repeat parent class’s code. This would also be violation of single responsibility principle - parent class should not know or care about child class concerns.
- Encapsulate - don’t give too much access to child class method, this reduces readability
- Open-closed: you may extend base class functionality, but you may not modify it (no support in JavaScript, only by convention).
- When base class for some reason knows about possible child classes, it’s breaking encapsulation and single responsibility principle. Every inheritance layer adds more concrete data. Base class should contain data as abstract as possible
- How to decide about parameter order when designing a function or a method: put non-optional parameters first, then parameters with default value. We may design our class in such way, that parameters often changed are non-optional, and parameters rarely changed have default value.
Sometimes you may wonder if using some technic is legitimate. Here are some examples which are acceptable in most cases:
- Child class method may reduce variability of parent class method (for example, hardcode parameters). For example, you may hardcode parameter passed to parent class constructor in child class constructor of divided class.Thus class instantiation will have less parameters.
- Redefined method may change initial method’s functionality or signature (get new formal parameters), but should not do something completely different.
- Default property is a way to restrain function/method behavior
- What happens in Vegas, stays in Vegas. And what is defined in constructor, should stay in constructor. Set class members (class properties and methods) in constructor and follow the convention not to rewrite them from outside. Although anything written to instance’s
thismay be reassigned from outside, this should be avoided.