"Why make it object-oriented, 2nd edition" https://www.amazon.co.jp/%E3%82%AA%E3%83%96%E3%82%B8%E3%82%A7%E3%82%AF%E3%83%88%E6%8C%87%E5%90%91%E3%81%A7%E3%81%AA%E3%81%9C%E3%81%A4%E3%81%8F%E3%82%8B%E3%81%AE%E3%81%8B-%E7%AC%AC2%E7%89%88-%E5%B9%B3%E6%BE%A4-%E7%AB%A0/dp/4822284654)
An introductory book about object-oriented (OOP). I think the introductory book is for people who are actually writing programs for work or hobbies.
As a feature of the introductory book that explains OOP, ・ Animals are superclass, dogs are subclasses, and pochi is an instance. ・ Means to express reality as it is in software While there are many books that emphasize the explanation that emphasizes ease of access in such parables, this book is __ "OOP doesn't reflect all the reality, it's one of the ways to get a PC to take over part of the job" __ __ "The mechanism of the program and the way of thinking (general-purpose organization) to incorporate the real world into the program are different" __ I am calmly explaining OOP with such a stance.
In the first half, while touching on the history of transition from machine language → assembly language → high-level language → structured language and the limits of large-scale development with them, It describes the points that compensated for the weaknesses that could not be covered by structured programming by the "reused parts group" creation function such as class library and framework by OOP. The specific role of that function is -Combine variables and subroutines __ -Hide them so that they can be used only inside the class __ -Create multiple instances from one class __ It is expressed as.
In the middle part, one chapter was devoted to the mechanism of memory and instance in OOP, and the static area, heap area, stack area, etc. were explained in an easy-to-understand manner. After that, it was written about the reuse of parts and ideas brought about by OOP, here. ・ Class library ·Framework ·component ・ Design pattern Was explained. Up to this point, the explanation was relatively close to the "program", but from this point on, business analysis and requirement definition It will be a story that is conscious of the connection between "upstream process" and OOP. Because ・ Classification ・ Polymorphism ・ Inheritance This is because even if this idea can be applied to program design, it cannot be applied to the real world as it is. So set theory was used as a way to successfully connect the real world and the software world (I did it in high school mathematics). This is because the relationship between a class and an instance is a set and an element. Also, although the OOP class and set theory are strictly different, the flow that was naturally applied is also short. The next chapter provides an overview of UML as a way to represent real-world organization and software in two dimensions.
At the end of the game, the increased hardware capabilities extend the life of the application. The structure definition of the entire software is explained with the point that maintainability and reusability have become important. For that purpose, it is necessary to compose with highly independent parts due to the strong degree of condensation and the weak degree of coupling. It is written that two techniques are required: the rearranging technique in the upstream process and the programming technique in the downstream process. So far, OOP has been written, In the next chapter, the transition of the development environment surrounding OOP is described. Beginning with waterfall development, iterative development processes (typically RUP and XP) were born. Promote a similar development method with the latter property by naming it agile development. Such as history. And as a practical method to promote them, ・ Test-driven development ・ Refactoring ・ CI Seems to have been improved and spread.
Finally, I will introduce a few buzzwordized technologies such as aspect-oriented (AOP), agent-oriented, and service-oriented as technologies that come after OOP, and an overview and basic explanation of functional languages that have been attracting attention in recent years. Was introduced.
The author repeatedly says in the book that "software is not a direct reflection of the real world." It may be that many people have the image of "reflecting the real world as it is", and I strongly felt the insistence that we should be careful about misunderstandings.
Along the way, there was a chapter explaining memory and instances, but I personally found it very easy to understand, and I thought it was a good starting point for a little deeper research.
I used to hear from my seniors that "object-oriented programming is set theory". At that time, the pin didn't come that far. However, the explanation of this book that "every object in the world has become an object to be organized into classes and instances by set theory, and object orientation has evolved into epistemology and philosophy" is easy to understand, __ set theory. I'm wondering if __ is the point to put __real world __ into the mechanism of __object-oriented programming __.
On the other hand, regarding UML and upstream processes after the middle stage, it may not come to that point unless you have actually done it. The same is true for the final chapter on functional languages. vice versa When I read it after doing it lightly, I felt that it fell into my mind. So, I think it's a good book as an opportunity for people who have touched it as a job to look back and step into a deeper world from a superficial understanding. However, the level is easy to read even for beginners, and it does not necessarily mean that you cannot understand it until you enter the upstream process. I felt a good balance.
Also, although it is useful for learning about historical transitions and concepts as a reading material for the first time, it is not a how-to book that specifically describes programming and how to write UML.