Different solutions selected for different scenarios based on scalability considerations

When it comes to extension, we all know that the application of some oo feature and principles can achieve this kind of effect (encapsulation), which can make the object most likely to encapsulate the changed part in the object, reduce the impact. coding to interface instead of implementation can be loosely coupled between objects for convenient extension. guideline such as OCP and SRP is also a method to achieve easy scalability.
In actual application, you may choose different solutions for different scenarios. Let's look at two examples.
First, Using System;
Using System. collections;
/**/ /// <Summary>
///Shopcart class
/// </Summary>
Public   Class Shopcart
{
Private List < Production > Productions;
Public Shopcart ()
{
Productions= NewList<Production>();
}
Public   Void Addproduction (production newproduction)
{
Productions. Add (newproduction );
}
}
/**/ /// <Summary>
///Abstract class production
/// </Summary>
Public   Abstract   Class Production
{
//
}
/**/ /// <Summary>
///Instance class
/// </Summary>
Public   Class Apple: Production
{
//
}
/**/ /// <Summary>
///Another instance class
/// </Summary>
Public   Class Fish: Production
{
//
}

It is easy to understand that shopcart can store any product, as long as it is inherited from the production base class, so that new product varieties will be added in the future, you only need to add a new instance class and do not need to modify the shopcart class.
Example 2, Using System;
Using System. collections;
/**/ /// <Summary>
///Subway class
/// </Summary>
Public   Class Subway
{
Private List < Station > Stations;
Private List < Connection > Connections;

Public Subway ()
{
Stations =   New List < Station > ();
Connections =   New List < Connection > ();

}
Public   Void Addstation ( String Stationname)
{
Stations. Add (NewStation (stationname ));
}
Public   Void Addconnection ( String Stationname1, String Stationname2)
{
Stations. Add (NewConnection (stationname1, stationname2 ));
}
//
}

/**/ /// <Summary>
///Station class
/// </Summary>
Public   Class Station
{
Public Station ( String Stationname)
{
//
}
//
}
/**/ /// <Summary>
///Connection class
/// </Summary>
Public   Class Connection
{
Public Connection (station station1, station station2)
{
//
}
//
}

The subway is composed of a station and a connection line. You can add your own stations and lines.
Here, we didn't pass the station and connection objects into the subway class as parameters. Our consideration is that the subway and connection lines are Entity classes and will not be modified, so we will not abstract them. the end user only cares about the station name and the final subway route map, and is not interested in the subway objects and connection lines. therefore, these two objects are not exposed to users. in this way, if there is a need for expansion or modification in the future, for example, in addition to the station name and color attribute, we can easily solve the problem internally without any changes to the outside world.
We can see from these two examples that the final good design is not achieved by the knowledge of some books, but by the accurate understanding of requirements and the forecast of future demand changes. only then can we know that those are changing and those are unchanged. this kind of OOA work requires considerable effort and is very worthwhile. It will do more with less for future maintenance.