Various people have written articles about GoF design patterns, and I am always studying. However, on the other hand, those articles are aimed at high-level people such as "There are such merits by designing this class" and "The conventional method has such problems", those who can share the premise to some extent. I got the impression that it was an article for, and in the first place, beginners like me do not understand, "I can write like this because of the language specifications", "If you design a class like this, the program will work like this" I don't think I can find an article that focuses on "what can be done first".
So, this time, I used Design patterns learned in Java language as a theme, and first designed from the viewpoint of "Java can do this because of language specifications". Let's look at the pattern.
It may be off the topic, but since the subject matter dealt with here is basically Java, it can already be specified in other languages (for example, Python's __iter__), or conversely it cannot or can be done in other languages. Even so, I will give an example of something that can only be done with a fairly elaborate writing style (for example, dependency injection in c ++?). With that in mind, there is no longer a design pattern common to all languages, and there may be design patterns for each language. However, I'm not so familiar with various programs, and I don't have the skills to discuss design patterns in other languages, so I won't go into this article in depth, but just say, "This is what Java's language specifications do. I will just introduce "I can do it".
That's a long introduction, but let's get started.
The variables handled in the GoF design pattern can be roughly divided into the following three types. In addition, the advantages and disadvantages of each are considered to be as follows.
| variable | How to use | merit | デmerit |
|---|---|---|---|
| Integer type (int,boolean etc.) | 8 | 8 | 8 |
| Official class or basic type （double,String etc.) |
5 | 6 | 3 |
| Self-made class | 2 | 3 | 3 |
There are four ways to handle variables within a method: The range that can be handled and the points to be noted when handling each are described. Regarding the points to note, I feel that it deviates from the main subject of the article, but on the other hand, I feel that the merits of the design pattern will not be visible unless I understand the features, so I will post it for the time being.
| Variable type | Handleable range | important point |
|---|---|---|
| Local variables | In the method | This is the most recommended usage, but on the other hand, if you dynamically allocate a large class with new every time, the calculation cost may increase, so please consult with the performance. |
| Member variables | Within individual instances （ staticIf you add, all classes will be shared) |
It's a global variable whose access is limited, so don't create it unnecessarily. Never reuse counter variables. |
| argument | Function user side | Try not to change the state in the function as much as possible (if attached)const修飾子を付ける）．また，複数ステータスを持つような大きなクラスをargumentにするのはなるべくやめましょう． |
| Return value | Function user side | As with the arguments, don't return them in a very large class. |
| Modifier | Modifiable | How to use |
|---|---|---|
| static | Member variables/function | 2 |
| public | Member variables/function | 2 |
| plivate | Member variables/function | 2 |
| protected | Member variables/function | 2 |
| @Override | Member function | 2 |
| abstract | Member function | Ah |
| final | Member function | Ah |
| Modifier | Insertion position | How to use |
|---|---|---|
| extends | After class declaration | This is a modifier for inheriting the class following extends. is-Let's be aware of the relationship of a. Only one class can be inherited. |
| abstract | Before class declaration | This is a modifier that prevents you from creating an instance of a class with abstract. You can inherit this without it, but add it if necessary to reduce mistakes. |
| final | Before class declaration | Classes with final cannot be inherited. It's okay if you don't add this either, but let's add it to the very final class that you don't want to overwrite. |
| implements | After class declaration | A qualifier for implementing interface. can-Be aware of the do relationship. Unlike extends, multiple interfaces can be implemented (multiple inheritance). |
| inteface | Instead of class declaration | Actually, it is not a class modifier, but it is arranged well, so here. It is a type that can be written instead of class and can only define methods. The difference from the abstract class is that you cannot define member variables. |
baseA.java
public class baseA {
public void func() {}
}
A.java
public class A extends baseA {
public void func() {System.out.println("A");}
}
A_.java
public class A_ extends baseA {
public void func() {System.out.println("A_");}
}
Main.java
public class Main {
public static void main(String[] args) {
baseA a;
a = new A();
a.func();
baseA a_;
a_= new A_();
a_.func();
}
}
Execution result
A
A_
Comment out the func implemented in the previous baseA.
baseA.java
public class baseA {
//public void func() {}
}
Then, this will compile, but
OK.java
A a;
a.func();
This will result in a compilation error.
NG.java
baseA a;
a = new A();
a.func();
I'm sorry, I posted a draft that was in the process of being created due to an operation error. After checking, it seems that once posted, it cannot be drafted again, so I will complete the article as soon as possible. Until then, it will be a mess for everyone, but thank you for your cooperation.