計算機只能識別機器碼0101…編程語言->能執行的機器碼 需要經過 預處理->編譯->彙編->鏈接->機器碼過程。一個語言處理系統的示意圖如下：

編譯器 是將源語言程序一次性翻譯成一個等價的，用目標語言編寫的程序。還存在另一種常見的語言處理器，解釋器：它是逐個語句的執行源語言程序。由一個編譯器產生的目標語言程序通常比一個解釋器快，但解釋器的錯誤診斷效果通常更好。

Java語言處理器結合了編譯和解釋的過程。一個.Java源程序首先被編譯為.class字節碼文件，被加載到虛擬機中，然後由虛擬機將字節碼翻譯成機器碼。

虛擬機的好處在於：一旦一個程序被轉換成 Java 字節碼，那麼它便可以在不同平台上的虛擬機實現里運行。實現一次編寫，到處運行。另外一個好處是它帶來了一個託管環境。這個託管環境能夠代替我們處理一些代碼中冗長而且容易出錯的部分，如自動內存管理與垃圾回收。

在Hotspot中，虛擬機翻譯字節碼有兩種方式：

1.解釋執行
即逐條將字節碼翻譯成機器碼並執行。

2.即時編譯
即將一個方法中包含的所有字節碼編譯成機器碼后再執行。

前者的優勢在於無需等待編譯，而後者的優勢在於實際運行速度更快。HotSpot 默認採用混合模式，綜合了解釋執行和即時編譯兩者的優點。它會先解釋執行字節碼，而後將其中反覆執行的熱點代碼，以方法為單位進行即時編譯。

即時編譯建立在程序符合二八定律的假設上，也就是百分之二十的代碼佔據了百分之八十的計算資源。

好了，裝X結束。

阿姨知道的編譯知識全在上面了。。(っ╥╯﹏╰╥c)

如題，下面我們來看一下讓Java項目運行起來我們能做什麼。

我們能做的很簡單，當然不是寫虛擬機。我們只需要：

1.執行command javac，將.Java文件變為.class文件。
2.執行command java，讓.class文件運行起來。

也就是 執行command ：）

Java程序的運行方式

Java程序可以通過java命令運行.class文件或運行可執行Jar文件。
我們先看第一種方式：從Hello World開始。

運行.class文件

Step1:編寫Java文件

Step2:執行 command javac

將.Java文件變為.class文件

小貼士：class文件的全路徑名是包名目錄+ 類文件名。

Step3:執行 command java

運行.class文件

神奇，我們沒有用IDE讓Java程序運行起來了 ：）

小夥伴先別噴老阿姨，哪特么有這麼簡單的Java項目啊。。我們工作中用的明明都是Jar文件啊…
Jar文件咋運行啊！！

運行可執行Jar文件

Jar文件是基於ZIP文件格式的一種文件格式，它將大量的Java類文件、相關的元數據和資源（文本、圖片等）文件聚合到一個Jar文件中，此外還包含一個可選的META-INF文件夾。這個文件夾下的文件或文件夾主要用來打包和擴展配置信息，包括安全，版本，擴展程序和服務等。如MANIFEST.MF文件定義了擴展和打包的相關數據信息。
一個Jar文件通常在項目中用作第三方類庫使用，也是項目構建的一部分。

生成一個Jar文件大致分為兩步：

1.將源文件編譯為.class文件

2.通過 command jar命令將.class文件，資源文件等等打成一個文件格式的Jar文件。

我們以一個SbDemo項目為例來看Jar文件的打包和運行。項目目錄結構如下：

Test2.java中調用了Test1.java的方法，

我們需要先將Test1.java編譯並打成一個Test1.jar文件，然後通過Test1.jar將Test2.java編譯並打成一個可執行的Test2.jar文件。

可執行和不可執行的Jar文件 區別在於是否在Jar文件中指定了main方法的入口，我們後面再看。

Step1:Test1.java的編譯

Step2:將編譯后的classes/com/Test1.class文件打成一個Test1.jar包

Java中和jar包相關的命令是jar命令，生成一個jar包我們需要定義信息文件(manifest-file)，它可以定義所生成jar包的classpath類搜索路徑,jar包的入口類等等。可以理解為與Jar包相關的元數據配置信息。
Step2.1 書寫信息文件
這裏我們使用resources/manifest-test1.text文件作為信息文件

是的，Test1.java太簡單了，就是打成一個可被他人引用的jar包，信息文件不重要。
Step2.2 執行打包命令

Step3. 編譯Test2.java文件
因為Test2.java中引用了com.Test1類，所以我們需要在編譯時指定Classpath路徑。
Classpath：顧名思義，是指待編譯類依賴的類所在路徑位置。我們可以通過 javac 的 -cp 參數指定。
關於編譯時classpath的值優先級如下：

• 如果沒有傳入classpath參數，將使用環境變量CLASSPATH的值。（小夥伴不知道環境變量咋查看和設置？去看阿姨的上一篇文章：）
• 如果沒有發現環境變量CLASSPATH，將使用 執行命令的當前文件夾（.）。
• 如果javac命令行 通過-classpath or -cp參數指定了類路徑值，則優先級最高。

這裏我們使用-cp指定Test1.jar所在位置

可以看到classes目錄下已經生成了com2/Test2.class文件了。

Step4. 將編譯后的Test2.class和它依賴的Test1.jar一起打成一個可執行的Jar包
Step4.1 書寫信息文件
這時候我們使用信息文件resources/manifest-test2.text文件指定這些信息

Step4.2 執行Jar包生成命令

可以看到在lib目錄下生成了Test2.jar

Step5.運行我們的可執行Jar

大功告成了，我們的SbDemo項目Run起來了…

當然實際項目不可能人肉編譯，打包。我們需要通過Maven/Gradle等構建工具，幫助我們管理代碼之間的Jar包依賴，構建，部署…我們可能大多時候通過點一下IDE就託管了Maven的構建部署命令。

拿Maven舉例子，Maven首先定義了一套項目結構，我們按照它的結構書寫代碼，引入各個模塊所需要的Jar包依賴。然後Maven可以通過自己的生命周期管理項目的清理，構建，打包，部署階段。每個階段有對應的Maven插件執行相應的目標。IDE又整合了Maven，使我們通過點吧點吧按鈕就完成了項目的運行。

