The first time I saw OO this concept was in a C + + book. There's an example of an animal in it. The concept of inheritance, polymorphism, etc. of animals, such as birds, mammals, insects, etc. Think of a college reading in C language inside a program logic diagram. I feel this oo is really amazing. And then contacted. NET. Start writing programs in the C # language based on the. NET platform. At first it felt pretty good, file operation. Use a system.file to fix it. To extend the functionality. Self-defining a class, the System.file function to bring over IS. Very comfortable. This feeling lasted for two months, and so on to achieve the middle of the project, more and more code. The structure of the month is more complicated. began to become frustrated. The original function remains unchanged, at the same time, to add new features to maintain the original function of the normal operation. Oh my God. I'm starting to make pasta. Solve more and more problems with more complex methods. I began to reflect on this oo. What exactly is OO concept. From the design to the present pasta. What did Oo do, and what did I do.
Design phase
OO design is a very comfortable thing, for example: two people play chess
Design a chess scene: Take the example of life is easy to see at least three objects, chessboard, chess people two people if more abstract point, on two objects, chess players and the chessboard. Do an analysis of these three objects, attribute fields, values, methods, interfaces, and so on, are not ready to write code. Very comfortable.
Compared to the structural design, it is simply too comfortable. Class player, class Player,class chessboard ... Inside to fill in what function, add method, add interface, even if your object is oriented to expand, face modification all open. It's okay. Even if you do not understand I/O, do not understand the CPU, it does not matter,. NET has a ready-made class library. Take it and make it. All right, we're done.
Pseudo code
Public Class Player:status:name,id Function:do (), Show (), UserInterface ();
Public Class Chessboard:Status:Color, Schema function:run (); HandleError ();
Is it that simple?
If we write this, we will find a lot of problems, board rules need to build an object? Does the user interface need to build an object? Or when a property, the user is using abstract class description or entity class, the chessboard? Do you use form as a user interface? FOM program and how to design? Wait a minute.....
And so we sweat the bite to finish. The next day the manager spoke. We need to add a stool to the design. That's not easy, then build a stool class, class stool. good. Who is to use the stool? Where do you put it? How does stool show it? Is it again to copy the display of the chessboard, to change a few lines of code. What if the display is replaced by a browser? Do you want to consider changing other code?
Two more days later, the manager added: We're going to have to add an air-conditioner. And to have a user interface, we also have to charge the air-conditioning function.
Oh my God. A direct breakdown. When you look at yourself writing tens of thousands of lines or even tens of thousands of lines of disgusting code. The heart that wants to die has. If you read this patiently, some of your friends will say, alas. You go and read design patterns. Your design has a problem, then ask: Is there a design pattern in the beginning to solve the extension of the problem behind? Even if you are rich in experience, design level is higher. Can you guarantee that your model will face a magical need? Just add an interface plus a property or a price object to solve the problem?