“This is the third day of my participation in the Gwen Challenge in November. Check out the details: The last Gwen Challenge in 2021.”

The bridge model

Bridge Pattern

The bridge here, in fact, is very graphic: it communicates the information between our two concepts.

In fact, the bridge pattern is complicated to talk about, but it is quite simple to explain with the following database-driven example.

  • Of course, the following database operations might normally be replaced with interfaces to achieve a greater degree of abstraction

We define an interface and a class:

Public interface database connection driver {} public class database operation {}Copy the code

What we know (and what you know now) :

  • Connect to different databases (mysql? Oracle? Or other databases), often require different connections and perform different operations.

    • So for different databases, we always need to implement different methods to accommodate this difference.

So:

  • We have too many classes if we use inheritance to connect to different databases.

Therefore, we use composition instead of inheritance here.

Let’s add a bit of description to the above interface:

Public interface Database connection {void Perform operation (); } public class mySQL connection implements database connection {//.... } public class database operation {private database connection hold connection; Public void Set connection (database connection A){this. Hold connection = a; } public Object Perform the operation (Object[] params){return this. Hold the connection. Perform the operation (); }}Copy the code

This is a simple implementation of the bridge pattern. Here we can see:

  • The bridge pattern actually hands over the corresponding operations to the corresponding objects in the class.

Such additional benefits are:

  • As long as the interface is implemented, in the example above we don’t care what database connection we are using, I just do the operation, okay

Of course, we also reduce the risk of the above quasi-explosion, but the problem here is actually:

  • Too many classes are created by mistakenly stitching together objects that are not abstract enough using inheritance

The appearance model

Appearance mode: Facede, also known as facade mode

  • Relationships with DDD: the basis of domain cohesion

In fact, the appearance pattern, the most important is to follow

Rule of composite reuse: use composition and aggregation rather than inheritance whenever possible.

Such as:

We have:

  • wrap
  • The wheel
  • The pedal
  • The chain

And so on and so forth cohesive object information.

We can combine these things into a larger concept: the bicycle

In appearance mode, the mapping for the above information content is:

Public class bicycle {handle wheel pedal chain public void ride {chain move wheel move if The car starts to sway and may fall.Copy the code

The facade pattern, which is essentially the aggregation of some cohesive domain (conceptual mapping in layman’s terms) into a larger domain or more specific business logic, has the following benefits:

  • You don’t have to break an already cohesive model
  • You can reuse previously validated logic

By describing the appearance pattern, we can see that it is one of the most widely used design patterns in programming practice:

  • In order to simplify our complex business logic, we always encapsulate some code unrelated to the business logic to reduce the complexity of the business code and the degree of coupling between different levels of code
  • And this wrapped code, we generally wrap it in related classes to make it as cohesive as possible

The flyweight pattern

The introduction of enjoy yuan mode is to solve such problems:

  • There are a large number of objects in the program, but a large part of the objects are exactly the same and unchanged.
  • So, if we keep this constant information for all of these objects, as the number of objects increases, memory will decrease the available memory due to these things, and even OOM.

The share mode solves this problem like this:

  • The abstraction of repeated information into certain objects
  • Solidify these objects (a factory save cache is a good method)
  • Objects that need this information use references to the solidified information, and memory usage is reduced.

Maybe not very well described, but here’s the most common example:

  • We commonly used network disk, is one of the applications of yuan mode

  • If it is the same as NAS:

    For each person’s file, we keep a complete file

    Then, the content of the file alone, the server is difficult to bear.

    Therefore, the common network disk strategy is:

    • Save only one file (excluding backup). The operation on the file is actually the operation on the reference to those files in the information that can be accessed by the user. This saves a lot of disk space.