但是當一個項目並沒有按照規範的構建工具結構搭建，或者項目沒有成功運行報錯時，了解Java實際的編譯運行過程會對理解、解決這類問題有所幫助。

好啦，限於篇幅，阿姨先不講這些年Maven躺過的坑了，有想看的嗎？關注，在看，轉發三連回應下 >-<

參考資料：
[1].《編譯原理》序 (ﾟ´ω`ﾟ)ﾟ
[2].https://time.geekbang.org/column/article/11289

本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理

【其他文章推薦】

※廣告預算用在刀口上，台北網頁設計公司幫您達到更多曝光效益

※別再煩惱如何寫文案,掌握八大原則!

※教你寫出一流的銷售文案?

※超省錢租車方案

※廣告預算用在刀口上，台北網頁設計公司幫您達到更多曝光效益

※產品缺大量曝光嗎?你需要的是一流包裝設計!

※回頭車貨運收費標準

0. 前言

通過前兩篇，我們創建了一個項目，並規定了一個基本的數據層訪問接口。這一篇，我們將以EF Core為例演示一下數據層訪問接口如何實現，以及實現中需要注意的地方。

1. 添加EF Core

先在數據層實現層引入 EF Core：

cd Domain.Implements
dotnet add package Microsoft.EntityFrameworkCore

當前項目以SqlLite為例，所以再添加一個SqlLite數據庫驅動：

dotnet add package Microsoft.EntityFrameworkCore.SQLite

刪除 Domain.Implements 里默認的Class1.cs 文件，然後添加Insfrastructure目錄，創建一個 DefaultContext：

using Microsoft.EntityFrameworkCore;

namespace Domain.Implements.Insfrastructure
{
    public class DefaultContext : DbContext
    {
        private string ConnectStr { get; }
        public DefaultContext(string connectStr)
        {
            ConnectStr = connectStr;
        }

        protected override void OnConfiguring(DbContextOptionsBuilder optionsBuilder)
        {
            optionsBuilder.UseSqlite(ConnectStr);//如果需要別的數據庫，在這裏進行修改
        }
    }
}

2. EF Core 批量加載模型

通常情況下，在使用ORM的時候，我們不希望過度的使用特性來標註實體類。因為如果後期需要變更ORM或者出現其他變動的時候，使用特性來標註實體類的話，會導致遷移變得複雜。而且大部分ORM框架的特性都依賴於框架本身，並非是統一的特性結構，這樣就會造成一個後果：本來應該是對調用方隱藏的實現就會被公開，而且在項目引用關係中容易出現循環引用。

所以，我在開發中會尋找是否支持配置類，如果使用配置類或者在ORM框架中設置映射關係，那麼就可以保證數據層的純凈，也能實現對調用方隱藏實現。

EF Core的配置類我們在《C# 數據訪問系列》中關於EF的文章中介紹過，這裏就不做過多介紹了（沒來得及看的小夥伴們不着急，後續會有一個簡單版的介紹）。

通常情況下，配置類我也會放在Domain.Implements項目中。現在我給大家介紹一下如何快速批量加載配置類：

protected override void OnModelCreating(ModelBuilder modelBuilder)
{
    modelBuilder.ApplyConfigurationsFromAssembly(Assembly.GetAssembly(this.GetType()),
		t => t.GetInterfaces().Any(i => t.Name.Contains("IEntityTypeConfiguration")));
}

現在版本的EF Core支持通過Assembly加載配置類，可以指定加載當前上下文類所在的Assembly，然後篩選實現接口中包含IEntityTypeConfiguration的類即可。

3. 使用EF Core實現數據操作

我們已經創建好了一個EF Context，那麼現在就帶領大家一起看一下，如何使用EF來實現 上一篇《「asp.net core」7 實戰之 數據訪問層定義》中介紹的數據訪問接口：

新建一個BaseRepository類，在Domain.Implements項目的Insfrastructure 目錄下：

using Domain.Infrastructure;
using Microsoft.EntityFrameworkCore;

namespace Domain.Implements.Insfrastructure
{
    public abstract class BaseRepository<T> : ISearchRepository<T>, IModifyRepository<T> where T : class
    {
        public DbContext Context { get; }
        protected BaseRepository(DbContext context)
        {
            Context = context;
        }
    }
}

先創建以上內容，這裏給Repository傳參的時候，使用的是EFCore的默認Context類不是我們自己定義的。這是我個人習慣，實際上並沒有其他影響。主要是為了對實現類隱藏具體的EF 上下文實現類。

在實現各接口方法之前，創建如下屬性：

public DbSet<T> Set { get => Context.Set<T>(); }

這是EF操作數據的核心所在。

3.1 實現IModifyRepository接口

先實現修改接口：

public T Insert(T entity)
{   
    return Set.Add(entity).Entity;
}

public void Insert(params T[] entities)
{
    Set.AddRange(entities);
}

public void Insert(IEnumerable<T> entities)
{
    Set.AddRange(entities);
}
public void Update(T entity)
{
    Set.Update(entity);
}

public void Update(params T[] entities)
{
    Set.UpdateRange(entities);
}

public void Delete(T entity)
{
    Set.Remove(entity);
}

public void Delete(params T[] entities)
{
    Set.RemoveRange(entities);
}

在修改接口裡，我預留了幾個方法沒有實現，因為這幾個方法使用EF Core自身可以實現，但實現會比較麻煩，所以這裏藉助一個EF Core的插件：

dotnet add package Z.EntityFramework.Plus.EFCore

這是一個免費開源的插件，可以直接使用。在Domain.Implements 中添加后，在BaseRepository 中添加如下引用：

using System.Linq;
using System.Linq.Expressions;

實現方法：

public void Update(Expression<Func<T, bool>> predicate, Expression<Func<T, T>> updator)
{
    Set.Where(predicate).UpdateFromQuery(updator);
}

public void Delete(Expression<Func<T, bool>> predicate)
{
    Set.Where(predicate).DeleteFromQuery();
}

public void DeleteByKey(object key)
{
    Delete(Set.Find(key));
}

public void DeleteByKeys(params object[] keys)
{
    foreach (var k in keys)
    {
        DeleteByKey(k);
    }
}

這裏根據主鍵刪除的方法有個問題，我們無法根據條件進行刪除，實際上如果約定泛型T是BaseEntity的子類，我們可以獲取到主鍵，但是這樣又會引入另一個泛型，為了避免引入多個泛型根據主鍵的刪除就採用了這種方式。

3.2 實現ISearchRepository 接口

獲取數據以及基礎統計接口：

public T Get(object key)
{
    return Set.Find(key);
}

public T Get(Expression<Func<T, bool>> predicate)
{
    return Set.SingleOrDefault(predicate);
}

public int Count()
{
    return Set.Count();
}

public long LongCount()
{
    return Set.LongCount();
}

public int Count(Expression<Func<T, bool>> predicate)
{
    return Set.Count(predicate);
}

public long LongCount(Expression<Func<T, bool>> predicate)
{
    return Set.LongCount(predicate);
}

public bool IsExists(Expression<Func<T, bool>> predicate)
{
    return Set.Any(predicate);
}

這裡有一個需要關注的地方，在使用條件查詢單個數據的時候，我使用了SingleOrDefault而不是FirstOrDefault。這是因為我在這裏做了規定，如果使用條件查詢，調用方應該能預期所使用條件是能查詢出最多一條數據的。不過，這裏可以根據實際業務需要修改方法：

• Single 返回單個數據，如果數據大於1或者等於0,則拋出異常
• SingleOrDefault 返回單個數據，如果結果集沒有數據，則返回null，如果多於1，則拋出異常
• First 返回結果集的第一個元素，如果結果集沒有數據，則拋出異常
• FirstOrDefault 返回結果集的第一個元素，如果沒有元素則返回null

實現查詢方法：

public List<T> Search()
{
    return Query().ToList();
}

public List<T> Search(Expression<Func<T, bool>> predicate)
{
    return Query(predicate).ToList();
}

public IEnumerable<T> Query()
{
    return Set;
}

public IEnumerable<T> Query(Expression<Func<T, bool>> predicate)
{
    return Set.Where(predicate);
}

public List<T> Search<P>(Expression<Func<T, bool>> predicate, Expression<Func<T, P>> order)
{
    return Search(predicate, order, false);
}

public List<T> Search<P>(Expression<Func<T, bool>> predicate, Expression<Func<T, P>> order, bool isDesc)
{
    var source = Set.Where(predicate);
    if (isDesc)
    {
        source = source.OrderByDescending(order);
    }
    else
    {
        source = source.OrderBy(order);
    }
    return source.ToList();
}

這裏我盡量通過調用了參數最多的方法來實現查詢功能，這樣有一個好處，小夥伴們可以想一下哈。當然了，這是我自己覺得這樣會好一點。

實現分頁：

在實現分頁之前，我們知道當時我們定義的分頁參數類的排序字段用的是字符串，而不是lambda表達式，而Linq To EF需要一個Lambda表示才可以進行排序。這裏就有兩種方案，可以自己寫一個方法，實現字符串到Lambda表達式的轉換；第二種就是借用三方庫來實現，正好我們之前引用的EF Core增強插件里有這個功能：

var list = context.Customers.OrderByDescendingDynamic(x => "x.Name").ToList();

這是它給出的示例。

我們可以先依此來寫一份實現方法：

public PageModel<T> Search(PageCondition<T> condition)
{
    var result = new PageModel<T>
    {
        TotalCount = LongCount(condition.Predicate),
        CurrentPage = condition.CurrentPage,
        PerpageSize = condition.PerpageSize,
    };
    var source = Query(condition.Predicate);
    if (condition.Sort.ToUpper().StartsWith("a")) // asc
    {
        source = source.OrderByDynamic(t => $"t.{condition.OrderProperty}");
    }
    else // desc
    {
        source = source.OrderByDescendingDynamic(t => $"t.{condition.OrderProperty}");
    }
    var items = source.Skip((condition.CurrentPage -1)* condition.PerpageSize).Take(condition.PerpageSize);
    result.Items = items.ToList();
    return result;
}

回到第一種方案：

我們需要手動寫一個字符串的處理方法，先在Utils項目創建以下目錄：Extend>Lambda，並在目錄中添加一個ExtLinq類，代碼如下：

using System.Linq;
using System.Linq.Expressions;
using System.Text.RegularExpressions;

namespace Utils.Extend.Lambda
{
    public static class ExtLinq
    {
        public static IQueryable<T> CreateOrderExpression<T>(this IQueryable<T> source, string orderBy, string orderAsc)
        {
            if (string.IsNullOrEmpty(orderBy)|| string.IsNullOrEmpty(orderAsc)) return source;
            var isAsc = orderAsc.ToLower() == "asc";
            var _order = orderBy.Split(',');
            MethodCallExpression resultExp = null;
            foreach (var item in _order)
            {
                var orderPart = item;
                orderPart = Regex.Replace(orderPart, @"\s+", " ");
                var orderArry = orderPart.Split(' ');
                var orderField = orderArry[0];
                if (orderArry.Length == 2)
                {
                    isAsc = orderArry[1].ToUpper() == "ASC";
                }
                var parameter = Expression.Parameter(typeof(T), "t");
                var property = typeof(T).GetProperty(orderField);
                var propertyAccess = Expression.MakeMemberAccess(parameter, property);
                var orderByExp = Expression.Lambda(propertyAccess, parameter);
                resultExp = Expression.Call(typeof(Queryable), isAsc ? "OrderBy" : "OrderByDescending",
                    new[] {typeof(T), property.PropertyType},
                    source.Expression, Expression.Quote(orderByExp));
            }

            return resultExp == null
                ? source
                : source.Provider.CreateQuery<T>(resultExp);
        }
    }
}

暫時不用關心為什麼這樣寫，後續會為大家分析的。

然後回過頭來再實現我們的分頁，先添加Utils 到Domain.Implements項目中

cd ../Domain.Implements # 進入Domain.Implements 項目目錄
dotnet add reference ../Utils

public PageModel<T> Search(PageCondition<T> condition)
{
    var result = new PageModel<T>
    {
        TotalCount = LongCount(condition.Predicate),
        CurrentPage = condition.CurrentPage,
        PerpageSize = condition.PerpageSize,
    };
    var source = Set.Where(condition.Predicate).CreateOrderExpression(condition.OrderProperty, condition.Sort);
    var items = source.Skip((condition.CurrentPage -1)* condition.PerpageSize).Take(condition.PerpageSize);
    result.Items = items.ToList();
    return result;
}

記得添加引用：

using Utils.Extend.Lambda;

在做分頁的時候，因為前台傳入的參數大多都是字符串的排序字段，所以到後端需要進程字符串到字段的處理。這裏的處理利用了C# Expression的一個技術，這裏就不做過多介紹了。後續在.net core高級篇中會有介紹。

4. 總結

到目前為止，看起來我們已經成功實現了利用EF Core為我們達成 數據操作和查詢的目的。但是，別忘了EF Core需要手動調用一個SaveChanges方法。下一篇，我們將為大家介紹如何優雅的執行SaveChanges方法。

這一篇介紹到這裏，雖然說明不是很多，但是這也是我在開發中總結的經驗。

更多內容煩請關注我的博客《高先生小屋》

本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理

【其他文章推薦】

※別再煩惱如何寫文案,掌握八大原則!

※網頁設計一頭霧水該從何著手呢? 台北網頁設計公司幫您輕鬆架站!

※超省錢租車方案

※教你寫出一流的銷售文案?

※網頁設計最專業,超強功能平台可客製化

※產品缺大量曝光嗎?你需要的是一流包裝設計!

※台中搬家遵守搬運三大原則,讓您的家具不再被破壞!

SunnyUI.Net, 基於 C# .Net WinForm 開源控件庫、工具類庫、擴展類庫、多頁面開發框架

• Blog: https://www.cnblogs.com/yhuse
• Gitee: https://gitee.com/yhuse/SunnyUI
• GitHub: https://github.com/yhuse/SunnyUI
• 幫助文檔目錄: https://www.cnblogs.com/yhuse/p/SunnyUI_Menu.html
• 歡迎交流，QQ群：  56829229 (SunnyUI技術交流群) 

主題

1、Color 色彩

SunnyUI為了避免視覺傳達差異，使用一套特定的調色板來規定顏色，為你所搭建的產品提供一致的外觀視覺感受。主要顏色參照Element（https://element.eleme.cn/）

• 主色

SunnyUI主要品牌顏色是鮮艷、友好的藍色。

• 輔助色

除了主色外的場景色，需要在不同的場景中使用（例如紅色表示危險的操作）。

• 中性色

中性色用於文本、背景和邊框顏色。通過運用不同的中性色，來表現層次結構。

2、Rect邊框

我們對邊框進行統一規範，可用於按鈕、卡片、彈窗等組件里。

主要屬性如下：

• RectColor：邊框顏色
• RectDisableColor：控件不可用時邊框顏色
• RectSides：邊框显示方向
• 無：不显示邊框
• 全部：显示全部邊框
• 頂：显示頂部邊框
• 底：显示底部邊框
• 左：显示左側邊框
• 右：显示右側邊框

注：邊框显示和圓角設置相關，如果一側的邊框兩端端點為圓角，則此邊框必定显示。

3、Radius圓角

我們提供了以下幾種圓角樣式，以供選擇。默認圓角大小為5px。

主要屬性如下：

Radius：圓角大小

RadiusSides：显示四個角圓角的显示與否

• 圓角不显示

• 默認圓角大小為5px

• 圓角大小與控件高度相等時，显示大圓角

• 可通過四個角圓角的設置，對控件組合显示

4、Font字體

默認字體為：微軟雅黑, 12pt

5、Style主題

SunnyUI包含 Element 風格主題 11 個，DotNetBar 主題 3 個，其他主題 2 個，包含主題管理組件 UIStyleManager，可自由切換主題。

•  UIStyleManager

參考SunnyUI.Demo.exe，將UIStyleManager放置在主窗體上，通過選擇UIStyleManager的屬性Style，或者通過代碼設置統一主題風格。

UIStyleManager.Style = style;

• Style主要屬性如下：

Style：設置主題風格

StyleCustomMode：是否為自定義主題，設置為False時使用UIStyleManager提供的統一主題風格，設置為Ture時可手動調整控件配色，不受UIStyleManager約束。

• UIStyle.Blue

• UIStyle.Green

• UIStyle.Orange

• UIStyle.Red

• UIStyle.Gray

• UIStyle.White

• UIStyle.DarkBlue

• UIStyle.Black

• UIStyle.Office2010Blue

• UIStyle.Office2010Silver

• UIStyle.Office2010Black

原創文章，轉載請保留鏈接 Sunny’s blog

本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理

【其他文章推薦】

※超省錢租車方案

※別再煩惱如何寫文案,掌握八大原則!

※回頭車貨運收費標準

※教你寫出一流的銷售文案?

※產品缺大量曝光嗎?你需要的是一流包裝設計!

※廣告預算用在刀口上，台北網頁設計公司幫您達到更多曝光效益

※網頁設計最專業,超強功能平台可客製化

引言

UDP是一個簡單的面向數據報的運輸層協議

UDP不提供可靠性，它把應用程序傳給IP層得數據發送出去，不保證它們能達到目的地

UDP首部

端口號表示發送進程和接受進程。

UDP長度字段指的是UDP首部和UDP數據的字節長度，該字段最小值為8字節，

UDP長度是全長減去IP首部的長度

UDP檢驗和是一個端到端的檢驗和。它由發送端計算，然後由接收端驗證。其目的是為了發現UDP首部和數據在發送端到接收端之間發生的任何改動。

最大UDP數據報長度

理論上，IP數據報的最大長度是65535字節，這是由IP首部（圖3-1）16比特總長度字段所限制的。去除20字節的IP首部和8個字節的UDP首部，UDP數據報中用戶數據的最長長度為65507字節。但是，大多數實現所提供的長度比這個最大值小。

UDP校驗和

UDP和TCP在首部中都有覆蓋它們首部和數據的檢驗和。UDP的檢驗和是可選的，而TCP的檢驗和是必需的。

儘管UDP檢驗和的基本計算方法與我們在3.2節中描述的IP首部檢驗和計算方法相類似（16 bit字的二進制反碼和），但是它們之間存在不同的地方。首先，UDP數據報的長度可以為奇数字節，但是檢驗和算法是把若干個16 bit字相加。解決方法是必要時在最後增加填充字節0，這隻是為了檢驗和的計算（也就是說，可能增加的填充字節不被傳送）。

其次，UDP數據報和TCP段都包含一個12字節長的偽首部，它是為了計算檢驗和而設置的。偽首部包含IP首部一些字段。其目的是讓UDP兩次檢查數據是否已經正確到達目的地（例如，IP沒有接受地址不是本主機的數據報，以及IP沒有把應傳給另一高層的數據報傳給UDP）。UDP數據報中的偽首部格式如圖11-3所示。

在該圖中，我們特地舉了一個奇數長度的數據報例子，因而在計算檢驗和時需要加上填充字節。注意，UDP數據報的長度在檢驗和計算過程中出現兩次。

如果檢驗和的計算結果為0，則存入的值為全1（65535），這在二進制反碼計算中是等效的。如果傳送的檢驗和為0，說明發送端沒有計算檢驗和。

如果發送端沒有計算檢驗和而接收端檢測到檢驗和有差錯，那麼UDP數據報就要被悄悄地丟棄。不產生任何差錯報文（當IP層檢測到IP首部檢驗和有差錯時也這樣做）。

UDP檢驗和是一個端到端的檢驗和。它由發送端計算，然後由接收端驗證。其目的是為了發現UDP首部和數據在發送端到接收端之間發生的任何改動。

這個系列主要是對自己讀TCP/IP詳解 卷一 協議的筆記，推薦看完以後去閱讀一下這本又臭又厚的書

电子書的鏈接地址http://www.52im.net/topic-tcpipvol1.html

感謝這位站長的開源 

本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理

【其他文章推薦】

※回頭車貨運收費標準

※產品缺大量曝光嗎?你需要的是一流包裝設計!

※自行創業缺乏曝光? 網頁設計幫您第一時間規劃公司的形象門面

※推薦評價好的iphone維修中心

※教你寫出一流的銷售文案?

作者：小傅哥
博客：https://bugstack.cn

沉澱、分享、成長，讓自己和他人都能有所收穫！

一、前言

對於代碼你有編程感覺嗎

很多人寫代碼往往是沒有編程感覺的，也就是除了可以把功能按照固定的流程編寫出流水式的代碼外，很難去思考整套功能服務的擴展性和可維護性。尤其是在一些較大型的功能搭建上，比較缺失一些駕馭能力，從而導致最終的代碼相對來說不能做到盡善盡美。

江洋大盜與江洋大偷

兩個本想描述一樣的意思的詞，只因一字只差就讓人覺得一個是好牛，一個好搞笑。往往我們去開發編程寫代碼時也經常將一些不恰當的用法用於業務需求實現中，當卻不能意識到。一方面是由於編碼不多缺少較大型項目的實踐，另一方面是不思進取的總在以完成需求為目標缺少精益求精的工匠精神。

書從來不是看的而是用的

在這個學習資料幾乎爆炸的時代，甚至你可以輕易就獲取幾個T的視頻，小手輕輕一點就收藏一堆文章，但卻很少去看。學習的過程從不只是簡單的看一遍就可以，對於一些實操性的技術書籍，如果真的希望學習到知識，那麼一定是把這本書用起來而絕對不是看起來。

二、開發環境

1. JDK 1.8
2. Idea + Maven
3. 涉及工程三個，可以通過關注公眾號：bugstack蟲洞棧，回復源碼下載獲取(打開獲取的鏈接，找到序號18)

三、裝飾器模式介紹

初看上圖感覺裝飾器模式有點像俄羅斯套娃、某眾汽車，而裝飾器的核心就是再不改原有類的基礎上給類新增功能。不改變原有類，可能有的小夥伴會想到繼承、AOP切面，當然這些方式都可以實現，但是使用裝飾器模式會是另外一種思路更為靈活，可以避免繼承導致的子類過多，也可以避免AOP帶來的複雜性。

你熟悉的場景很多用到裝飾器模式

new BufferedReader(new FileReader(""));，這段代碼你是否熟悉，相信學習java開發到字節流、字符流、文件流的內容時都見到了這樣的代碼，一層嵌套一層，一層嵌套一層，字節流轉字符流等等，而這樣方式的使用就是裝飾器模式的一種體現。

四、案例場景模擬

在本案例中我們模擬一個單點登錄功能擴充的場景

一般在業務開發的初期，往往內部的ERP使用只需要判斷賬戶驗證即可，驗證通過後即可訪問ERP的所有資源。但隨着業務的不斷髮展，團隊里開始出現專門的運營人員、營銷人員、數據人員，每個人員對於ERP的使用需求不同，有些需要創建活動，有些只是查看數據。同時為了保證數據的安全性，不會讓每個用戶都有最高的權限。

那麼以往使用的SSO是一個組件化通用的服務，不能在裏面添加需要的用戶訪問驗證功能。這個時候我們就可以使用裝飾器模式，擴充原有的單點登錄服務。但同時也保證原有功能不受破壞，可以繼續使用。

1. 場景模擬工程

itstack-demo-design-9-00
└── src
    └── main
        └── java
            └── org.itstack.demo.design
                ├── HandlerInterceptor.java
                └── SsoInterceptor.java

• 這裏模擬的是spring中的類：HandlerInterceptor，實現起接口功能SsoInterceptor模擬的單點登錄攔截服務。
• 為了避免引入太多spring的內容影響對設計模式的閱讀，這裏使用了同名的類和方法，盡可能減少外部的依賴。

2. 場景簡述

2.1 模擬Spring的HandlerInterceptor

public interface HandlerInterceptor {

    boolean preHandle(String request, String response, Object handler);

}

• 實際的單點登錄開發會基於；org.springframework.web.servlet.HandlerInterceptor 實現。

2.2 模擬單點登錄功能

public class SsoInterceptor implements HandlerInterceptor{

    public boolean preHandle(String request, String response, Object handler) {
        // 模擬獲取cookie
        String ticket = request.substring(1, 8);
        // 模擬校驗
        return ticket.equals("success");
    }

}

• 這裏的模擬實現非常簡單隻是截取字符串，實際使用需要從HttpServletRequest request對象中獲取cookie信息，解析ticket值做校驗。
• 在返回的裏面也非常簡單，只要獲取到了success就認為是允許登錄。

五、用一坨坨代碼實現

此場景大多數實現的方式都會採用繼承類

繼承類的實現方式也是一個比較通用的方式，通過繼承后重寫方法，併發將自己的邏輯覆蓋進去。如果是一些簡單的場景且不需要不斷維護和擴展的，此類實現並不會有什麼，也不會導致子類過多。

1. 工程結構

itstack-demo-design-9-01
└── src
    └── main
        └── java
            └── org.itstack.demo.design
                └── LoginSsoDecorator.java

• 以上工程結構非常簡單，只是通過 LoginSsoDecorator 繼承 SsoInterceptor，重寫方法功能。

2. 代碼實現

public class LoginSsoDecorator extends SsoInterceptor {

    private static Map<String, String> authMap = new ConcurrentHashMap<String, String>();

    static {
        authMap.put("huahua", "queryUserInfo");
        authMap.put("doudou", "queryUserInfo");
    }

    @Override
    public boolean preHandle(String request, String response, Object handler) {
        // 模擬獲取cookie
        String ticket = request.substring(1, 8);
        // 模擬校驗
        boolean success = ticket.equals("success");

        if (!success) return false;

        String userId = request.substring(9);
        String method = authMap.get(userId);

        // 模擬方法校驗
        return "queryUserInfo".equals(method);
    }

}

• 以上這部分通過繼承重寫方法，將個人可訪問哪些方法的功能添加到方法中。
• 以上看着代碼還算比較清晰，但如果是比較複雜的業務流程代碼，就會很混亂。

3. 測試驗證

3.1 編寫測試類

@Test
public void test_LoginSsoDecorator() {
    LoginSsoDecorator ssoDecorator = new LoginSsoDecorator();
    String request = "1successhuahua";
    boolean success = ssoDecorator.preHandle(request, "ewcdqwt40liuiu", "t");
    System.out.println("登錄校驗：" + request + (success ? " 放行" : " 攔截"));
}

• 這裏模擬的相當於登錄過程中的校驗操作，判斷用戶是否可登錄以及是否可訪問方法。

3.2 測試結果

登錄校驗：1successhuahua 攔截

Process finished with exit code 0

• 從測試結果來看滿足我們的預期，已經做了攔截。如果你在學習的過程中，可以嘗試模擬單點登錄並繼承擴展功能。

六、裝飾器模式重構代碼

接下來使用裝飾器模式來進行代碼優化，也算是一次很小的重構。

裝飾器主要解決的是直接繼承下因功能的不斷橫向擴展導致子類膨脹的問題，而是用裝飾器模式后就會比直接繼承顯得更加靈活同時這樣也就不再需要考慮子類的維護。

在裝飾器模式中有四個比較重要點抽象出來的點；

1. 抽象構件角色(Component) – 定義抽象接口
2. 具體構件角色(ConcreteComponent) – 實現抽象接口，可以是一組
3. 裝飾角色(Decorator) – 定義抽象類並繼承接口中的方法，保證一致性
4. 具體裝飾角色(ConcreteDecorator) – 擴展裝飾具體的實現邏輯

通過以上這四項來實現裝飾器模式，主要核心內容會體現在抽象類的定義和實現上。

1. 工程結構

itstack-demo-design-9-02
└── src
    └── main
        └── java
            └── org.itstack.demo.design
                ├── LoginSsoDecorator.java
                └── SsoDecorator.java

裝飾器模式模型結構

• 以上是一個裝飾器實現的類圖結構，重點的類是SsoDecorator，這個類是一個抽象類主要完成了對接口HandlerInterceptor繼承。
• 當裝飾角色繼承接口後會提供構造函數，入參就是繼承的接口實現類即可，這樣就可以很方便的擴展出不同功能組件。

2. 代碼實現

2.1 抽象類裝飾角色

public abstract class SsoDecorator implements HandlerInterceptor {

    private HandlerInterceptor handlerInterceptor;

    private SsoDecorator(){}

    public SsoDecorator(HandlerInterceptor handlerInterceptor) {
        this.handlerInterceptor = handlerInterceptor;
    }

    public boolean preHandle(String request, String response, Object handler) {
        return handlerInterceptor.preHandle(request, response, handler);
    }

}

• 在裝飾類中有兩個重點的地方是；1)繼承了處理接口、2)提供了構造函數、3)覆蓋了方法preHandle。
• 以上三個點是裝飾器模式的核心處理部分，這樣可以踢掉對子類繼承的方式實現邏輯功能擴展。

2.2 裝飾角色邏輯實現

public class LoginSsoDecorator extends SsoDecorator {

    private Logger logger = LoggerFactory.getLogger(LoginSsoDecorator.class);

    private static Map<String, String> authMap = new ConcurrentHashMap<String, String>();

    static {
        authMap.put("huahua", "queryUserInfo");
        authMap.put("doudou", "queryUserInfo");
    }

    public LoginSsoDecorator(HandlerInterceptor handlerInterceptor) {
        super(handlerInterceptor);
    }

    @Override
    public boolean preHandle(String request, String response, Object handler) {
        boolean success = super.preHandle(request, response, handler);
        if (!success) return false;
        String userId = request.substring(8);
        String method = authMap.get(userId);
        logger.info("模擬單點登錄方法訪問攔截校驗：{} {}", userId, method);
        // 模擬方法校驗
        return "queryUserInfo".equals(method);
    }
}

• 在具體的裝飾類實現中，繼承了裝飾類SsoDecorator，那麼現在就可以擴展方法；preHandle
• 在preHandle的實現中可以看到，這裏只關心擴展部分的功能，同時不會影響原有類的核心服務，也不會因為使用繼承方式而導致的多餘子類，增加了整體的靈活性。

3. 測試驗證

3.1 編寫測試類

@Test
public void test_LoginSsoDecorator() {
    LoginSsoDecorator ssoDecorator = new LoginSsoDecorator(new SsoInterceptor());
    String request = "1successhuahua";
    boolean success = ssoDecorator.preHandle(request, "ewcdqwt40liuiu", "t");
    System.out.println("登錄校驗：" + request + (success ? " 放行" : " 攔截"));
}

• 這裏測試了對裝飾器模式的使用，通過透傳原有單點登錄類new SsoInterceptor()，傳遞給裝飾器，讓裝飾器可以執行擴充的功能。
• 同時對於傳遞者和裝飾器都可以是多組的，在一些實際的業務開發中，往往也是由於太多類型的子類實現而導致不易於維護，從而使用裝飾器模式替代。

3.2 測試結果

23:50:50.796 [main] INFO  o.i.demo.design.LoginSsoDecorator - 模擬單點登錄方法訪問攔截校驗：huahua queryUserInfo
登錄校驗：1successhuahua 放行

Process finished with exit code 0

• 結果符合預期，擴展了對方法攔截的校驗性。
• 如果你在學習的過程中有用到過單點登陸，那麼可以適當在裏面進行擴展裝飾器模式進行學習使用。
• 另外，還有一種場景也可以使用裝飾器。例如；你之前使用某個實現某個接口接收單個消息，但由於外部的升級變為發送list集合消息，但你又不希望所有的代碼類都去修改這部分邏輯。那麼可以使用裝飾器模式進行適配list集合，給使用者依然是for循環后的單個消息。

七、總結

• 使用裝飾器模式滿足單一職責原則，你可以在自己的裝飾類中完成功能邏輯的擴展，而不影響主類，同時可以按需在運行時添加和刪除這部分邏輯。另外裝飾器模式與繼承父類重寫方法，在某些時候需要按需選擇，並不一定某一個就是最好。
• 裝飾器實現的重點是對抽象類繼承接口方式的使用，同時設定被繼承的接口可以通過構造函數傳遞其實現類，由此增加擴展性並重寫方法里可以實現此部分父類實現的功能。
• 就像夏天熱你穿短褲，冬天冷你穿棉褲，雨天挨澆你穿雨衣一樣，你的根本本身沒有被改變，而你的需求卻被不同的裝飾而實現。生活中往往比比皆是設計，當你可以融合這部分活靈活現的例子到代碼實現中，往往會創造出更加優雅的實現方式。

八、推薦閱讀

• 1. 重學 Java 設計模式：實戰工廠方法模式(多種類型商品發獎場景)
• 2. 重學 Java 設計模式：實戰抽象工廠模式(替換Redis雙集群升級場景)
• 3. 重學 Java 設計模式：實戰建造者模式(裝修物料組合套餐選配場景)
• 4. 重學 Java 設計模式：實戰原型模式(多套試每人題目和答案亂序場景)
• 5. 重學 Java 設計模式：實戰橋接模式(多支付渠道「微信、支付寶」與多支付模式「刷臉、指紋」場景)
• 6. 重學 Java 設計模式：實戰組合模式(營銷差異化人群發券，決策樹引擎搭建場景)

本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理

【其他文章推薦】

※廣告預算用在刀口上，台北網頁設計公司幫您達到更多曝光效益

※別再煩惱如何寫文案,掌握八大原則!

※教你寫出一流的銷售文案?

※超省錢租車方案

※廣告預算用在刀口上，台北網頁設計公司幫您達到更多曝光效益

※產品缺大量曝光嗎?你需要的是一流包裝設計!

※回頭車貨運收費標準

前言

在周六發現了Linus去Google演講的一個視頻，當時還發了一條朋友圈：

有興趣的同學也可以去看看，一點兒也不無聊，在線看Linus大佬懟人

https://www.bilibili.com/video/BV1xb411A7ac?from=search&seid=4239535088233137638

朋友圈的評論有幾個人問我女朋友呢

我又恰好給我女朋友科普過什麼是Git，所以這篇文章就有了。

Git介紹

Git是幹啥用的？它是一個版本控制軟件。

Git這個玩意三歪曾經還給女朋友給科普過（三歪會經常給女朋友說點技術的東西，我也不知道她到底聽懂了沒有，反正她每次都說好像有點懂了）。

當時情況是這樣的，某一天她跟三歪說：我做的Excel還沒保存，電腦藍屏死機了，東西全丟了。

於是三歪說：這…我也沒怎麼用過Excel這類的軟件，要不看看你用的WPS或者Office？有沒有相關的備份功能或者說是自動保存？

三歪順手找了一下WPS是有備份（自動保存）功能的，時間什麼的要自己定義一下。

三歪還補了一句：這種情況要是在程序員的手上感覺發生的概率會低一點，程序員習慣會按ctrl+s。甚至有的時候，看着看着網頁還會按ctrl+s。不過像我們寫代碼的工具(IDEA)都不用自己手動保存了….

過了一會，她說藍屏之前做的東西找不回來了，沒設置自動保存。

三歪又感嘆一句：我們寫代碼還有版本控制的軟件，在這個過程中會記錄每次修改的內容，誰改了什麼東西。誰改錯了，誰要背鍋，一個都不能跑！

女朋友聽着三歪一頓亂吹，貌似也有點感興趣：“版本控制是什麼東西？這麼厲害的嗎？會計就經常要背鍋”

三歪：“其實也沒啥，就是我們一般寫代碼往往都是多人協作的。你們會計可能是每個人負責一張表(Excel)，然後把已完成好的表傳給下一個人。而寫代碼的不一樣，我們都是在同一個項目裡邊編寫的，不會單獨等着某個人做完了，其他的人再開始動手”

女朋友：“嗯？然後呢”

三歪：“你可以理解成，我們多個人會在同一個目錄下編寫代碼，裡邊可能會做更改或者添加文件的操作。項目組裡的所有人都可以對這個目錄修改，改完了我們會提交，然後發布上線系統。”

女朋友：“啥？你是不是偏題了？這跟發布上線系統有啥關係？”

三歪：“哦，我還是舉個例子吧。就比如我們寫論文的時候可能要對論文不斷修改，我們的修改是基於原有的基礎上改的”

三歪繼續補充：”因為我們怕在原來的基礎改錯了東西，沒法恢復，所以，我們可能會有多個「畢業論文」的文件。而我們寫代碼的時候本身就是「多人協作」的，修改是無法避免的，我們不希望有多個文件的產生，又希望能夠記錄每次更改的內容。“

三歪：”更改的內容指的就是：基於原有的基礎上更改了什麼，以及提交者是誰。這樣子，我們就沒法甩鍋了。說白了就是，我們能知道的文件被改了什麼，以及誰改了“。

三歪：“到這裏，有問題嗎？”

女朋友：“嗯，沒問題，你繼續”

三歪：“「每一次的修改」我們稱為一個版本，它能夠實現版本與版本之間的來回穿梭。打個比方，我有篇文章寫了一周，這期間有10個版本，我能隨意回到我想要的版本。所以它叫做版本控制軟件”

女朋友：“我大致聽懂了，大概就是每一次修改都會被記錄下來，然後你們就可以知道每一次版本修改了什麼，是誰改的，如果做錯了，可以通過這個軟件回到想要的版本”

三歪：“嗯，就是這個意思”

女朋友：“那我想問個問題，你一直提到的「多人協作」是在同一個目錄下對文件修改的，然後可以看到彼此改了什麼。那你是在你的電腦上改，你的同事是在他的電腦上改的，你們是怎麼看到彼此改了什麼？這現在有這麼厲害的東西了嗎？“

三歪：”哦~你的意思大概就是：我們又不聯網，怎麼知道對方改了什麼，是這個意思吧？“

女朋友：“嗯，是的”

三歪：“你的理解是沒錯的，我們之間不聯網，是沒辦法知道對方改了什麼的。我漏了一點沒說，我們在改到一定程度下（比如說這個功能我們做完了、也可能做得差不多了），我們會把當前版本提交到遠程倉庫上”

三歪繼續補充：“可以發現的是，提交到遠程倉庫后，即便我們電腦壞了，我們可以從遠程倉庫再把這份數據拉取下來。”

女朋友：“所以呢？遠程倉庫到我這聽起來就是一個備份的功能吧？你們怎麼知道對方改了什麼？”

三歪：“是這樣的，我們從遠程倉庫拉取代碼的時候除了會把有變動的代碼同步到自己的電腦上，還會把所有修改的記錄也同步到自己的電腦上。所以說，我們會知道彼此修改的內容。”

女朋友：”聽着很有用啊，我平時用的word和excel可以用這個軟件嗎？即便我電腦壞了，我還可以去『遠程倉庫』拿到上一次我提交的數據，並且還有你所說的『版本控制』功能。又能備份，又能知道每次修改了什麼，很好用啊！“

三歪：”很可惜，像你們那種工作場景，可能用不上，也可以說不太適合用“

女朋友：”為什麼？“

三歪：”之前我也想要用定時任務+GitHub的方式去保存我在本地寫的文章，發出來之後，被一頓噴。GitHub你可以簡單理解為就是那個遠程倉庫，定時任務我就是讓它隔一段時間就保存一次“

女朋友：”我聽明白了，你想要的是備份功能，對吧？為什麼被噴的呢？“

三歪：”他們說我瞎整，這每隔一段時間就提交到GitHub，網絡開銷可多大啊。然後給我列出一系列的產品，比如說：「堅果雲」「Dropbox」「OneDrive」等等“

女朋友：”那你怎麼不用？“

三歪：”我哪知道啊，有信息差的呢。反正當時覺得自己寫個定時任務實現了，就沒多想了。“

女朋友：”那你是真的菜“

三歪：”哦“

三歪：”除了上面說的自動同步，你們的word、excel在用我們的工具也沒法查到歷史的版本記錄“

女朋友：”為啥？你不是說你們寫代碼都可以的嗎？為什麼word和excel就沒法查？“

三歪：”我們寫代碼的文件類型都是屬於文本文件，而你的word、excel本質上屬於二進制文件，很難去比對每次修改的差異，所以不支持“

女朋友：”那聽你這樣說，在我的場景里這個「版本控制軟件」沒啥用啊，它不能記錄像Word、Excel這種文件每次版本的差異，要想用它做備份，還不如現有的雲產品。“

三歪：”嗯，是的。其實現在雲產品也能提供版本控制的功能了，你用它們就足夠了。還有一點很重要的是，它有學習成本，可不是每個人都會用的。“

女朋友：”聽你說了這麼多，好像雲產品就很行啊，為啥你們還要「偏執」去用你說的那東西？“

三歪：“主要是我們寫代碼時遇到的問題會更多，我們用的「版本控制軟件」會更加靈活，它支持的功能會更多。”

女朋友：“對了，你都說了這麼久了，你們用的那個軟件叫啥啊？”

三歪：“Git”

三歪瞎扯

其實本來想着直接講一下在工作中常用到的Git命令，但發現不太好寫（琢磨了很久

看三歪文章的人可能很多都是大學生，對Git本身了解可能就不太清楚，直接上Git的命令可能看不太懂，所以就分開了兩篇。

下一篇講一下三歪在工作中使用Git的糗事以及工作中是怎麼用Git的。

涵蓋Java後端所有知識點的開源項目（已有8K+ star）：

• GitHub
• Gitee訪問更快

我是三歪，一個想要變強的男人，感謝大家的點贊收藏和轉發，下期見。

本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理

【其他文章推薦】

※別再煩惱如何寫文案,掌握八大原則!

※網頁設計一頭霧水該從何著手呢? 台北網頁設計公司幫您輕鬆架站!

※超省錢租車方案

※教你寫出一流的銷售文案?

※網頁設計最專業,超強功能平台可客製化

※產品缺大量曝光嗎?你需要的是一流包裝設計!

本文始發於個人公眾號：TechFlow，原創不易，求個關注

Input: S = "ADOBECODEBANC", T = "ABC"
Output: "BANC"

# 存儲區間內的字符
segement = {}
for i in range(n):
    segement[s[i]] += 1
    # 當滿足條件的時候移動區間左側
    while l <= i and satisified(segment):
        # 更新最佳答案
        if i - l + 1 < ans_len:
            ans_len = i - l + 1
            beg, end = l, i + 1
        # 彈出元素
  segement[s[l]] -= 1
        l += 1

class Solution:
    def minWindow(self, s: str, t: str) -> str:
        from collections import Counter, defaultdict
        # 通過Counter直接獲取T當中的字符構成
        counter = Counter(t)
        n, m = len(s), len(counter)
        l, beg, end = 0, 0, 0
        cur = defaultdict(int)
        matched = 0
        flag = False
        # 記錄合法的字符串的長度
        ans_len = 0x3f3f3f3f
        
        for i in range(n):
            if s[i] not in counter:
                continue
                
            cur[s[i]] += 1
            # 當數量匹配上的時候，matched+1
            if cur[s[i]] == counter[s[i]]:
                matched += 1
                
            # 如果已經找到了合法的區間，嘗試縮短區間的長度
            while l <= i and matched == m:
                if i - l + 1 < ans_len:
                    flag = True
                    beg, end = l, i+1
                    ans_len = i - l + 1
                    
                # 彈出左側元素
                c = s[l]
                if c in counter:
                    cur[c] -= 1
                    if cur[c] < counter[c]:
                        matched -= 1
                        
                l += 1

        
        return "" if not flag else s[beg: end]

本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理

【其他文章推薦】

※教你寫出一流的銷售文案?

※廣告預算用在刀口上，台北網頁設計公司幫您達到更多曝光效益

※回頭車貨運收費標準

※別再煩惱如何寫文案,掌握八大原則!

※超省錢租車方案

※產品缺大量曝光嗎?你需要的是一流包裝設計!