Object-oriented design learned from "Thorough capture Java SE 11 Silver problem collection"

Preface

I will be involved in a Java project at the site where I am currently participating. However, despite my 15th year as an engineer, I have only dealt with technologies around .NET, so this is my first Java project. Therefore, in order to learn the basic knowledge of Java on a zero basis, I decided to start learning with the goal of acquiring Java SE 11 Silver / Gold.

To start learning, I bought Thorough Strategy Java SE 11 Silver Problem Collection (so-called "Kuromoto").

Since the explanation of the answer is written very carefully, I felt that it was the best teaching material not only for exam preparation but also for learning basic knowledge, but in the book I said "Reference (not directly related to exam preparation) However, I paid attention to the part that says "It is useful information to know)".

Even in the "reference" section, there are some descriptions that are very important, especially if you are going to dig deeper into "object-oriented" in the future, so I will summarize them in this article.

From P51: Immutable object

This is from the explanation of the problem related to the String object in "Chapter 2 Basic Java Data Types and String Operations". An example implementation of an "immutable object" is provided to prevent improper data modification. This is essential knowledge for implementing "Value Object" in DDD (Domain Driven Design).

Reference: Bombing a low-aggregation class with a ValueObject that has tightly packed design requirements

From P203: The more arguments, the harder it is to use the method

From the answer to the question about the number of arguments defined in the calling method and method declaration in Chapter 6, Instances and Methods.

Reference information such as is described.

A concrete example I've seen recently Introduction to Domain Driven Design Bottom-up! Basics of Domain Driven Design I think the "command object" strategy, which defines the object "~ Command" that has an argument as a field in the sample code of, is a very easy-to-understand example.

Example of "~ Command" object that has an argument as a field

https://github.com/nrslib/itddd/blob/master/Layered/SnsApplication/Users/Get/UserGetCommand.cs

Example method to call "~ Command" object

https://github.com/nrslib/itddd/blob/master/Layered/WebApplication/Controllers/UserController.cs#L36

In this sample code, the return value is also summarized as a "~ Result" object, so the design is simple and resistant to changes, which is also helpful.

From P220: Encapsulation

This is from the explanation of the problem regarding the concept of encapsulation in "Chapter 6 Instances and Methods". The problem here is, "The code is presented and I want to apply encapsulation to it. Choose the best code from the following." Therefore, knowledge about "encapsulation" is indispensable for exam preparation, but it seems to be the same knowledge for object-oriented programming. Encapsulation is explained as follows.

Encapsulation is a "class for what" by combining related data and the processing that requires that data into one when dividing the software, and excluding irrelevant and irrelevant ones from the class. It is done to clarify the purpose of the class "Is it?", And aims at a state where there is no duplicate data or processing in other classes.

The Value Object mentioned above is just one of the methods to achieve "encapsulation". Then, in order to implement the "encapsulated" object, "data hiding", in Java, the fields in the object are qualified (hidden) with private, and the method using the value of the field is made public (public). , Etc. are also described.

From P244: "Inheritance" is no longer used

From the explanation of the problem of class inheritance in "Chapter 7 Class Inheritance, Interfaces, Abstract Classes". Class inheritance is essential knowledge in object-oriented languages,

Recently, it has been pointed out that the use of inheritance is more likely to reduce maintainability.

It is described as. The following post explains in an easy-to-understand manner what happens if you try to inherit easily.

Your inheritance is used incorrectly

Does the system you maintain also have a "God / base class" that implements many common processes such as "AbstractController" and "AbstractService"?

Implementation methods may be more hurdles than inheritance, but if you want to use inheritance, it may be the best practice of modern object-oriented design to consider "transfer" or "synthesis".

[What I learned after fighting object-oriented for 10 years] (https://qiita.com/tutinoco/items/6952b01e5fc38914ec4e)

From p259: Liskov Substitution Principle

From the explanation of the problem of method overriding in "Chapter 7 Class Inheritance, Interfaces, Abstract Classes". For reference, the principle that "subclasses must be replaceable with superclasses" and "Liskov Substitution Principle (LSV)" are introduced. There are many other principles in object orientation, and it is recommended that you study these principles well for better design. Typical examples of these principles are the five principles, the so-called "SOLID Principle", including the "Liskov Substitution Principle".

The following posts explain the SOLID principle with code examples in an easy-to-understand manner.

A brief description of the SOLID principle

From P283: Design pattern and Strategy pattern

This is from the explanation of the problem regarding the basic declaration method of lambda expressions in "Chapter 8 Functional Interface, Lambda Expressions". The code itself of this question is a realization of the Strategy pattern using a lambda expression, from which the introduction of the GoF design pattern and the explanation of the Strategy pattern are described.

Speaking of Java and design patterns, it's already a 15-year-old publication. Introduction to Design Patterns Learned in Java Language I remembered. At that time, I wasn't dealing with Java, but the implementation examples of design patterns were posted with sample code, which was a great learning experience. Highly rated reviews have been posted on Amazon's reviews over the last 1-2 years, so it seems that they are still rated as masterpieces.

Summary

The above is a summary of the "Thorough Strategy Java SE 11 Silver Problem Collection" as a supplement for learning more about object-oriented design from the "reference" information. We hope that Java and programming beginners (or even veterans?) Who have read this workbook will have a chance to come to this article and learn more about object-oriented programming.

Recommended Posts

Object-oriented design learned from "Thorough capture Java SE 11 Silver problem collection"
Significance of interface learned from Java Collection
Passed Java SE8 Silver
[java] Java SE 8 Silver Note
What you learned when you acquired Java SE 8 Silver and Gold
[Experience] Passed Java SE 8 Silver
Java SE8 Silver Pass Experience
How to study Java Silver SE 8
Object-oriented programming learned from Dragon Ball
[Note] Java Silver SE8 qualification acquired
Road to Java SE 11 Silver acquisition
What I learned with Java Silver
Diary for Java SE 8 Silver qualification
[Qualification] Java Silver SE11 Passing Experience