Revolutionizing the traditional-object-oriented design ideas (Continued chapter)

Since the publication of "subvert traditional-object-oriented design ideas (collation)", many of my friends and comments have been posted, either good or bad. Of course, there are also many friends in Article In the comments, I posted my own opinions. Here I will explain some typical comments.

• From wanghualiang
  Comment

I really admire the poster's divergent thinking. However, it is far from revolutionizing the tradition.
Here I will talk about my point of view,
Is there a problem in describing the characteristics of an object from an interface.
Whether a fish can be eaten must be identified as one of its attributes,
Class fish
{
Public   Bool Iseatable;
}
When the customer wants to eat this fish, iseatable = True ; If it is a puffer fish, it is false.
Of course, there are many uncertain factors between what you can eat and what you can't eat. Then we should
[Flags]
Enum eattype
{

Deliciouseate,//Delicious
Distasteful,
Barbed,
..
}

Class fish
{
PublicEattype;
}

I think wanghualiang's comments represent the views of a considerable number of friends. From the traditional Object-oriented Thinking (or general acceptance), there is no problem in doing so, it has even been written into many object-oriented textbooks as a demo. But in fact, this is a problem. At least I personally think so. The first question we need to consider is: can the fish decide whether they can eat or whether they can eat well? It should not be possible to decide whether the fish can be eaten. Whether it is good or not should be the object of the fish, right. Maybe from the perspective of ordinary people, the puffer fish cannot be eaten, but from the perspective of talented chefs or senior elders, it is extremely delicious, this is why I added an image at the end of the chapter to focus on object behavior.
After all, since the fish cannot decide whether to eat or not, that is to say, the behavior that the fish cannot eat is not determined by the fish, some people may ask why to implement the ieatable interface, isn't it the same as making an attribute directly? This is a very good question. Since fish cannot decide whether they can eat or not, why does fish implement the ieatable interface. Actually, implementing the ieatable interface on fish is completely For ease of use and interface level (this issue will be discussed later) The fully object-oriented method should be to have another object to identify whether the fish can eat or not (this is also based on the design balance, you can refer to the open-closed principle ). There is basically no difference between using interfaces and attributes in this place, but once the identification methods (implementation methods) for determining whether or not a fish can eat or not, attributes cannot be extended. You can only modify them. Code But the advantage of using interfaces is that I can use other methods to remedy it. For example, I am doing a decoration object that implements the ieatable interface to decorate the fish object.
In addition, the reason for implementing the ieatable interface of the fish object may be due to the consideration of the interface isolation principle. If the attribute is used to identify whether the fish can eat or not, it is necessary to depend on the fish object, this improves system coupling. The sample code is as follows: 1 ' Search for foods that can be eaten
2 Public   Function Geteatablefish ( Byval Foods As Ieatable ()) As Ieatable ()
3
4 ' Used to save the list
5 Dim Templist As   New Arraylist
6
7 ' Loop search
8 For   Each Item As Ieatable In Foods
9
10 ' Determine whether you can eat
11 If Item. iseatable Then
12
13 Templist. Add (item)
14 End   If
15 Next
16
17 ' Returned results
18 Return Templist. toarray ( GetType (Ieatable ))
19
20 End Function
21
22 ' Can I use interfaces?
23 Public   Interface Ieatable
24
25 ' Can I eat?
26 Function Iseatable () As   Boolean
27
28 End Interface

When software is designed, it is neither good nor bad. Everything has two sides. This is a trade-off. What we can do is to make the design controllable, if the design gets out of control, it's all done. Then again, if we can confirm that the criteria in the current system for determining whether a fish can eat will not change, it is completely possible to integrate the things that will not change into the fish object, it is also a good idea to use attributes to implement specific implementations.

• From
  Anders Liu
  Comment

Well... We recommend that you think more about it before writing.

For example:Public ClassGoby: ifish, iclimbable, ieatable
I think this is better:Public ClassGoby: fish, iclimbable, ieatable

Have you seen the difference?

As for Anders Liu
And wanghualiang
The opinions are basically the same, if I do not understand the mistakes. When introducing a class, we need to consider the purpose of introducing this class, it is not reliable to introduce a class without any purpose or simply to encapsulate a method to introduce a class. I will write an article to discuss classes and interfaces in detail later.