[JAVA] Reading Memo "Why make it object-oriented"

Introduction

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.

This time, I will talk about "Why make it object-oriented (written by Akira Hirasawa)" (hereinafter "this book").

Table of Contents of Book (Nikkei BP Bookstore site)


Summary of 3 lines

--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.


Chapter 1 Object-oriented is a technology that facilitates software development

--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


Chapter 2 Object-oriented and real world are very different


Chapter 3 The shortcut to understanding OOP lies in the history of programming languages

--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?


Chapter 4 OOP is a programming technology that eliminates waste and keeps things organized

--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


Chapter 5 Understanding the mechanism of memory is a programmer's pleasure

--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"


Chapter 6 Reuse of software and ideas brought about by OOP

--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.


Chapter 7 Object-oriented masquerading as a general-purpose organizing technique

――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"?


Chapter 8 UML is a tool for viewing intangible software

--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.


Chapter 9 Modeling that bridges the gap between the real world and software

Recommended Posts

Reading Memo "Why make it object-oriented"
[Summary] Why make it object-oriented?
[Book Review] Why make it object-oriented, 2nd edition
[Java] Make it a constant