What we need is not just concrete completion. [Learning class and interface feelings]

Today, I saw a colleague write a Section Code:
Arraylist A = new arraylist;
Logitisc. Package P = new logitisc. package;
A. Add (P)
Object H = new object ();
Foreach (h in)
{
If (H = P)
///
Else
///
}

Surprised, he stored the objects of a (Logistics System) package in the arraylist of,
I carefully read the help of arralist and found that arralist supports adding an object,
I used to think that only strings can be added. Now I understand that string is also an object.
Then, he tells why he wants to do this,

Because there is a small packet under a package object, and there are items in the small packet,
The shipping process is,
Package items into small packages and combine them into large packages.

For example:
Warehouse A = new warehouse ()
Package P = new package ();
Goods G1 = new goods ();
Goods g2 = new goods ();
P. Add (G1 );
P. Add (G2 );
Warehouse A. Add (P );

This is a model for storing items in a warehouse.

You can see how clear this process is through object description.

Therefore, it has always been suggested that when we define a model, we should abstract and then abstract it,
First, do not consider implementation. Once implementation is considered, it will inevitably be entangled in details,
The overall consideration is often ignored.

The main difference between a process and an object lies in the difference in ideas, rather than the specific code.

Class corresponds to the Model in real life.
When defining classes, you must define them according to the object model instead of limiting the definition of languages,
Do not be afraid that the specific language cannot be completed.