Object-oriented Thinking-about objects (materials come from thinking in Java. These things are the same as C # and have nothing to do with language)

Since there are few good books on C #-Based Object-Oriented ideology and methods, I started to read thinking in Java 3rd to understand some object-oriented ideology and methods, write down some wonderful paragraphs (statements). For the first time, I thought about classes and objects (of course I thought about them in the original book)
The Chinese translation is translated by a netizen on the Internet. As far as I can see, the translation is quite good, so I can directly read the Chinese version. If I have any doubts, I can read the original text.

I. Five features of object-oriented architecture:

1.Everything is an object.Think of an object as a fancy variable; it stores data, but you can "make requests" to that object, asking it to perform operations on itself. in theory, you can take any conceptual component in the problem you're trying to solve (dogs, buildings, services, etc .) and represent it as an object in your program.

Everything is an object. Think of an object as a special variable. It stores data and allows you to request it to perform some operations. Theoretically, you can make the conceptual components (dogs, buildings, services, etc.) in the problem to be solvedProgram.

2.A program is a bunch of objects telling each other what to do by sending messages. To make a request of an object, you "send a message" to that object. more concretely, you can think of a message as a request to call a method that belongs to a particle object.

A program is a group of objects that send messages to each other and tell the other party what to do. You can send a request to the object. More specifically, you can think that a message is a request that calls a method of a specific object.

3.Each object has its own memory made up of other objects. Put another way, you create a new kind of object by making a package containing existing objects. Thus, you can build complexity into a program while hiding it behind the simplicity of objects.

Each object uses other objects to form its own memory. In other words, you can create a new object by dividing an existing object into a package. Therefore, you can hide the complexity of the program under the simplicity of the object.

4.Every object has a type. Using the parlance, each object isInstanceOfClass, In which "class" is synonymous with "type." The most important distinguishing characteristic of a class is "What messages can you send to it ?"

All objects have types. This statement means that any object is an instance of a class (InstanceOfClass). The class here is the meaning of type. The most prominent topic used for classification is "What messages can you send to it ?"

5.All objects of a participant type can receive the same messages. This is actually a loaded statement, as you will see later. because an object of type "circle" is also an object of type "shape," a circle is guaranteed to accept shape messages. this means you can write code that talks to shapes and automatically handle anything that fits the description of a shape. thisSubstitutabilityIs one of the powerful concepts in OOP.

All objects of the same type can receive the same message. In the future, you will know that this is a definition rather than a feature. A "circle" type object is also a "shape" type object, so ensure that the circle can accept the shape message. That is to say, what you wrote to shapeCodeIt can be automatically handed over to anything that meets the shape description. This interchangeable (Substitutability) Is one of the most powerful functions of OOP.

A more concise definition is:
Objects are stateful, behavior, and identifier.

This means that an object can be in the internal data (this gives it the State), has a method (and thus produces behavior), and each object can be separated from other objects-specifically, each object has a unique address in the memory.

2. interfaces for objects

3. The object will provide services
While you're trying to develop or understand a program design, one of the best ways to think about objects is as "service providers ."

When you develop a program or analyze the design of a program, the best way to understand objects is to treat them as "service providers ".

In a good object-oriented design, each object does one thing well, but doesn' t try to do too much.

In a well-designed object-oriented design, each object should only do one thing and do one thing well, rather than doing too many things.

Iv. Hide implementation

So the first reason for access control is to keep client programmers 'Hands off portions they shouldn't touch-parts that are necessary for the internal operation of the data type but not part of the interface that users need in order to solve their participant ular problems.

The primary reason for controlling access rights is to prohibit successful customers from touching what they should not do-what is necessary for internal operations of data types. Only allow them to access the interface necessary to solve the problem.

The second reason for access control is to allow the library designer to change the internal workings of the class without worrying about how it will affect the client programmer.

The second reason is that the class library designer is allowed to modify the internal working mode of the class without disturbing the client programmer.

(This is actually implemented by access modifiers in languages, such as public and private)

To be continued...

Note: The interface mentioned in the second point is not an interface in C #, but an interface in a broad sense. Here it actually refers to a method. For details, see the original book. I will be lazy and will not write it.