This is a personal reading memo that summarizes the knowledge gained by reading technical books. So, I will summarize it with a lot of my impressions.
Table of Contents of Book (Nikkei BP Bookstore site)
--Shows the mistakes that common discourse about object-oriented (OOP) contains and gives a more realistic explanation of OOP. ――The basic concept of OOP, its history, and basic knowledge about OOP such as how to use memory are carefully written. --The peripheral technologies surrounding OOP such as UML and design / development process are also summarized.
--Organizing the three confusions that beginners tend to --Flood of terms --Abuse of metaphor ――Anything object syndrome
The flood of terms certainly has a memory that bothered me when I first started learning. Especially words that you are not familiar with in everyday life (such as polymorphism). I wasn't aware of metaphors and object syndromes, but I think this book has clarified the boundary between the real world and the program world. Real world! = Program world
--About the history of programming languages leading up to the birth of OOP
OOP is
It can be said that it appeared inevitably in the history of ingenuity and improvement of programming languages that have continued continuously.
I'm saying that. I only recognized the difference between pre-OOP languages (C, etc.) and OOP, but I was able to understand the differences and relationships. I never thought that OOP had existed so long ago (I first learned the language Simula 67). Is the GOTO sentence bad?
--Easy-to-understand explanation of "encapsulation (" class "in this book)", "polymorphism", and "inheritance", which are said to be the characteristics of OOP.
Is the programming language degenerated?
The theory left an impression on me. Certainly, as things evolve, in a sense, "dangerous" functions will disappear (e.g.) MT of automobiles)? I found it interesting to deepen the basic knowledge about these hidden mechanisms and to use them with high functionality (applied) on the premise of these (I'm rather applied). I think).
I learned for the first time that exceptions are a relatively new concept.
Whether to save or kill OOP, it depends on the programmer's intention
--How memory is used in OOP --Garbage collection --Memory when instantiating
Memory is "static area" "heap area" "stack area" (it's soberly difficult ...) Instance variables are created for each instance, but there is only one method in memory for each class. There are also "pointers" in OOP (just getting better without the programmer being aware of it)
"Method table"
--About "design patterns" that transcend the framework of software, developed from OOP
In other words, the know-how when creating the reused parts group is extracted as a new design pattern, and it is utilized in the development of the next reused parts group.
--"Hollywood Principles" about frameworks --GoF design pattern -> It's old, but it's still valid.
I was interested in design patterns, so I decided to refer to books in the future.
――Object-oriented (idea) has become a general-purpose organization of the development process beyond software. ――Is this aspect a day for personnel who hinder the understanding of "object-oriented"?
--About UML
I used UML, but I didn't know it was so widespread and versatile (it seems that this is sometimes criticized).
In software design, "class diagram" and "sequence diagram" seem to be sufficient (I didn't understand the communication diagram well). These can also be used to express general-purpose knowledge other than software. As non-object-oriented expressions, "use case diagram", "activity diagram", and "state machine diagram" can be used. These are often used in the projects I'm working on, so I'd like to take this opportunity to become familiar with them.