Vertical subdivision knowledge points in inheritance: property inheritance and subdivision knowledge points

Vertical subdivision knowledge points in inheritance: property inheritance and subdivision knowledge points

We will not share with you the situation that "the class instance can inherit the attributes of the parent class" is known to everyone.

This article mainly shares "the problem of overwriting attribute values in the continuous abstraction process"

Because we need to use the SubMail information sending platform recently, and the platform's text messages must be sent in the form of a model (mu) board, we cannot write text messages at will, so I wrote N templates based on business needs, which is not the focus

The question is: (which one is the best one to send messages ?) The parameters of each template are not the same (template ID, parameter quantity, parameter name), for example:

Your account @ var (name) has been approved. Welcome to @ var (sys)

Order @ var (order) paid, @ var (name) (@ var (tel) will be consumed at @ var (date)

However, the ID appid appkey is the same. to distinguish between variables, constants, and access levels, I thought of using inheritance + read-only to implement the appkey.

 

/// <Summary> /// abstract class used for sending generic constraints // The method signature for sending is written as follows: public static bool SendModel <T> (string target, T model) where T: subMailModel /// </summary> public abstract class SubMailModel {}/// <summary> /// corresponding SubMail identity /// </summary> public abstract class Base10107: subMailModel {const string appid = ""; // ID const string appkey = ""; // ID key} // <summary> // template // </summary> public class Template_PaySuccessUser: Base10107 {const string templateID = "DVaVf3 "; // template parameter public string order {get; set;} public string name {get; set;} public string tel {get; set ;}}Method that cannot be accessed during the call

The above statement has a very obvious problem: the generic constraint is a top-level abstract class, and there is nothing in this class. All constants are in the corresponding subclass, the parent class cannot access the subclass, so the variable cannot be found when calling and sending.

 

So with the following code after "improvement ",

/// <Summary> /// abstract class used for sending generic constraints // The method signature for sending is written as follows: public static bool SendModel <T> (string target, T model) where T: SubMailModel // </summary> public abstract class SubMailModel {public string appid; // ID public string appkey; // ID public string templateID ;} /// <summary> /// corresponding SubMail identity /// </summary> public abstract class Base10107: SubMailModel {string appid = "aaaaaaaaaa "; string appkey = "bbbbbbbbbbbbbbb" ;}/// <summary >/// template /// </summary> public class Template_PaySuccessUser: Base10107 {string templateID = "DVaVf3 "; // template parameter public string order {get; set;} public string name {get; set;} public string tel {get; set ;}}How to implicitly hide parent class Parameters

In the preceding method, parameters can be accessed during the call, but another problem is that the parameters of the parent class are implicitly hidden rather than inherited. in this way, the variable does not have a value because of the generic constraints when sending a call.

 

I suddenly thought of a base that inherits frequently-used keywords, so I had the last piece of code.

/// <Summary> /// abstract class used for sending generic constraints // The method signature for sending is written as follows: public static bool SendModel <T> (string target, T model) where T: SubMailModel // </summary> public abstract class SubMailModel {public string appid; // ID public string appkey; // ID public string templateID ;} /// <summary> /// corresponding SubMail identity /// </summary> public abstract class Base10107: SubMailModel {public Base10107 () {base. appid = "aaaaaaaaaa"; base. appkey = "bbbbbbbbbbbbbbb" ;}/// <summary >/// template /// </summary> public class Template_PaySuccessUser: Base10107 {public Template_PaySuccessUser () {base. templateID = "DVaVf3";} // template parameter public string order {get; set;} public string name {get; set;} public string tel {get; set ;}}The logic is correct, but the access level is too large.

You can also see my title. The access level is too high, which is of course the simplest.

Directly modify the attributes of the abstract class with internal, so that when sending a call, it is accessible because it is a DLL. when calling an external call, you only need to instantiate the template class to assign values to relevant attributes to send information. The identity and template identity cannot be accessed.

End