实现1.add(1).add(2).add(3)……的级联叠加

本文详细解析了如何在JavaScript中实现数的叠加求和操作,包括将数值转换为对象、实现add方法、调用this以及实现级联调用的方法。

最近在面试的时候,面试官问我:“1.add(1).add(2).add(3)...我希望这样来实现数的叠加求和,你告诉我怎么实现?”

我哑口无言。回来经过不断的调试,终于被我找到了实现的方法。

首先,要和大家说的是,1.add(1).add(2)是绝对实现不了的。为什么呢?因为1它不是一个对象,直接运行此代码,会报“语法错误”。


所以,

问题1:如何将1转变为对象。

经过测试,我所想到的方法为:直接new一个新的Number对象出来,使用方法为:

new Number(1).add(1).add(2);

用new Number(1)替换单独的1,才可实现调用。


问题1解决了,我们来看看问题2。


问题2:add方法应该放在哪里?

在实现add()方法的时候,脑海里面第一时间想到的实现方法是:

var add = function(n){
    return this + n;
}

但是很要命的是,这个方法根本无法执行。


意思是,add()方法不存在。

其实这是必然的,因为我们的add()没有放在正确的位置上。

其实我们应该将add放在Number.prototype中,这样才可以让number对象调用到add方法。

Number.prototype.add = function(){
    return this + n;
}

好的,我们完成了问题2,接下来是问题3。


问题3:如何调用this。

在一开始的时候,我曾想过这样实现多变量相加。

<pre name="code" class="javascript"><pre name="code" class="javascript">Number.prototype.add = function(){
    var i;
    for(i = 0; i < arguments.length; i++){
        this += arguments[i];
    }
    return this;
}




但是最终结果却是报错。


其实原因在于:this不能被修改。因此请不要尝试在等号左边放上this,这样必然会报错。

所以最终应该如此实现:

Number.prototype.add = function(){
    var i, sum = 0;
    for(i = 0; i < arguments.length; i++){
        sum += arguments[i];
    }
    return this + sum;
}


问题4:如何实现级联调用。

所谓的级联调用,就是指add(1).add(2).add(3)……,类似的一直无限的调用。

要实现的方法很简单,只需要在add()方法的最后加上一句:

    return this;
如此便可实现级联调用。


最终的实现代码如下:


<!DOCTYPE html>
<html lang="en">
<head>
	<meta charset="UTF-8">
	<title>Document</title>
</head>
<body>
<script>
	Number.prototype.add = function(){
	 	var i, sum = 0;
	 	for(i = 0; i < arguments.length; i++){
	 		sum += arguments[i];
	 	}
	 	return this + sum;
	}
	alert(new Number(1).add(2,3,4,5));  //15
</script>
</body>
</html>


