Object Orientation as I understand it (ObjectiveSql practice)

I recently participated in a project, which suddenly made me rethink "object-oriented". For a long time, "object-oriented" only existed in my subconscious, when I used Java to design a system. First, subdivide the problem domain into a set of related states and behaviors that can reasonably exist. This is my basic logic to solve the problem. Of course, there are too many ambiguous actions in the above sentence, such as: "Subdivision", "relevant state", "behavior", "reasonable", these words contain a lot of subjective ideas, the benevolent see benevolence, and the wise see wisdom.

There is a concept in economics called "blackboard economics". Economics is the study of the development laws of human society (not just economic laws). Blackboard economics usually thinks about human society with a purely theoretical thinking and algorithm. The laws of the commons, seemingly perfect, are often contrary to reality, such as: the tragedy of the commons, the logic of charity, etc. In software system design, there are also many cases, the tragedy of J2EE, the popularity of Python (network effect). Therefore, software system design should pay more attention to practical considerations. Theory can improve the height of cognition, while the actual work should be tailored to a certain extent, and practice should be used to disprove the theory.

This article is to express my understanding of object-oriented, and I have to talk about procedural programming, whose design logic is basically the same as object-oriented. Process-oriented is to decompose the problem domain into functions, and abstract related problems into modules, files, etc.; while object-oriented is to decompose into classes, and each class has methods and fields related to the class. Process-oriented emphasizes the separation of logic and data, while object-oriented emphasizes the organic combination of logic and data in the subdivided problem domain to form a reusable whole of the problem domain, so that the program can be reused continuously. The approximate problem pattern can be copied to more fields through encapsulation, which is essentially an improvement to procedural programming. Limited access to the state can effectively avoid the occurrence of low-level errors, but cannot completely solve them. In the same class, different methods will also lead to confusion of the state, waiting for the emergence of a new programming language, which can effectively avoid the appearance of low-level problems. At present, we can only rely on the wisdom of programmers, which is also the meaning of the existence of senior programmers.

I watched some videos recently, about "congestion model" and "anemia model", as well as ActiveRecord mode, etc. If you understand it from a higher perspective, "anemia model" is "struct" in C language, while congestion model It is the Class in Java. Whether it is a "struct" or a Class needs to be understood from different positions in the system. Both have reasons for their existence, but the "anemia model" will exist implicitly. My understanding is that the "anemic model" usually exists in data transmission. It is just a transmission protocol definition that can be used for data transfer between different subsystems or databases. Of course, the "anemic model" is not just set and get methods. It should encapsulate protocol-related behavior (usually these behaviors are encapsulated in other control classes), Google's ProtoBuffer is a good practice. The "congestion model" and ActiveRecord are artificial definitions. In essence, they are only the basic concepts (encapsulation of states and behaviors) in object-oriented design, and are purely manufacturing concepts.

Object-oriented topic is very big, I will briefly introduce it with the actual problem in my project.

@DomainModel
public class Order {
  private String no;
  private Integer memberId;
  private Float amount;
  private Float quantity;
  @Column(transition = SqlDateTimeTransitional.class)
  private Timestamp salesAt;
  @Relation(relationType = RelationType.BELONGS_TO)
  private Member member;
  @Relation(relationType = RelationType.HAS_MANY)
  private List<OrderLine> orderLines;
  @Transactional
  @DataSourceName("test")
  public static void makeOrder(Order order, OrderLine... orderLines) throws SQLException {
    Order.create(order, false);
    OrderLine.create(orderLines, false);
  }
}

DomainModel exists in the form of Annotation in the project, which is used to identify whether a Class is a model in the application system. The model should include the state and logic of the business, and should also describe the relationship between the model and other models. The specific explanation is as follows :

1. @DomainModel will associate the state of the model with a table in the database

2. @Column(transition = SqlDateTimeTransitional.class) defines the conversion method between the field and the database

3. @Relation(relationType = RelationType.BELONGS_TO) defines the relationship between Order and Member

4. @Transactional identifies the method's data operations will be submitted as a transaction

5. When @DataSourceName("test") is used for multiple data sources, specify the database to which the data in this method belongs

You can call the Order model ActiveRecord or the congestion model, but it is essentially a Java standard Class, which conforms to the general principles of object-oriented design, subdivides the problem domain, and then encapsulates it. Order" abstracts, designs states and behaviors, reduces the problem domain to atomic granularity, deduces from business logic concepts without ambiguity, enables the code to clearly describe logic and state, and separates purely technical code. After the above definition is completed, You can use it directly like this:

 

Member member = Member.queryByPrimaryKey(1);

List<Member> members = Member.query("id between ? and ?", 10, 20);

int count = Member.count("id > ?", 10);

For more information, please refer to: ObjectiveSql

{{o.name}}

{{m.name}}