در مورد ادامه ...
مقایسه مجوزهای سورس باز
تنظیم minheight برای سطرهای جدول
نگاهی به نحوهی عملکرد سرویسها و تزریق وابستگیها در AngularJS 2.0
فرض کنید کلاس سرویسی، به نحو ذیل تعریف شدهاست:
export class MyService {}
let svc = new MyService();
همچنین در این حالت، mocking این سرویس برای نوشتن unit tests نیز مشکل میباشد.
راه بهتر و توصیه شدهی در اینجا، ثبت و معرفی این سرویسها به AngularJS 2.0 است. سپس AngularJS 2.0 به ازای هر کلاس سرویس معرفی شدهی به آن، یک وهله/نمونه را ایجاد میکند. بنابراین طول عمر سرویسهای ایجاد شدهی در این حالت، singleton است (یکبار ایجاد شده و تا پایان طول عمر برنامه زنده نگه داشته میشوند).
پس از آن میتوان از تزریق کنندههای توکار AngularJS 2.0، جهت تزریق وهلههای این سرویسها استفاده کرد.
اکنون اگر کلاسی، نیاز به این سرویس داشته باشد، نیاز خود را به صورت یک وابستگی تعریف شدهی در سازندهی کلاس اعلام میکند:
constructor(private _myService: MyService){}
به این فرآیند اصطلاحا dependency injection و یا تزریق وابستگیها میگویند. در فرآیند تزریق وابستگیها، یک کلاس، وهلههای کلاسهای دیگر مورد نیاز خودش را بجای وهله سازی مستقیم، از یک تزریق کننده دریافت میکند. بنابراین بجای نوشتن newها در کلاس جاری، آنها را به صورت وابستگیهایی در سازندهی کلاس تعریف میکنیم تا توسط AngularJS 2.0 تامین شوند.
با توجه به اینکه طول عمر این وابستگیها singleton است و این طول عمر توسط AngularJS 2.0 مدیریت میشود، اطلاعات وهلههای سرویسهای مختلف و تغییرات صورت گرفتهی در آنها، بین تمام کامپوننتها به صورت یکسانی به اشتراک گذاشته میشوند.
به علاوه اکنون امکان mocking سرویسها با توجه به عدم وهله سازی آنها در داخل کلاسها به صورت مستقیم، سادهتر از قبل میسر است.
مراحل ساخت یک سرویس در AngularJS 2.0
ساخت یک سرویس در AngularJS 2.0، با ایجاد یک کلاس جدید شروع میشود. سپس متادیتای آن افزوده شده و در آخر موارد مورد نیاز آن import خواهند شد. با این موارد پیشتر در حین ساختن یک کامپوننت جدید و یا یک Pipe جدید آشنا شدهاید و این طراحی یک دست را در سراسر AngularJS 2.0 میتوان مشاهده کرد.
اولین سرویس خود را با افزودن فایل جدید product.service.ts به پوشهی app\products آغاز میکنیم؛ با این محتوا:
import { Injectable } from 'angular2/core'; import { IProduct } from './product'; @Injectable() export class ProductService { getProducts(): IProduct[] { return [ { "productId": 2, "productName": "Garden Cart", "productCode": "GDN-0023", "releaseDate": "March 18, 2016", "description": "15 gallon capacity rolling garden cart", "price": 32.99, "starRating": 4.2, "imageUrl": "app/assets/images/garden_cart.png" }, { "productId": 5, "productName": "Hammer", "productCode": "TBX-0048", "releaseDate": "May 21, 2016", "description": "Curved claw steel hammer", "price": 8.9, "starRating": 4.8, "imageUrl": "app/assets/images/rejon_Hammer.png" } ]; } }
همانند سایر ماژولهای تعریف شده، در اینجا نیز باید کلاس تعریف شده export شود تا در قسمتهای دیگر قابل استفاده و دسترسی گردد.
سپس در این سرویس، یک متد برای بازگشت لیست محصولات ایجاد شدهاست.
در ادامه یک decorator جدید به نام ()Injectable@ به بالای این کلاس اضافه شدهاست. این متادیتا است که مشخص میکند کلاس جاری، یک سرویس AngularJS 2.0 است.
البته باید دقت داشت که این مزین کننده تنها زمانی نیاز است حتما قید شود که کلاس تعریف شده، دارای وابستگیهای تزریق شدهای باشد. اما توصیه شدهاست که بهتر است هر کلاس سرویسی (حتی اگر دارای وابستگیهای تزریق شدهای هم نبود) به این decorator ویژه، مزین شود تا بتوان طراحی یک دستی را در سراسر برنامه شاهد بود.
در آخر هم موارد مورد نیاز، import میشوند. برای مثال Injectable در ماژول angular2/core تعریف شدهاست.
هدف از تعریف این سرویس، دور کردن وظیفهی تامین داده، از کلاس کامپوننت لیست محصولات است؛ جهت رسیدن به یک طراحی SOLID.
در قسمت بعدی این سری، این لیست را بجای یک آرایهی از پیش تعریف شده، از یک سرور HTTP دریافت خواهیم کرد.
ثبت و معرفی سرویس جدید ProductService به AngularJS 2.0 Injector
مرحلهی اول استفاده از سرویسهای تعریف شده، ثبت و معرفی آنها به AngularJS 2.0 Injector است. سپس این Injector است که تک وهلهی سرویس ثبت شدهی در آنرا در اختیار هر کامپوننتی که آنرا درخواست کند، قرار میدهد.
مرحلهی ثبت این سرویس، معرفی نام این کلاس، به خاصیتی آرایهای، به نام providers است که یکی از خواص decorator ویژهی Component است. بدیهی است هر کامپوننتی که در برنامه وجود داشته باشد، توانایی ثبت این سرویس را نیز دارد؛ اما باید از کدامیک استفاده کرد؟
اگر سرویس خود را در کامپوننت لیست محصولات رجیستر کنیم، تک وهلهی این سرویس تنها در این کامپوننت و زیر کامپوننتهای آن در دسترس خواهند بود و اگر این سرویس را در بیش از یک کامپوننت ثبت کنیم، آنگاه دیگر هدف اصلی طول عمر singleton یک سرویس مفهومی نداشته و برنامه هم اکنون دارای چندین وهله از سرویس تعریف شدهی ما میگردد و دیگر نمیتوان اطلاعات یکسانی را بین کامپوننتها به اشتراک گذاشت.
بنابراین توصیه شدهاست که از خاصیت providers کامپوننتهای غیر ریشهای، صرفنظر کرده و سرویسهای خود را تنها در بالاترین سطح کامپوننتهای تعریف شده، یعنی در فایل app.component.ts ثبت و معرفی کنید. به این ترتیب تک وهلهی ایجاد شدهی در اینجا، در این کامپوننت ریشهای و تمام زیر کامپوننتهای آن (یعنی تمام کامپوننتهای دیگر برنامه) به صورت یکسانی در دسترس قرار میگیرد.
به همین جهت فایل app.component.ts را گشوده و تغییرات ذیل را به آن اعمال کنید:
import { Component } from 'angular2/core'; import { ProductListComponent } from './products/product-list.component'; import { ProductService } from './products/product.service'; @Component({ selector: 'pm-app', template:` <div><h1>{{pageTitle}}</h1> <pm-products></pm-products> </div> `, directives: [ProductListComponent], providers: [ProductService] }) export class AppComponent { pageTitle: string = "DNT AngularJS 2.0 APP"; }
الف) خاصیت providers که آرایهای از سرویسها را قبول میکند، با ProductService مقدار دهی شدهاست.
ب) در ابتدای فایل، ProductService، از ماژول آن import گردیدهاست.
تزریق سرویسها به کامپوننتها
تا اینجا یک سرویس جدید را ایجاد کردیم و سپس آنرا به AngularJS 2.0 Injector معرفی نمودیم. اکنون نوبت به استفاده و تزریق آن، به کلاسی است که به این وابستگی نیاز دارد. در TypeScript، تزریق وابستگیها در سازندهی یک کلاس صورت میگیرند. هر کلاس، دارای متد سازندهای است که در زمان وهله سازی آن، اجرا میشود. اگر نیاز به تزریق وابستگیها باشد، تعریف این سازنده به صورت صریح، ضروری است. باید دقت داشت که هدف اصلی از متد سازنده، آغاز و مقدار دهی متغیرها و وابستگیهای مورد نیاز یک کلاس است و باید تا حد امکان از منطقهای طولانی عاری باشد.
در ادامه فایل product-list.component.ts را گشوده و سپس سازندهی ذیل را به آن اضافه کنید:
import { ProductService } from './product.service'; export class ProductListComponent implements OnInit { pageTitle: string = 'Product List'; imageWidth: number = 50; imageMargin: number = 2; showImage: boolean = false; listFilter: string = 'cart'; constructor(private _productService: ProductService) { }
روش خلاصه شدهای که در اینجا جهت تعریف سازندهی کلاس و متغیر تعریف شدهی در آن بکار گرفته شده، معادل قطعه کد متداول ذیل است و هر دو حالت ذکر شده، در TypeScript یکی میباشند:
private _productService: ProductService; constructor(productService: ProductService) { _productService = productService; }
این وابستگی در اولین باری که کلاس کامپوننت، توسط AngularJS 2.0 وهله سازی میشود، از لیست providers ثبت شدهی در کامپوننت ریشهی سایت، تامین خواهد شد.
اکنون نوبت به استفادهی از این سرویس تزریق شدهاست. به همین جهت ابتدا لیست عناصر آرایهی خاصیت products را حذف میکنیم (برای اینکه قرار است این سرویس، کار تامین اطلاعات را انجام دهد و نه کلاس کامپوننت).
products: IProduct[];
this.products = _productService.getProducts();
به همین جهت روش صحیح انجام این مقدار دهی، با پیاده سازی life cycle hook ویژهای به نام OnInit است که در قسمت پنجم آنرا معرفی کردیم:
export class ProductListComponent implements OnInit { products: IProduct[]; constructor(private _productService: ProductService) { } ngOnInit(): void { //console.log('In OnInit'); this.products = this._productService.getProducts(); }
در اینجا اکنون خاصیت products عاری است از ذکر صریح عناصر تشکیل دهندهی آن. سپس وابستگی مورد نیاز، در سازندهی کلاس تزریق شدهاست و در آخر، در رویداد چرخهی حیات ngOnInit، با استفاده از این وابستگی تزریقی، لیست محصولات دریافت و به خاصیت عمومی products نسبت داده شدهاست.
در ادامه برنامه را اجرا کنید. باید هنوز هم مطابق قبل، لیست محصولات قابل مشاهده باشد.
کدهای کامل این قسمت را از اینجا میتوانید دریافت کنید: MVC5Angular2.part7.zip
خلاصهی بحث
فرآیند کلی تعریف یک سرویس AngularJS 2.0، تفاوتی با ساخت یک کامپوننت یا Pipe سفارشی ندارد. پس از تعریف کلاسی که نام آن ختم شدهی به Service است، آنرا مزین به ()Injectable@ میکنیم. سپس این سرویس را در بالاترین سطح کامپوننتهای موجود یا همان کامپوننت ریشهی سایت، ثبت و معرفی میکنیم؛ تا تنها یک وهله از آن توسط AngularJS 2.0 Injector ایجاد شده و در اختیار تمام کامپوننتهای برنامه قرار گیرد. البته اگر این سرویس تنها در یک کامپوننت استفاده میشود و قصد به اشتراک گذاری اطلاعات آنرا نداریم، میتوان سطح سلسله مراتب دسترسی به آنرا نیز کاهش داد. برای مثال این سرویس را در لیست providers همان کامپوننت ویژه، ثبت و معرفی کرد. به این ترتیب تنها این کامپوننت خاص و فرزندان آن دسترسی به امکانات سرویس مدنظر را مییابند و نه تمام کامپوننتهای دیگر تعریف شدهی در برنامه.
در ادامه هر کلاسی که به این سرویس نیاز دارد (با توجه به سلسه مراتب دسترسی ذکر شده)، تنها کافی است در سازندهی خود، این وابستگی را اعلام کند تا توسط AngularJS 2.0 Injector تامین گردد.
شما برای کار با دیتا در اندروید، کدامیک از روش های زیر را استفاده میکنید یا ترجیح می دهید؟
صورت مساله
قصد داریم اطلاعاتی را با فرمت JSON، از یک API خارجی، توسط HttpClient دریافت و سپس آنرا به یک DTO فرضی، به نام GitHubRepositoryDto نگاشت کنیم.
راه حل 1
در این روش از وهله سازی مستقیم HttpClient به همراه استفادهی از یک عبارت using کمک گرفته شدهاست. همچنین چون عملیات async است، نتیجهی آنرا به کمک خاصیت Result دریافت کردهایم که پس از آن، کل اطلاعات دریافتی را به صورت یک رشته، در اختیار خواهیم داشت:
public class GitHubClient { public IReadOnlyCollection<GitHubRepositoryDto> GetRepositories() { using (var httpClient = new HttpClient{BaseAddress = new Uri(GitHubConstants.ApiBaseUrl)}) { var result = httpClient.GetStringAsync(GitHubConstants.RepositoriesPath).Result; return JsonConvert.DeserializeObject<List<GitHubRepositoryDto>>(result); } } }
- استفاده از خاصیت Result، هیچگاه ایدهی خوبی نبوده است و یک عملیات async را تبدیل به عملیاتی Blocking میکند که حتی میتواند سبب بروز dead-lock نیز شود.
- HttpClient نباید Dispose شود. علت آنرا در مطلب «روش استفادهی صحیح از HttpClient در برنامههای دات نت» مفصل بررسی کردهایم.
- دریافت کل response یک API به صورت یک رشتهی بزرگ، یک Large object heap را بهوجود میآورد که باز هم ایدهی خوبی نیست.
راه حل 2
اگر خاصیت Result راه حل 1 را حذف کنیم، به راه حل 2 خواهیم رسید:
public class GitHubClient : IGitHubClient { public async Task<IReadOnlyCollection<GitHubRepositoryDto>> GetRepositories() { using (var httpClient = new HttpClient { BaseAddress = new Uri(GitHubConstants.ApiBaseUrl) }) { var result = await httpClient.GetStringAsync(GitHubConstants.RepositoriesPath); return JsonConvert.DeserializeObject<List<GitHubRepositoryDto>>(result); } } }
- اینبار از دسترسی asynchronous واقعی استفاده شدهاست.
معایب:
- ایجاد و تخریب یک HttpClient جدید به ازای هر فراخوانی.
- دریافت و ذخیره سازی کل response به صورت یک رشته.
راه حل 3
در این نگارش، HttpClient از طریق وهله سازی در سازندهی کلاس دریافت شده و به این ترتیب امکان استفادهی مجدد را پیدا میکند:
public class GitHubClient : IGitHubClient { private readonly HttpClient _httpClient; public GitHubClient() { _httpClient = new HttpClient { BaseAddress = new Uri(GitHubConstants.ApiBaseUrl) }; } public async Task<IReadOnlyCollection<GitHubRepositoryDto>> GetRepositories() { var result = await _httpClient.GetStringAsync(GitHubConstants.RepositoriesPath).ConfigureAwait(false); return JsonConvert.DeserializeObject<List<GitHubRepositoryDto>>(result); } }
services.AddSingleton<GitHubClient>();
- دسترسی asynchronous واقعی به API مدنظر.
- استفادهی مجدد از HttpClient
معایب:
- دریافت و ذخیره سازی کل response به صورت یک رشته.
- چون طول عمر GitHubClient از نوع Singleton است و برای همیشه از یک وهلهی سراسری استفاده میکند، از تغییرات DNS آگاه نخواهد شد.
راه حل 4
تا اینجا همانطور که ملاحظه کردید، به سادگی میتوان HttpClient را به نحو نادرستی مورد استفاده قرار داد. ایجاد مجدد آن به علت عدم رها شدن بلافاصلهی سوکتهای لایهی زرین آن توسط سیستم عامل، مشکل حادی را به نام sockets exhaustion پدید میآورد. به همین جهت، این کلاس باید یکبار نمونه سازی شده و در طول عمر برنامه از همین تک وهلهی آن استفاده شود. یک روش اینکار تعریف آن به صورت اشیاء singleton و یا static است. مشکلی که این روش به همراه دارد، عدم باخبر شدن آن از تغییرات DNS است. برای رفع این مسایل، از NET Core 2.1. به بعد، خود مایکروسافت با ارائهی یک IHttpClientFactory، روش استانداری را برای مدیریت وهلههای HttpClient ارائه کردهاست:
public class GitHubClient : IGitHubClient { private readonly IHttpClientFactory _httpClientFactory; public GitHubClient(IHttpClientFactory httpClientFactory) { _httpClientFactory = httpClientFactory ?? throw new ArgumentNullException(nameof(httpClientFactory)); } public async Task<IReadOnlyCollection<GitHubRepositoryDto>> GetRepositories() { var httpClient = _httpClientFactory.CreateClient("GitHub"); var result = await httpClient.GetStringAsync(GitHubConstants.RepositoriesPath).ConfigureAwait(false); return JsonConvert.DeserializeObject<List<GitHubRepositoryDto>>(result); } }
services.AddHttpClient("GitHub", x => { x.BaseAddress = new Uri(GitHubConstants.ApiBaseUrl); }); services.AddSingleton<GitHubClient>();
مزیتها:
- استفادهی از یک IHttpClientFactory توکار
معایب:
- استفادهی یک از کلاینت نامدار، بجای یک کلاینت مشخص شدهی بر اساس نوع آن.
- دریافت و ذخیره سازی کل response به صورت یک رشته.
روش ثبت services.AddHttpClient را که در اینجا ملاحظه میکنید، یک روش ثبت نامدار است و بر اساس نام رشتهای GitHub کار میکند. همین نام در متد GetRepositories به صورت httpClientFactory.CreateClient("GitHub") برای دسترسی به یک HttpClient جدید استفاده شدهاست.
راه حل 5
در اینجا از یک کلاینت نوعدار، بجای یک کلاینت نامدار، استفاده شدهاست:
public class GitHubClient : IGitHubClient { private readonly HttpClient _httpClient; public GitHubClient(HttpClient httpClient) { _httpClient = httpClient ?? throw new ArgumentNullException(nameof(httpClient)); } public async Task<IReadOnlyCollection<GitHubRepositoryDto>> GetRepositories() { var result = await _httpClient.GetStringAsync(GitHubConstants.RepositoriesPath).ConfigureAwait(false); return JsonConvert.DeserializeObject<List<GitHubRepositoryDto>>(result); } }
services.AddHttpClient<GitHubClient>(x => { x.BaseAddress = new Uri(GitHubConstants.ApiBaseUrl); });
مزایا:
- استفاده از IHttpClientFactory
- استفاده از یک کلاینت نوعدار، بجای یک نمونهی نامدار
معایب:
- اینبار تمام استفاده کنندگان از IGitHubClient ما باید دارای طول عمر transient باشند (خصوصیت کلاینتهای نوعدار است)؛ برخلاف راه حلهای پیشین که میتوانستند singleton تعریف شوند (یا امکان فراخوانی IGitHubClient از سرویسهای singleton نیز وجود داشت).
- دریافت و ذخیره سازی کل response به صورت یک رشته.
راه حل 6
اگر در جائی نیاز به استفاده و تزریق یک کلاینت نوعدار، در یک سرویس با طول عمر singleton را داشتید، روش آن به صورت زیر است:
public class GitHubClientFactory { private readonly IServiceProvider _serviceProvider; public GitHubClientFactory(IServiceProvider serviceProvider) { _serviceProvider = serviceProvider; } public GitHubClient Create() { return _serviceProvider.GetRequiredService<GitHubClient>(); } }
services.AddHttpClient<GitHubClient>(x => { x.BaseAddress = new Uri(GitHubConstants.ApiBaseUrl); }); services.AddSingleton<GitHubClientFactory>();
مزایا:
- استفاده از IHttpClientFactory
- استفاده از یک کلاینت نوعدار
- استفاده کنندهی از GitHubClientFactory، میتوانند طول عمر singleton نیز داشته باشد
معایب:
- دریافت و ذخیره سازی کل response به صورت یک رشته.
راه حل 7
از اینجا به بعد، هدف ما بهینه سازی عملیات است و رفع مشکل کار با یک رشتهی بزرگ. برای این منظور بجای متد GetStringAsync، از متد SendAsync که امکان streaming را فراهم میکند، استفاده خواهیم کرد. به این ترتیب، بجای ارسال یک رشتهی بزرگ به متد Deserialize، امکان دسترسی به استریم response را توسط آن میسر کردهایم.
public class GitHubClient : IGitHubClient { private readonly HttpClient _httpClient; private readonly JsonSerializer _jsonSerializer; public GitHubClient(HttpClient httpClient, JsonSerializer jsonSerializer) { _httpClient = httpClient ?? throw new ArgumentNullException(nameof(httpClient)); _jsonSerializer = jsonSerializer ?? throw new ArgumentNullException(nameof(jsonSerializer)); } public async Task<IReadOnlyCollection<GitHubRepositoryDto>> GetRepositories() { var request = CreateRequest(); var result = await _httpClient.SendAsync(request, HttpCompletionOption.ResponseContentRead); using (var responseStream = await result.Content.ReadAsStreamAsync()) { using (var streamReader = new StreamReader(responseStream)) using (var jsonTextReader = new JsonTextReader(streamReader)) { return _jsonSerializer.Deserialize<List<GitHubRepositoryDto>>(jsonTextReader); } } } private static HttpRequestMessage CreateRequest() { return new HttpRequestMessage(HttpMethod.Get, GitHubConstants.RepositoriesPath); } }
services.AddHttpClient<GitHubClient>(x => { x.BaseAddress = new Uri(GitHubConstants.ApiBaseUrl); }); services.AddSingleton<GitHubClientFactory>(); services.AddSingleton<JsonSerializer>();
- کار با IHttpClientFactory
- استفاده از یک کلاینت نوعدار
- کار با استریم response
معایب:
- استفاده از ResponseContentRead
راه حل 8
در این روش بجای سطر ذیل در راه حل 7
var result = await _httpClient.SendAsync(request, HttpCompletionOption.ResponseContentRead);
var result = await _httpClient.SendAsync(request, HttpCompletionOption.ResponseHeadersRead);
مزایا:
- کار با IHttpClientFactory
- استفاده از یک کلاینت نوعدار
- کار با استریم response
- استفاده از ResponseHeadersRead
معایب:
- شاید بتوان از کتابخانهی دیگری برای json deserialization استفاده کرد؟
ساختار دادهها چیست؟
نوع داده انتزاعی Abstraction Data Type -ADT
- خطی یا Linear: شامل ساختارهایی چون لیست و صف و پشته است: List ,Queue,Stack
- درختی یا Tree-Like: درخت باینری ، درخت متوازن و B-Trees
- Dictionary : شامل یک جفت کلید و مقدار است در جدول هش
- بقیه: گرافها، صف الویت، bags, Multi bags, multi sets
(void Add(object | افزودن المان به آخر لیست |
(void Remove(object | حذف یک المان خاص از لیست |
()void Clear | حذف کلیه المانها |
( bool Contains(object | شامل این داده میشود یا خیر؟ |
( void RemoveAt(int | حذف یک المان بر اساس جایگاه یا اندیسش |
(void Insert(int, object | افزودن یک المان در جایگاهی (اندیس) خاص بر اساس مقدار position |
(int IndexOf(object | اندیس یا جایگاه یک عنصر را بر میگرداند |
[this[int | ایندکسر ، برای دستریس به عنصر در اندیس مورد نظر |
لیستهای ایستا static Lists
public class CustomArrayList<T> { private T[] arr; private int count; public int Count { get { return this.count; } } private const int INITIAL_CAPACITY = 4; public CustomArrayList(int capacity = INITIAL_CAPACITY) { this.arr = new T[capacity]; this.count = 0; }
public void Add(T item) { GrowIfArrIsFull(); this.arr[this.count] = item; this.count++; } public void Insert(int index, T item) { if (index > this.count || index < 0) { throw new IndexOutOfRangeException( "Invalid index: " + index); } GrowIfArrIsFull(); Array.Copy(this.arr, index, this.arr, index + 1, this.count - index); this.arr[index] = item; this.count++; } private void GrowIfArrIsFull() { if (this.count + 1 > this.arr.Length) { T[] extendedArr = new T[this.arr.Length * 2]; Array.Copy(this.arr, extendedArr, this.count); this.arr = extendedArr; } } public void Clear() { this.arr = new T[INITIAL_CAPACITY]; this.count = 0; }
برای پیاده سازی آن به دو کلاس نیاز داریم. کلاس ListNode برای نگهداری هر المان و اطلاعات المان بعدی به کار میرود که از این به بعد به آن Node یا گره میگوییم و دیگری کلاس <DynamicList<T برای نگهداری دنباله ای از گرهها و متدهای پردازشی آن.
public class DynamicList<T> { private class ListNode { public T Element { get; set; } public ListNode NextNode { get; set; } public ListNode(T element) { this.Element = element; NextNode = null; } public ListNode(T element, ListNode prevNode) { this.Element = element; prevNode.NextNode = this; } } private ListNode head; private ListNode tail; private int count; // … }
از آن جا که نیازی نیست کاربر با کلاس ListNode آشنایی داشته باشد و با آن سر و کله بزند، آن را داخل همان کلاس اصلی به صورت خصوصی استفاده میکنیم. این کلاس دو خاصیت دارد؛ یکی برای المان اصلی و دیگر گره بعدی. این کلاس دارای دو سازنده است که اولی تنها برای عنصر اول به کار میرود. چون اولین بار است که یک گره ایجاد میشود، پس باید خاصیت NextNode یعنی گره بعدی در آن Null باشد و سازندهی دوم برای گرههای شماره 2 به بعد به کار میرود که همراه المان داده شده، گره قبلی را هم ارسال میکنیم تا خاصیت NextNode آن را به گره جدیدی که میسازیم مرتبط سازد. سه خاصیت کلاس اصلی به نامهای Count,Tail,Head به ترتیب برای اشاره به اولین گره، آخرین گره و تعداد گرهها، به کار میروند که در ادامه کد آنرا در زیر میبینیم:
public DynamicList() { this.head = null; this.tail = null; this.count = 0; } public void Add(T item) { if (this.head == null) { this.head = new ListNode(item); this.tail = this.head; } else { ListNode newNode = new ListNode(item, this.tail); this.tail = newNode; } this.count++; }
سازنده مقدار دهی پیش فرض را انجام میدهد. در متد Add المان جدیدی باید افزوده شود؛ پس چک میکند این المان ارسالی قرار است اولین گره باشد یا خیر؟ اگر head که به اولین گره اشاره دارد Null باشد، به این معنی است که این اولین گره است. پس اولین سازندهی کلاس ListNode را صدا میزنیم و آن را در متغیر Head قرار میدهیم و چون فقط همین گره را داریم، پس آخرین گره هم شناخته میشود که در tail نیز قرار میگیرد. حال اگر فرض کنیم المان بعدی را به آن بدهیم، اینبار دیگر Head برابر Null نخواهد بود. پس دومین سازندهی ListNode صدا زده میشود که به غیر از المان جدید، باید آخرین گره قبلی هم با آن ارسال شود و گره جدیدی که ایجاد میشود در خاصیت NextNode آن نیز قرار بگیرد و در نهایت گره ایجاد شده به عنوان آخرین گره لیست در متغیر Tail نیز قرار میگیرد. در خط پایانی هم به هر مدلی که المان جدید به لیست اضافه شده باشد متغیر Count به روز میشود.
public T RemoveAt(int index) { if (index >= count || index < 0) { throw new ArgumentOutOfRangeException( "Invalid index: " + index); } int currentIndex = 0; ListNode currentNode = this.head; ListNode prevNode = null; while (currentIndex < index) { prevNode = currentNode; currentNode = currentNode.NextNode; currentIndex++; } RemoveListNode(currentNode, prevNode); return currentNode.Element; } private void RemoveListNode(ListNode node, ListNode prevNode) { count--; if (count == 0) { this.head = null; this.tail = null; } else if (prevNode == null) { this.head = node.NextNode; } else { prevNode.NextNode = node.NextNode; } if (object.ReferenceEquals(this.tail, node)) { this.tail = prevNode; } }
برای حذف یک گره شماره اندیس آن گره را دریافت میکنیم و از Head، گره را بیرون کشیده و با خاصیت nextNode آنقدر به سمت جلو حرکت میکنیم تا متغیر currentIndex یا اندیس داده شده برابر شود و سپس گره دریافتی و گره قبلی آن را به سمت تابع RemoveListNode ارسال میکنیم. کاری که این تابع انجام میدهد این است که مقدار NextNode گره فعلی که قصد حذفش را داریم به خاصیت Next Node گره قبلی انتساب میدهد. پس به این ترتیب پیوند این گره از لیست از دست میرود و گره قبلی به جای اشاره به این گره، به گره بعد از آن اشاره میکند. مابقی کد از قبیل جست و برگردان اندیس یک عنصر و ... را به خودتان وگذار میکنم.
در روشهای بالا ما خودمان 2 عدد ADT را پیاده سازی کردیم و متوجه شدیم برای دخیره دادهها در حافظه روشهای متفاوتی وجود دارند که بیشتر تفاوت آن در مورد استفاده از حافظه و کارآیی این روش هاست.
لیستهای پیوندی دو طرفه Doubly Linked_List
لیستهای پیوندی بالا یک طرفه بودند و اگر ما یک گره را داشتیم و میخواستیم به گره قبلی آن رجوع کنیم، اینکار ممکن نبود و مجبور بودیم برای رسیدن به آن از ابتدای گره حرکت را آغاز کنیم تا به آن برسیم. به همین منظور مبحث لیستهای پیوندی دو طرفه آغاز شد. به این ترتیب هر گره به جز حفظ ارتباط با گره بعدی از طریق خاصیت NextNode، ارتباطش را با گره قبلی از طریق خاصیت PrevNode نیز حفظ میکند.
این مبحث را در اینجا میبندیم و در قسمت بعدی آن را ادامه میدهیم.