<think>我们正在讨论PNR(旅客订座记录)中的add-on类型航程。根据航空业术语,add-on航段通常指附加在主行程上的延伸航段,可能由不同票号或不同运价规则控制。以下将系统解释其定义及处理方式:###一、Add-on航程的核心定义1.**业务场景**-主行程:旅客原始预订的干线航班(如国际航线)-Add-on航段:后续追加的支线航班(如国内中转段),常见场景:```mermaidgraphLRA[主行程]-->B(上海-纽约J舱)C[Add-on航段]-->D(杭州-上海Y舱)```-**票号关联**:可能与主行程同票号(同一票证),也可能使用独立票号2.**技术标识**在GDS(全球分销系统)中通过特定字段标记:-Amadeus系统:`SSROTHS`备注含"ADD-ONSEGMENT"-Sabre系统:`RMK`字段标注"ADDON"标识###二、PNR处理流程差异####1.预订环节-**运价计算**:Add-on航段可能适用特殊运价公式:$$\text{总价}=P_{\text{main}}+\max(P_{\text{addon}},\text{最低附加费})$$其中$P_{\text{main}}$为主行程价格,$P_{\text{addon}}$为附加段基准价[^1]。-**自动校验**:系统需验证行程连续性(如中转时间≥120分钟):```sqlSELECTsegment_type,MIN(connection_time)FROMflight_segmentsWHEREpnr_id=&#39;ABC123&#39;GROUPBYsegment_typeHAVINGsegment_type=&#39;ADDON&#39;;--确保最短衔接时间```####2.出票环节-**票证关联**:-同票号时:在电子客票的`ADDITIONALENDORSEMENTS`栏位标注"ADD-ONATCONNECTION"-异票号时:通过`EI`(EndorsementIndicator)字段关联主票号```xml<!--示例:电子客票关联标记--><Endorsement><Type>ADDON</Type><LinkedTicket>123-4567890123</LinkedTicket></Endorsement>```####3.变更与退票-**级联规则**:修改主行程时,系统自动检查add-on航段是否仍有效:```javaif(mainSegment.isChanged()){for(Segmentaddon:pnr.getAddons()){if(!addon.validateConnection(mainSegment)){addon.setStatus(SegmentStatus.INVALID);}}}```-**退票手续费**:按**主行程运价规则**计算退费,与add-on航段独立:>示例:主行程退票费$200,add-on段退票费$50→实际收取$200[^2]###三、技术实现关键点1.**数据库设计**典型PNR表结构需区隔航段类型:|字段名|类型|示例值|说明||----------------|------------|----------------|---------------------||segment_id|VARCHAR(10)|S001|航段唯一ID||segment_type|ENUM|MAIN/ADDON|主段或附加段||linked_ticket|VARCHAR(13)|1234567890123|关联票号(可空)|2.**异常处理逻辑**当add-on航段状态异常时,GDS自动触发QC(QueueControl)消息:```QUEUE5:ADDONSEGMENTINVALID-TIMECONNECTIONLESSTHANMCT```###四、行业应用案例-**跨联盟中转**:星空联盟成员执飞主段+天合联盟成员执飞add-on段-**缺口程**:去程PVG-JFK(主行程),回程BOS-PVG(add-on航段)§§相关问题§§1.如何处理跨GDS的add-on航段(如主段在Amadeus,add-on在Sabre)?2.Add-on航段在运价计算中如何避免运价规则冲突?3.当主行程航变导致add-on航段失效时,自动保护机制如何实现?</think>### PNR中Add-on类型航程的定义与处理 **Add-on航程**(附加航段)指在已有主行程基础上追加的延伸航段,通常用于解决以下场景: 1. **地理延伸**:主行程为国际干线(如上海-纽约),Add-on段为国内支线(如杭州-上海) 2. **舱位组合**:主行程为高舱位(如公务舱),Add-on段为经济舱(因航线无高舱位) 3. **多票号关联**:主行程与Add-on段使用不同票号但需关联操作 ### 处理流程与技术实现 #### 一、业务规则特征 1. **运价计算** - Add-on段运价独立计算后与主行程叠加 - 需满足**运价连续性规则**: $$ \text{总价} = P_{\text{main}} + P_{\text{addon}} - \Delta_{\text{deduction}} $$ 其中$\Delta_{\text{deduction}}$为联运折扣(若有)[^1] 2. **行程约束** - 最短衔接时间(MCT)强制校验: ```java // 伪代码:MCT校验逻辑 if (addonSegment.departureTime - mainSegment.arrivalTime < MIN_CONNECTION_TIME) { throw new InvalidConnectionException("MCT violation"); } ``` #### 二、PNR系统处理机制 1. **数据结构标识** GDS系统通过特殊字段标记Add-on航段: | 字段 | 示例值 | 含义 | |---------------|-------------|---------------------| | `segment_type` | `ADDON` | 航段类型标识 | | `linked_ticket`| `784-1234567890` | 关联主票号 | 2. **自动化处理流程** ```mermaid graph TD A[添加Add-on航段请求] --> B{校验主行程状态} B -->|主行程有效| C[计算联运运价] B -->|主行程无效| D[拒绝请求] C --> E[生成关联票号] E --> F[写入PNR数据库] F --> G[发送电子客票指令] ``` #### 三、技术实现难点 1. **跨系统协同** - 当主行程与Add-on段归属不同航空公司时: ```python # 示例:跨航司PNR同步 def sync_addon(pnr, airline_code): if airline_code != main_airline: amadeus_api.push_pnr(pnr) # 推送至其他GDS sabre_api.verify_ticket_linkage(pnr.tickets) ``` 2. **异常处理** - 主行程变更时自动触发Add-on段重验证: ```sql /* 数据库触发器示例 */ CREATE TRIGGER check_addon_after_update AFTER UPDATE ON main_segments FOR EACH ROW EXECUTE FUNCTION validate_addon_connection(); ``` ### 行业应用场景 - **缺口程(OJT)**:去程PVG-JFK(主行程),回程BOS-PVG(Add-on段) - **混舱组合**:国际段公务舱(主票号)+ 国内段经济舱(Add-on票号) - **联运扩展**:星空联盟成员执飞主段 + 伙伴航司执飞Add-on段[^2]
评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值