** Review conducted **
Since one year has passed, I updated it so that the explanation is as polite as possible without changing the essence of the content.
Twenty years have passed since the object orientation by Java started. I think it can be said that it has penetrated in the system development field. That said, the Java language itself is clear, but I'm sure many people aren't quite clear about object-orientation. In the first place, object-oriented programming was to grasp the world of the problem domain from the viewpoint of "things" and let those "things" send messages to each other to operate the system. It's easy to understand if it's a visible object, but it became ambiguous when it came to a conceptual or abstract object, which contributed to the confusion. In addition, the fact that the explanations and introductions were often different from the actual objects also increased ambiguity and difficulty in understanding, and was confusing. And the explanation of sending a message to make it work was more realistic than the expression of calling and using it. So, I would like to look back and understand object-oriented programming based on the progress so far. Please note that the following description may be based on personal subjectivity. Please refer to the brief explanation in the tail part for the words and phrases specific to object-oriented programming used in the text.
Since object-oriented programming is based on human perceptions and ideas (concepts), it is not possible to determine a clear correct answer. If you do not fully understand this premise, you will be in a situation where you cannot make various decisions. In conclusion, object-oriented programming was simply one of the methods for organizing, classifying, and structuring data groups and operation groups (processing groups). Well, it's just organizing, classifying, and composing.
I would like to explain the basics of object-oriented programming (what it was) with an example. (For those who are now, you can pass within the range of ☆ from here to ☆ to here ☆.) --- ☆ From here ☆ --- There are many on the net, but for the sake of clarity, I will explain here based on a simple example. An example is creating a magnificent dish, with the following steps:
If you think carefully about item 4, you may have some issues and questions. (1) How do you collect materials (data) and tools (operations)? This is determined by analyzing a large number of recipes and determining what ingredients and tools are needed. I created a rearranging box in advance, gave it a name that shows what I put in, and wrote it down. I'll put a label on it. (2) How many organizing boxes do you make? This is the kind of thing that the cook checks the things around him and listens to the opinions of other cooks. I will decide by trying to organize. If there are too many, it will be difficult to classify, and if there are too few, it will not be possible to classify properly. Also, basically one cooking (one type) is handled by one organizing box. (3) Which rearranging box should I put in? This is natural, ・ Which organizing box should I put this item (materials and tools) in? ・ Since I have made several boxes of the same type, should I store them in a chest of drawers? Such a thing is assumed as an issue. Naturally, the way of organizing differs between groups and cooks. Of course, it is a matter of course to decide the definition that this thing is always put in this rearranging box among cooking people all over Japan. can not. Is it like this as a cook? Isn't it a realistic way to organize things by compromising on that level? However, it is troublesome and useless when a chef who gives a lecture and imposes a detailed arrangement method comes out. Time will be wasted. After all, it's a technique of organizing. It's decided that it's better to get rid of it and start cooking before it's messed up is. (4) What are the judgments and criteria for putting them in the rearranging box? Put tools that are closely related to the material in the same box. You can put multiple materials and tools. You may put more organizers in the organizer. You may put a request form for another sorting box in the sorting box. (5) How to organize and cook? The chef will organize and cook. The chef cooks using the ingredients and tools in the organizer. If you need to cook ingredients with slightly different attributes, use the tools in another organizing box inside. It is also possible to use it. And finally, the finished dish is completed. We will do this in groups to complete a magnificent dish. --- ☆ Up to here ☆ ---
(6) To summarize Putting the words back together, object-oriented is -Identify necessary data groups and operation groups (processing groups) from experience, knowledge, documents, etc. -Organize, classify, and structure data groups and operation groups (processing groups). ・ For organizing, classifying, and structuring, data (materials) and operations (tools) closely related to the defined class (organization box) are used. Assign and carry out. That was all.
In the above explanation, one of the differences from the development methods (and programs) up to that point is that a class is created. I would like to explain a little about this class (organization box). A class is a basic unit (organization box) in a Java program that contains related data groups (materials) and operation groups (tools). To give an example, for example, if you think about a box (class) called "spaghetti", Peperoncino, meat sauce, bolognese, pescatore, arabiata, Amatriciana, Carbonara, Alfred, Genovese, Trapanese, Napolitan, cod roe spaghetti, mentaiko spaghetti, ... You can put in materials and tools related to spaghetti. You may want to put separate boxes such as oil sauce, tomato sauce, cream sauce, and basil sauce in the spaghetti box. If it is an oil sauce, put Peperoncino, if it is a tomato sauce, put meat sauce, Bolognese ingredients and tools in a sorting box by type. And be aware that "spaghetti" is not always in class. Considering the class of "food", it is possible to judge that spaghetti is a material (data). In addition, Peperoncino is not a material (data), but may become a rearranging box (class) considering toppings. In other words, the organization and classification will differ depending on what kind of problem is viewed from what point of view. Of course, it depends on the person. Therefore, no matter what class you define, it cannot be evaluated as correct by everyone, and it is always ambiguous. This part is a source of relatively discrepancies in judgment and recognition, and becomes a cause of confusion as many people are involved. It is not possible to determine which is the correct answer, so if there is no mistake, it is better to proceed to the next. And you should avoid creating extensibility-friendly classes that aren't specifically required. The ambiguity just increases.
I think I was able to grasp the outline of object-oriented programming. Next, I would like to shift my perspective to that feature and deepen my understanding. Object-oriented features include instantiation and the three principles (encapsulation, inheritance and polymorphism). Due to these features (1) Support for simultaneous multiple processing by materializing / embodying (instantiating) from a concept (class). (2) Organize the same implementation contents in one place without describing them in multiple places. (3) Conceal the real instance (object) as much as possible to enhance its independence. It is said that can be realized.
(** About instantiation **) So first of all, why do you need to instantiate? To put it simply, instantiation means creating a copy clone of a class and setting values for member variables. Instantiation is commonly done when using a multithreaded environment (simultaneous multiple processing) or inheritance / polymorphism. Inheritance and polymorphism will be described later, and first, instantiation in a multithreaded environment and an in-thread environment will be described below. In a multi-thread environment, the same processing (data is different) may be performed at the same time, so class is materialized / embodied (instantiated), and the same type object containing different data is generated and processed for each thread. Is common. This method allows each thread to process the data of interest quickly and appropriately. However, instantiation is not always required in a multithreaded environment, and there is no need for instantiation if the existence of a class is sufficient. In fact, libraries and the like do not require significant partial instantiation using static methods.
On the other hand, there may be multiple instantiated objects of the same class in the same thread at the same time. As a typical example, you may want to perform some processing using the object data for each object (generally line by row) generated based on the search results. Example: Calculate the total amount for each sales item. In this case, it is natural that the higher sales class may be used as long as the total amount is calculated. In other words, the necessity of creating the corresponding multiple objects is not always essential. There are two types of such objects, user classes and collections (List, Map, etc.), and user classes include the original one that includes the actual processing method and the one that does not (Bean, DTO: DataTransferObject, VO, etc.). : ValueObject) There are two types. From the viewpoint of which type to use, in the case of processing that changes the state of sales detail data (DB) (changes the value), it is still better to perform processing in the sales detail class (user class). Is the right perspective. In other words, if there is data to be retained (not temporary data) and there is a process to change its value, it is better to process it with the user class that retains the data (create such a class). Should be). However, classes like collections, beans, DTOs and VOs may be fine (less need for encapsulation) if there is no special care to change that value. Also, in the case where the search result is returned as a character string list, it is better to pass the character string list (collection) without re-entering the object group.
From the above, it can be said that it is possible (effective) to design a user class as a whole, instantiate it, and process it in multiple simultaneous processes, but it is not always essential including the in-thread environment, and it is flexible. It means that we should deal with. In other words, it is an instance of the most basic functions in object-oriented programming (including OOP), but considering the current situation, it seems that there is no need for it as much as the catchphrase at that time. However, I think that the characteristics of instantiation contributed to some extent in persuading the necessity and validity of object-oriented programming.
(** About the three principles **)
Next, I would like to explain the three principles of encapsulation, inheritance and polymorphism.
First, I will explain each term.
Next, I would like to evaluate and explain the perspective of whether these three principles are actually useful based on my experience. (1) Make the program more independent and concise by utilizing these three principles. I think it is certain that you can do it. (2) These three principles are more effective, especially in the development of basic functions (framework and common function equivalent parts). It seems to be. (3) Smooth development from the flow of object-oriented analysis / design organization / classification to implementation It can be said that it is a mechanism that can wait. (4) Set up to the extent necessary using a mechanism like the three principles without being bound by the word object-oriented It seems that it is realistic and effective to measure and implement. (5) However, these mechanisms are used more than necessary to complicate the design and program structure. Please note that productivity may decrease. As mentioned above, these three principles are not just Java object-oriented, they can be practiced in many other development environments.
Finally, I would like to explain the comparison with the module that was sometimes talked about. Basically, I don't think that what you can do (process) with "object" cannot be done with "function" / "module". Of course, it is a prerequisite that the program length, memory length, processing speed, etc. are not taken into consideration. One of the characteristics of "objects" is that they can exist more than once at the same time, but on the other hand, "functions" and "modules" cannot have more than one at the same time. However, this can also be practically possible with "functions" and "modules" if a function that can realize multiple processes is incorporated. In terms of catchphrase, I think it's a tone that says "... can be realized relatively easily in an object-oriented manner" rather than "... can be realized because it is object-oriented." I think the slightly sharp catchphrase was also the cause of the confusion.
After the above explanation, was object-oriented really necessary? Personally, it seems that object-oriented programming had few new features without alternatives at the basic level, and I don't think it was essential from this point of view, but it is effective and produced by its appearance. I think it can be said that there was a certain effect on improving productivity and quality. Therefore, it seems that a certain effect can be expected as long as it is adopted while paying attention to the precautions when using it described later.
At that time, I often heard that object-oriented development failed. So what did you mean by object-oriented development in the first place? And what went bankrupt as a result of what they did? Did it fail because it adopted the Java language? The Java language is still at the forefront of the field, and I don't think there was anything fatal. I suspect that most of the general causes in system development were. The causes of failure (in terms of cost, deadline, quality) are as follows (from the perspective of the contractor / developer). ・ I have not made a proper estimate. I easily lowered the price to receive an order. He focused on price and downplayed real-life perspectives such as experience, technology, and structure. ・ Low ability to determine specifications ・ Low authority to determine specifications. In development, a large number of specifications must be decided flexibly. Since the ability and authority of the ordering party and the development side were too low, it was not possible to make appropriate judgments and decisions. won. ・ Low communication skills Communication between the ordering side and the development side, the inside of the ordering side, and the inside of the developer side is poor. Anyway, he has a strong attitude to avoid responsibility and pass on work and responsibility to others. ・ Low willingness to succeed. The ordering side and the development side have a weak intention to succeed anyway. This tendency is especially true when there are many time workers (because employees of other companies are not responsible). Become stronger. ・ Inexperienced. The number of experienced people who need development platform technology, languages, middleware, etc. is small. Many members have no knowledge of domains. I think that there is a possibility that the word "failure" can be used in an object-oriented manner only after clearing these. So what are the causes of object-oriented failures? ・ Spend a lot of time discussing object-oriented programming rather than the original specifications in analysis and design. I was sorry. · Spend a lot of time creating object-oriented documentation in analysis and design I was waiting. ・ Since the class granularity is unnecessarily small and the structure is complicated and deep, it takes time to develop. It was hungry. ・ There were many members who had almost never experienced OOP in the first place. ・ I tried to practice a development methodology with little experience. Is it such a place? It seems that such a thing was not essential and could be avoided relatively easily. As mentioned above, the discussion for object orientation should have been kept to a minimum, and a lot of time should have been spent on the original specification. I should have thought that unnecessarily dependent or biased object-oriented programming is not good for cost performance.
Next, I would like to look back on the development methodology from the perspective of failure. As is the case today, development methodologies were being proposed at that time. These various development methodologies became a hot topic and were recognized as one with object-oriented programming, which also contributed to the confusion about object-oriented programming. Mainly, it was a proposal to change from the conventional waterfall type to the iteration type (including agile type). So, it's not that the iteration type has become the mainstream now, but the basics are still the waterfall type. It seems that this mixed development methodology confusion also contributed to the story of object-oriented failure. I think it was necessary to treat object-oriented programming and development methodologies separately. I think many engineers and customers made a great contribution to software vendors during this period (laughs).
So what should we do with the documentation? Documents specific to object orientation include: Conceptual model diagram, use case diagram, use case description, package diagram, analysis class diagram, Analysis sequence diagram, design class diagram, design sequence diagram, design activity diagram, etc. There is no doubt that it is doubtful from the viewpoint of cost performance to create such a document in a lawful manner. It may not be possible to write in the first place in large-scale development. The performance of recent UML diagram creation tools has improved, but I think it is difficult to draw diagrams on large-scale systems. It would be appropriate to aim for document creation that can describe the necessary items in an appropriate amount, can be used effectively, can easily respond to changes, does not require new tools, and can be used as a deliverable. However, in the development of basic common functions (application-level framework that is not middleware), it seems effective to create class diagrams as temporary documents. It is certain that it is advantageous in terms of time and change to organize object-oriented documents in Excel table format instead of figure-based documents such as UML. Moreover, I think it has the advantage of being able to accurately instruct the necessary content.
The initial screen should be created with HTML or a screen design tool, etc., and then a prototype should be created and confirmed without mounting, including screen transitions, before the mounting process, and used in the mounting process.
One of the reasons for object-oriented development was that "it is because we can respond flexibly to changes" was explained more like that at that time. The changes were called hotspots. Of course, it will be possible to meet this requirement if the whole is implemented consciously by OOP. However, if you think about it, change estimates are everywhere in the program, with millions and tens of millions of steps. If you introduce a criterion that is "highly likely to change", you will run into the theme of how to clarify and embody that criterion. Another issue is who decides whether it is high or low and who has the cost. If there is a prospect that the operation work can be outsourced, it may be possible to take some risks in the development work, but in recent years such a form has become rare.
In addition, it is useless and unrealistic to make an unreasonable OOP by guessing without clarifying what kind of change will occur. Therefore, in order to respond to changes, it is necessary to take steps such as clarifying and determining the change specifications, designing, programming, and testing in advance. In other words, we have to build a mechanism that can respond to changes. I recognize that it is not so much that object-oriented features exert great productivity and importance in this mechanism construction part. Overall, it's not much different from other development methods and means. After all, as mentioned above, it is better to specify it in the requirement specifications and realize it in an environment where the cost and period can be recorded.
I have described what I came up with by looking back on the past, but finally, from the results of these reflections, I have listed the points to be aware of when practicing object-oriented programming in the future. Please refer to it.
·concept A concept is a word that means "characteristics that are common to all things." When there are multiple things that have common properties, they are regarded as the same type due to the common points. Image formed by. Example: Cat concept (cat image), car concept (car image), etc. From a different point of view of classification, it can be said to be a higher classification. ·override Refers to redefining a method defined in a parent class in a child class. ·Overload Methods with the same method name but different argument types, numbers, and order in the same class Refers to defining multiple.