​

This is the third day of my participation in the August More Text Challenge

rendering

​

What are design patterns

What are design patterns? Design patterns are a set of repeatedly used, widely known, cataloged experiences of elite code designers

Why use design patterns? Design patterns are used to make code reusable (with little or no modification to solve new problems), reduce rework, make code easier to understand, and ensure code reliability.

Design pattern is a kind of middle layer surface in the process of programming skills or experiences (micro level such as algorithms, data structure, grammar, macro level such as framework, toolbox, system architecture), many good programmers is summed up by a large number of actual project hone advocates “secrets”, by studying their efficient methods, sums up the experience of skills, Then when we encounter a specific problem, it is easier to come up with a good and reasonable solution.

What is a Singleton?

What is a Singleton? In short, there can be only one (or none) instance of a Singleton class during the execution of a program. The singleton pattern is a very useful design pattern for managing classes or classes that have only one instance in a program. The CEO of a company, for example, can be a singleton. And a practical example, such as resource management class in the game, we may need to access it at any time, but every time don’t want the image to create a new a resource management class instances (avoid frequently create destruction to the effects of performance), then the singleton pattern is a good solution.

Processing is different from the Java implementation

Processing has some special features that make it more important to note than using Java directly to implement the singleton pattern:

The default class declared in PDE is an inner class and cannot have static fields. To implement the singleton pattern, you need to create a top-level class. To do this, we first add a new label. When asked to name it, remember that the name of the TAB is important!! The name of the class must be followed by ‘.java’, for example using SimpleImagemanager.java

​

Add the following code to the SimpleImagemanager.java TAB

import processing.core.*; import java.io.File; import java.io.IOException; import java.util.ArrayList; import java.util.List; public class SimpleImageManager { private static PApplet app; private static SimpleImageManager instance; Private ArrayList<PImage> imgs = new ArrayList<PImage>(); // @note private constructor, Private SimpleImageManager() {} private SimpleImageManager() {} public SimpleImageManager() { GetInstance (PApplet papp) {/// @note Create an instance if (instance == null) {instance = new SimpleImageManager(); app = papp; } // @note returns the created instance. } public void draw() {// @note for (int I = 0; i < imgs.size(); i++) { app.image(imgs.get(i), i * 171, 0); Public void loadImages(String path) {File dir = new File(path); If (dir.exists() && dir.isdirectory ()) {system.out.println (" Directory exists! ); File[] files = dir.listFiles(); for (File f : files) { String filepath = path + f.getName(); // System.out.println(filepath); //< test PImage img; img = app.loadImage(filepath); img.resize(171, 256); /// < scale each image imgs.add(img); }} else {system.out.println (" Directory does not exist!") ); }}}Copy the code

The code for calling pDE is

The call here is also very simple, is to do an instance variable is the same judgment and draw

SimpleImageManager inst, inst_; void setup() { size(1200, 256); background(255); First create an instance / / / @ note inst. = SimpleImageManager getInstance (this); inst.loadImages("/Users/lingyunpan/Documents/Processing/projects/Images/"); Mac directory under / / / / / < / @ note again for instance simulation inst_ = SimpleImageManager. GetInstance (this); /// @test if(inst == inst_){println("inst and inst_ are the same instance variable." ); } // @note uses inst_ to draw, instead of reloading the image inst_.draw(); //< window size limit, maximum 7 display}Copy the code

The end result is shown at the beginning of the article.

Design patterns fall into three categories

1. Creation: Provides object creation mechanisms to increase flexibility and reuse of existing code.

  • Single case model
  • The prototype pattern
  • Factory method pattern
  • Abstract Factory pattern
  • Builder model

2. Structural: Explain how objects and classes can be assembled into a larger structure while keeping the structure flexible and efficient

  • Adapter mode
  • The bridge model
  • Decorative pattern
  • The appearance model
  • The proxy pattern
  • The flyweight pattern
  • Portfolio model

3. Behavioral: Responsible for effective communication and the allocation of responsibilities between objects.

  • Template method pattern
  • The strategy pattern
  • Command mode
  • Chain of Responsibility model
  • The state pattern
  • Observer model
  • The mediator pattern
  • Iterator pattern
  • Visitor pattern
  • Memo mode
  • Interpreter mode

Finally, a concise summary of the seven principles of object orientation is provided

1. Single Responsibility Principle (SRP)

There is one and only one reason when a class needs to be modified. In other words, let a class do only one type of responsibility, and when that class needs to take on other types of responsibility, it needs to be broken up.

Example: You can’t expect a programmer to write programs and hire. If you need to hire new employees, it’s better to hire an HR or headhunter.

2. Open-closed Principle (OCP)

Software entities should be extensible, not modifiable. That is, open for extension and closed for modification.

Example: there is a class called programmer. You can derive C++ programmer, Java programmer, C# programmer, C# programmer who knows PS, and programmer who doesn’t like to write comments. This is the open principle. But you can’t expect all programmers to know C++, Java, C#, PS and C#, and not like to write comments. That’s the closed principle.

3, Dependence Inversion Principle (DIP)

High-level modules should not depend on low-level modules; both should depend on abstractions. Abstraction should not depend on details, details should depend on abstractions.

E.g. The top of a company should not rely on lower-level programmers to fire whenever they want or hire another one. . The profession of programmer should not be dependent on a particular programming language, but knowing a certain programming language makes you a programmer.

4. Interface Segregation Principle (ISP)

Users cannot be forced to rely on interfaces they do not use. In other words, it is better to have multiple specialized interfaces than a single master interface.

Example: Don’t call a server programmer when discussing UI.

5. Liskov Substitution Principle (LSP)

Wherever a base class can appear, a subclass must appear.

Example: Every employee needs to clock out, so do programmers. If you see someone who doesn’t clock out, it’s probably the boss.

Composite Reuse Principle (CRP)

Use composition/aggregation whenever possible and avoid inheritance whenever possible.

E.g. When building a new team, if you first bring in all the people from the old team and then hire as needed, not all of them may have something to do.

7. Principle of Minimum Knowledge (Law of Demeter, LoD)

That is, one object should know as little as possible about other objects.

Example: As a designer (or PM), you don’t need to know how the program is implemented, you just need to ask for requirements. “Top line: this demand is very simple, bottom line: how to achieve I don’t care, hengpi: tomorrow online.”

​