حمله چینیها به سایتهای ایرانی !
آموزش های تکمیلی سیلورلایت
dotnet add package Microsoft.AspNetCore.DataProtection.EntityFrameworkCore
public class MyKeysContext : DbContext, IDataProtectionKeyContext { // A recommended constructor overload when using EF Core // with dependency injection. public MyKeysContext(DbContextOptions<MyKeysContext> options) : base(options) { } // This maps to the table that stores keys. public DbSet<DataProtectionKey> DataProtectionKeys { get; set; } }
public int Id { get; set; } public string FriendlyName { get; set; } public string XmlData { get; set; }
public void ConfigureServices(IServiceCollection services) { // using Microsoft.AspNetCore.DataProtection; services.AddDataProtection() .PersistKeysToDbContext<MyKeysContext>(); }
چون در شروع کار تجربه خوبی نداشتم و از حجم اطلاعات مطمئن نبودم روی دیتابیسم pk نذاشتم حالا که میخوام pk و ایندکس گذاریش کنم برای هر جدول یک filegroup و در هر فایل گروپ یک فایل برای pk و یک فایل برای indexها گذاشتم و تقریبا هر کدوم از اون جدوال بزرگ را به 30 تا جدول تقسیم کردم تا سرعت پرس و جوهای زیادم بسیار کمتر بشه که به نظرم خوب نمیاومد (کار پرس و جو و ایجاد کوئری را دشوارتر میکنه) تا با راه حل شما اشنا شدم اما سوالم اینجاست اگر داده هام رو بر اساس تاریخ در datafileها پارتیشن بندی کنم زمانی که بخوام مثلا اطلاعات تا قبل از سال 85 را ارشیو کنم تاثیری در زمان پرس و جوی من دارد و کلیدها و ایندکسها وضعیتشون به چه شکل خواهد بود اگر از راه حل خودم استفاده نکنم چون همینجوریش حجم دیتابیسم 35 گیگه و با گذاشتن کلید و ایندکس چیزی بین 15 تا 20 گیگ هم اضافه میشه که خیلی بد هست.
الان که یه خورده رو کدها کار کردم یه سوال برام پیش اومد مثالی میزنم من جدولی دارم که تاریخ را با نام شرکت میگیره و یک کد گزارش میده حالا من این کد گزارش را با مثلا 10 هزار رکورد در جدول دوم ذخیره میکنم و و باز با همون کد گزارش 5000 رکورد را در جدول سوم ذخیره میکنم و به همین ترتیب برای تمام روزها و برای کل شرکتها این کد گزارش تولید و با حجم انبوهی از رکوردها در جداول ذخیره میشن
حالا سوال اینه که چطور بر اساس تاریخ که در جدول فقط اول هست جداول دیگر را پارتیشن بندی کنم ؟
C# 7.1 - async Main
نحوهی کار با متدهای async، در متدهای Main نگارشهای پیش از C# 7.1
برای کار با متدهای Async نیاز است از واژهی کلیدی await استفاده شود و با قید این واژه، ضروری است واژهی کلیدی async نیز به امضای متد دربرگیرندهی عملیات اضافه گردد؛ اما در نگارشهای پیشین زبان #C، امکان async تعریف کردن متد Main وجود نداشت. در این حالت میبایستی به صورت ذیل عمل میشد:
static void Main(string[] args) { MainAsync().GetAwaiter().GetResult(); Console.ReadLine(); } private static async Task MainAsync() { using (StreamReader reader = File.OpenText("Program.cs")) { var message = await reader.ReadToEndAsync().ConfigureAwait(false); Console.Write(message); } }
نحوهی کار با متدهای async در متدهای Main برنامههای مبتنی بر C# 7.1
در زبان سیشارپ، متدهای Main برنامههای کنسول میتوانند خروجیهایی از نوع void و int داشته باشند؛ به همراه آرگومانی از نوع []string و یا بدون آرگومان. اکنون در سیشارپ 7.1، دو امضای دیگر نیز به این مجموعه، جهت کار با اعمال Async اضافه شدهاست: async Task و یا <async Task<int
در این حالت مثال قبل را میتوان به صورت ذیل خلاصه کرد:
static async Task Main(string[] args) { using (StreamReader reader = File.OpenText("Program.cs")) { var message = await reader.ReadToEndAsync().ConfigureAwait(false); Console.Write(message); } Console.ReadLine(); }
نگاهی به پشت صحنهی کامپایل async Task Main در C# 7.1
در عمل، کامپایلر سیشارپ جهت حفظ سازگاری با نگارشهای قبلی، مجددا همان متد static void Main را تولید میکند و عملیاتی را که در مورد نگارشهای پیشین توضیح داده شد، تکرار خواهد کرد:
using System; using System.IO; using System.Runtime.CompilerServices; using System.Threading.Tasks; namespace ConsoleCS71 { internal class Program { private static async Task Main(string[] args) { StreamReader reader = File.OpenText("message.txt"); try { string str = await reader.ReadToEndAsync(); string message = str; str = (string)null; Console.Write(message); message = (string)null; } finally { if (reader != null) reader.Dispose(); } reader = (StreamReader)null; Console.ReadLine(); } [SpecialName] private static void <Main>(string[] args) { Program.Main(args).GetAwaiter().GetResult(); } } }
در یک برنامهی سیشارپ میتوان بیش از یک متد Main داشت
تعریف بیش از یک متد Main در برنامههای سیشارپ مجاز است:
namespace ConsoleApp5 { class Class1 { static void Main(string[] args) { } } class Class2 { static void Main(string[] args) { } } }
اما ... اگر دقت کنید، متد async Task Main در اینجا ایندکس نشدهاست که به نظر کمبود نگارش فعلی VS 2017 است.
کنترلهای زیر جهت ورود اطلاعات در ویرایشگر پشتیبانی میشوند:
- text
- textarea
- select
- date
- datetime
- dateui
- combodate
- html5types
- checklist
- wysihtml5
- typeahead
- typeaheadjs
- select2
clear | دکمهای جهت حذف محتوای کادر متنی است. مقدار پیش فرض آن true است. |
escape | برای
دفاع در برابر کدهای مخرب html به کار میرود و کاراکترهای مدنظر را در صورت
true بودن غیرفعال میکند. البته اگر از خاصیت display استفاده کنید این
گزینه تاثیرش را از دست خواهد داد. |
inputclass | یک کلاس css را به کادر متنی اعمال میکند. |
placeholder | مقدار داده شده را در صورتی که کادر متنی خالی باشد، نشان میدهد. |
tpl | به معنی یک قالب. شما میتوانید کد html تگ input خود را وارد کنید؛ ولی توصیه نمیشود. |
TextArea
همان خاصیتهای قبلی را دارد بعلاوه rows که نمایانگر مقدار ارتفاع آن است.
select
خاصیتهای escape,input,class و tpl را دارد بهعلاوه خاصیتهای زیر:
prepend | همانند گزینه پایینی است ولی قبل از آن دادههای خود را اضافه میکند. |
source | از
آنجا که یک لیست، لیستی از آیتمها را دارد و کاربر یکی از آنها را
انتخاب میکند، این بخش، منبع آیتمها را معرفی میکند. این خاصیت چهار نوع
داده میپذیرد: آرایه یا شیءایی از مقادیر. تابعی که بعد از انجام هر عملی،
اطلاعات به آن پاس میشوند و یا از نوع رشته که این رشته یک آدرس سمت سرور
است که با درخواست از آن آدرس، اطلاعات را دریافت میکند. |
sourceCache | اگه خاصیت بالا با آدرسی پر شده باشد که از سمت سرور بخواند، در دفعات بعدی مقدار دریافتی را از کش خواهد خواند. |
sourceError | یک پیام خطا هنگام بارگزاری اطلاعات |
sourceOptions | در
صورتیکه قصد اضافه کردن پارامتری را به درخواست ایجکسی دارید. یک شیء از پارامترها را به آن
نسبت میدهیم و برای رونویسی پارامترها از یک تابع استفاده میکنیم که نحوهی تغییرات را قبلا در جدول شماره یک دیدهاید. |
date
خاصیتهای مشترک قبلی : tpl,input,class,escape و clear است.
datepicker | پیکربندی تقویم را بر عهده دارد. برای اطلاعات بیشتر در مورد پیکربندی تقویم به این لینک مراجعه فرمایید.{ weekStart: 0, startView: 0, minViewMode: 0, autoclose: false } |
format | قالب بندی فرمت تاریخ جهت ارسال به سرور\ حالت پیش فرض yyyy-mm-dd مقادیری که میتوان به کار برد: yy yyyy mm m dd d |
viewformat | این فرمت هنگام نمایش به کار میآید و در صورتیکه مقدار عنصر در این قالب نباشد، آن را تبدیل میکند. |
datetime در بوت استراپ
کاملا مشترک با مورد قبلی.
dateUI
مختص JqueryUI است و کاملا مشترک با مورد قبلی.
combodate
موارد مشترک قبلی را دارد ولی به جای خاصیت datepicker از combodate استفاده میشود که پیکربندی آن در این لینک قرار دارد.
نوعهای HTML 5
شامل موارد زیر است:
- password
- url
- tel
- number
- range
- time
خاصیتهای ذکر شده در مورد نوع text، در مورد آنها نیز صدق میکند.
checklist
همانند نوع select است؛ فقط خاصیت separator را دارد که کارش جدا کردن مقادیر است و مقدار پیش فرض آن علامت ',' است.
wysihtml5
سورس و دمو ی این نوع ادیتور که بر پایهی بوت استرپ بنا شده است و زحمت اضافه کردن کتابخانهها به صفحه، بر عهده شماست.
مداخل زیر را به طور دستی به صفحه اضافه کنید:
<link href="js/inputs-ext/wysihtml5/bootstrap-wysihtml5-0.0.2/bootstrap-wysihtml5-0.0.2.css" rel="stylesheet" type="text/css"></link> <script src="js/inputs-ext/wysihtml5/bootstrap-wysihtml5-0.0.2/wysihtml5-0.3.0.min.js"></script> <script src="js/inputs-ext/wysihtml5/bootstrap-wysihtml5-0.0.2/bootstrap-wysihtml5-0.0.2.min.js"></script>
<script src="js/inputs-ext/wysihtml5/wysihtml5.js"></script>
typeahead
این گزینه فقط مختص بوت استرپ 2 است و یک کنترل autocomplete به شمار میآید. منبع دادههای آن از طریق خاصیت source به دو صورت آرایه و object تامین میگردد.
['text1', 'text2', 'text3' ...] //or [{value: 1, text: "text1"}, {value: 2, text: "text2"}, ...]
typeaheadjs
همانند قبلی است و بر اساس twitterBootstrap است و شامل همان خصوصیات قبلی است. تنها خصوصیت typeahead آن است که باید از این پیکربندی استفاده کنید.
Select2
این المان بر اساس این کتابخانه سورس باز ایجاد میشود. و مستندات آن شامل جزئیات و پیکربندی آن میشود. برای معرفی آن فایلهای زیر را به صفحه معرفی کنید.
<link href="select2/select2.css" rel="stylesheet" type="text/css"></link> <script src="select2/select2.js"></script>
<link href="select2-bootstrap.css" rel="stylesheet" type="text/css"></link>
نکته: در حال حاضر خاصیت autotext روی این المان جواب نمیدهد و میتوانید از خاصیت data-value به جای آن استفاده کنید.
قالبی نو برای ویرایشگر
ویرایشگر فعلی ما به خصوص در بوت استرپ، ظاهر فوق العادهای دارد. ولی اگر بازهم مایل به تغییر و رونویسی هستید، این امکان فراهم شده است.
fn.editableform.template$
مقدار پیش فرض آن که حتما باید شامل تگ فرم و کلاسهای مدنظر باشد:
<form> <div> <div><div></div><div></div></div> <div></div> </div> </form>
- control-group
- editable-input
- editable-buttons
- editable-error-block
fn.editableform.buttons$
<button type="submit">ok</button> <button type="button">cancel</button>
و نهایتا جهت تغییر loading
fn.editableform.loading$
<div></div>
گاهی اوقات نیاز است که خصوصیات این ویرایشگر را در شرایط متغیر صفحه کنترل کنیم، برای مثال گاهی پیش میآید که بخواهید در یک شرایط خاص ویرایشگر یک المان خاص را غیرفعال کنید. کد زیر مثال این تغییرات است.
$('#favsite').editable('option', 'disabled', false);
متدها و رویدادها
متدهایی که روی آن قابل اجراست:
editable | ویرایشگر را بر اساس مقادیر اولیه روی عنصر مشخص شده فعال میکند. |
() activate | فوکوس را به input ویرایشگر باز میگرداند. |
() destory | حذف ویژگی ویرایش از روی عنصر |
() disable | غیرفعال کردن ویرایشگر |
() enable | فعال سازی آن |
()getvalue | باعث بازگردانی
مقدار جاری همه عناصر توسط شیء جفت کلید مقدار میشود و عناصری که شامل
متن یا مقداری نیستند، از آن حذف میشوند. در صورتیکه قصد دارید مقدار تنها
یک عنصر قابل دریافت باشد، با خاصیت isSingle آن را true کنید. $('#username, #fullname').editable('getValue'); //result: { username: "superuser", fullname: "John" } //isSingle = true $('#username').editable('getValue', true); //result "superuser" |
()hide | مخفی کردن تگ فرم ویرایشگر |
(option(key,value | تغییر خصوصیات یک عنصر که در بالا هم نمونه کد آن را دیدیم. |
(setvalue(value,convertStr | ست کردن مقدار جدید کنترل و پارامتر دوم وضعیت تبدیل این مقدار به فرمت داخلی است که برای آن تعریف شده است مثل date |
() show | نمایش ویرایشگر |
( submit(options | در
صورتی که خاصیت ارسال خودکار به سمت سرور را غیر فعال کرده باشید، با این
گزینه میتوانید همه اطلاعات و تغییرات را ارسال کنید. برای ایجاد فرم بر
اساس ویرایشگرها و ارسال اطلاعات با کلیک بر روی دکمه submit کاربرد دارد. یک مثال
در این زمینه . پارامترهای options به شرح زیر هستند: url data ajaxoptions (error(obj (success(obj,config از نسخه 1.5.1 میتوان این گزینه را به راحتی روی یک المان خاص هم صدا زد: $('#username').editable('submit') |
() toggle | کدی که صدا زده میشود بین دو وضعیت show و hide سوئیچ میکند. |
() toggleDisabled | تغییر وضعیت بین دو حالت enable و disable |
() validate | انجام اعتبارسنجی بر روی همه کنترل ها.$('#username, #fullname').editable('validate'); // possible result: { username: "username is required", fullname: "fullname should be minimum 3 letters length" } |
رویدادها
hidden | این
رویداد زمانی رخ میدهد که ویرایشگر دیگر قابل مشاهده نیست و شامل دو پارامتر
event و reason است. reason دلیل اینکه چرا ویرایشگر از دید خارج شده است
را با یکی از گزینههای زیر مشخص میکند. save cancel onblur nochange manual $('#username').on('hidden', function(e, reason) { if(reason === 'save' || reason === 'cancel') { //auto-open next editable $(this).closest('tr').next().find('.editable').editable('show'); } }); |
init | موقعی صدا زده میشود که متد editable روی عنصر صدا زده میشود و به یاد داشته باشید که این رویداد باید قبل از آن ست شده باشد.$('#username').on('init', function(e, editable) { alert('initialized ' + editable.options.name); }); $('#username').editable(); |
save | موقعی
که مقدار جدید، با موفقیت تایید میشود. دو پارامتر event و params را باز
میگرداند که params شامل دو خصوصیت newValue و response است که به ترتیب
مقدار جدید و اطلاعات برگشت داده شده از درخواست آژاکس است.$('#username').on('save', function(e, params) { alert('Saved value: ' + params.newValue); }); |
shown | موقعیکه ویرایشگر نمایش مییابد و فرم با موفقیت رندر شده است. برای اشیایی چون select باید صبر کنید تا مقادیر آنها بارگذاری شوند.$('#username').on('shown', function(e, editable) { editable.input.$input.val('overwriting value of input..'); }); |
حل مشکل این ابزار در کندو
موقعیکه من این ابزار را بر روی treeview قرار دادم، به این مشکل برخوردم که اطراف پنجره باز شده، توسط حاشیههای treeview محدود شده است و مطابق شکل زیر قسمتهایی از آن دیده نمیشود. به همین علت cssهای کندو را به اندازه یک خط ویرایش کردم.
برای حل این مشکل فایل kendo.common-xxx را باز کنید. xxx بر اساس قالبی که برای کندو انتخاب کردهاید، میتواند متفاوت باشد. در مثالهای کندو عموما این xxx به نام default شناخته میشود یا برای مثال من، bootstrap بود.
بعد از اینکه باز کردید، به دنبال چنین استایلی بگردید:
div.k-treeview{ border-width: 0px; background: transparent none repeat scroll 0px center; overflow: auto; white-space: nowrap; }
overflow: auto;
نکته بعدی اینکه وقتی ویرایشگر در حالت popup قرار میگیرد، مقدار خاصیت title نمایش مییابد که عموما با مضامینی چون "کلمه جدید را وارد نمایید" و ... پر میشود که به طور پیش فرض سمت چپ قرار گرفته است. کد زیر را در صفحه وارد کنید تا متن در سمت راست قرار بگیرد:
.popover-title { text-align: right; }
ترجمه بخشی از متن اصلی به نقل از خبرگزاری دانشجو :
یافته تکان دهنده کسپراسکای این است که Equation قابلیت آلوده کردن سفتافزار یک درایو سخت یا کد سطح پایینی که نقش واسط بین سختافزار و نرمافزار را بازی میکند را داراست.
این بدافزار سفتافزار درایو سخت را برنامهریزی مجدد میکند و سکتورهای پنهانی روی درایو ایجاد میکند که فقط میتوانند از طریق یک API سری مورد دسترسی قرار گیرند. حذف این بدافزار پس از نصب غیرممکن است، فرمت کردن دیسک و نصب مجدد سیستم عامل هیچ تأثیری بر روی آن ندارد و سکتورهای پنهان همچنان باقی میمانند.
درایوهای ساخته شده توسط سیگیت، وسترن دیجیتال، هیتاچی، سامسونگ، آیبیام، میکرون و توشیبا میتوانند توسط ۲ پلتفورم بدافزار Equation یعنی Equationdrug و Grayfish دستکاری شوند.
بنا بر این گزارش، Equation دانشی از این درایوها در اختیار دارد که بسیار بیشتر از اسناد عمومی منتشر شده توسط تولید کنندگان آنها است.
Equation مجموعه دستورات ATA یکتای مورد استفاده توسط تولید کنندگان درایوهای سخت را برای فرمت کردن محصولات آنها میداند. اغلب دستورات ATA عمومی هستند، چرا که از استانداردی استفاده میکنند که این اطمینان را ایجاد میکند که درایو سخت با هر نوع کامپیوتری سازگار است. اما دستورات ATA ی غیر مستندی وجود دارند که توسط تولید کنندگان برای اعمالی مانند ذخیرهسازی داخلی و تصحیح خطا به کار میروند. در حقیقت، آنها یک سیستم عامل بسته هستند. دستیابی به چنین کدهای ATA، نیازمند دسترسی به این اسناد است که هزینه زیادی در بر دارد. احتمال اینکه کسی بتواند با استفاده از اطلاعات عمومی، سیستم عامل درایو سخت را بازنویسی کند تقریباً صفر است.
بنا بر اظهارات رایو، قابلیت برنامهریزی مجدد سفتافزار فقط یک مدل درایو سخت به طرز باورنکردنی پیچیده است. اما دارا بودن چنین قابلیتی برای انواع زیادی از درایوها از تولیدکنندگان مختلف تقریباً غیرممکن است.
به نظر میرسد که Equation بسیار بسیار جلوتر از صنعت امنیت است. تشخیص این نوع نفوذ تقریباً غیرممکن است. پاک کردن کامل درایو یا تعویض سفتافزار آن نیز چندان مفید نیست، چرا که برخی از انواع ماژولها در برخی سفتافزارها دائمی هستند و نمیتوانند مجدداً فرمت گردند.
همانطور که قول داده بودم، به اصول GRASP میپردازیم.
اصول GRASP-General Responsibility Assignment
Software Principles
این اصول به بررسی نحوه تقسیم وظایف بین کلاسها و مشارکت اشیاء برای به انجام رساندن یک مسئولیت میپردازند. اینکه هر کلاس در ساختار نرم افزار چه وظیفهای دارد و چگونه با کلاسهای دیگر مشارکت میکند تا یک عملکرد به سیستم اضافه گردد. این اصول به چند بخش تقسیم میشوند:
- کنترلر ( Controller )
- ایجاد کننده ( Creator )
- انسجام قوی ( High Cohesion )
- واسطه گری ( Indirection )
- دانای اطلاعات ( Information Expert )
- اتصال ضعیف ( Low Coupling )
- چند ریختی ( Polymorphism )
- حفاظت از تاثیر تغییرات ( Protected Variations )
- مصنوع خالص ( Pure Fabrication )
Controller
این الگو بیان میکند که مسئولیت پاسخ به رویدادهای (Events ) یک سناریوی محدود مانند یک مورد کاربردی ( Use Case ) باید به عهده یک کلاس غیر UI باشد. کنترلر باید کارهایی را که نیاز است در پاسخ رویداد انجام شود، به دیگران بسپرد و نتایج را طبق درخواست رویداد بازگرداند. در اصل، کنترلر دریافت کننده رویداد، راهنمای مسیر پردازش برای پاسخ به رویداد و در نهایت برگرداننده پاسخ به سمت مبداء رویداد است. در زیر مثالی را میبینیم که رویداد اتفاق افتاده توسط واسط گرافیکی به سمت یک handler (که متدی است با ورودیِ فرستنده و آرگمانهای مورد نیاز) در کنترلر فرستاده میشود. این روش event handling، در نمونههای وب فرم و ویندوز فرم دیده میشود. به صورتی خود کلاسهای .Net وظیفه Event Raising از سمت UI با کلیک روی دکمه را انجام میدهد:
public class UserController { protected void OnClickCreate(object sender, EventArgs e) { // call validation services // call create user services } }
در مثال بعد عملیات مربوط به User در یک WebApiController پاسخ داده میشود. در اینجا به جای استفاده از Event Raising برای کنترل کردن رویداد، از فراخوانی یک متد در کنترلر توسط درخواست HttpPost انجام میگیرد. در اینجا نیاز است که در سمت کلاینت درخواستی را ارسال کنیم:
public class UserWebApiController { [HttpPost] public HttpResponseMessage Create(UserViewModel user) { // call validation services // call create user services } }
Creator :
این اصل میگوید شیء ای میتواند یک شیء دیگر را بسازد ( instantiate ) که: (اگر کلاس B بخواهد کلاس A را instantiate کند)
- کلاس B شیء از کلاس A را در خود داشته باشد؛
- یا اطلاعات کافی برای instantiate کردن از A را داشته باشد؛
- یا به صورت نزدیک با A در ارتباط باشد؛
- یا بخواهد شیء A را ذخیره کند.
از آنجایی که این اصل بدیهی به نظر میرسد، با مثال نقض، درک بهتری را نسبت به آن میتوان پیدا کرد:
// سازنده public class B { public static A CreateA(string name, string lastName, string job) { return new A() { Name =name, LastName = lastName, Job = job }; } } // ایجاد شونده public class A { public string Name { get; set; } public string LastName { get; set; } public string Job { get; set; } } public class Context { public void Main() { var name = "Rasoul"; var lastName = "Abbasi"; var job = "Developer"; var obj = B.CreateA(name, lastName, job); } }
و اما چرا این مثال، اصل Creator را نقض میکند. در مثال میبینید که کلاس B، یک شیء از نوع A را در متد Main کلاس Context ایجاد میکند. کلاس B فقط یک متد برای تولید A دارد و در عملیات تولید A هیچ منطق خاصی را پیاده سازی نمیکند.کلاس B شیء ای را از کلاس A ، در خود ندارد، با آن ارتباط نزدیک ندارد و آنرا ذخیره نمیکند. با اینکه کلاس B اطلاعات کافی را برای تولید A از ورودی میگیرد، ولی این کلاس Context است که اطلاعات کافی را ارسال مینماید. اگر در کلاس B منطقی اضافه بر instance گیریِ ساده وجود داشت (مانند بررسی صحت و اعتبار سنجی)، میتوانستیم بگوییم کلاس B از یک مجموعه عملیات instance گیری با خبر است که کلاس Context نباید از آن خبر داشته باشد. لذا اکنون هیچ دلیلی وجود ندارد که وظیفه تولید A را در Context انجام ندهیم و این مسئولیت را به کلاس B منتقل کنیم. این مورد ممکن است در ذهن شما با الگوی Factory تناقض داشته باشد. ولی نکته اصلی در الگو Factory انجام عملیات instance گیری با توجه به منطق برنامه است؛ یعنی وظیفهای که کلاس Context نباید از آن خبر داشته باشد را به کلاس Factory منتقل میکنیم. در غیر اینصورت ایجاد کلاس Factory بی معنا خواهد بود (مگر به عنوان افزایش انعطاف پذیری معماری که بتوان به راحتی نوع پیاده سازی یک واسط را تغییر داد).
High Cohesion :
این اصل اشاره به یکی از اصول اساسی طراحی نرم افزار دارد. انسجام واحدهای نرم افزاری باعث افزایش خوانایی، سهولت اشکال زدایی، قابلیت نگهداری و کاهش تاثیر زنجیرهای تغییرات میشود. طبق این اصل، مسئولیتهای هر واحد باید مرتبط باشد. لذا اجزایی کوچک با مسئولیتهای منسجم و متمرکز بهتر از اجزایی بزرگ با مسئولیتهای پراکنده است. اگر واحدهای سازنده نرم افزار انسجام ضعیفی داشته باشند، درک همکاریها، استفاده مجدد آنها، نگه داری نرم افزار و پاسخ به تغییرات سختتر خواهد شد.
در مثال زیر نقض این اصل را مشاهده میکنیم:
class Controller { public void CreateProduct(string name, int categoryId) { } public void EditProduct(int id, string name) { } public void DeleteProduct(int id) { } public void CreateCategory(string name) { } public void EditCategory(int id, string name) { } public void DeleteCategory(int id) { } }
همانطور که میبینید، کلاس
کنترلر ما، مسئولیت مدیریت Product و Category را بر عهده دارد. بزرگ شدن این کلاس، باعث سختتر شدن
خواندن کد و رفع اشکال میگردد. با جداسازی کنترلر مربوط به Product از Category میتوان انسجام را بالا برد.
Indirection :
این اصل بیان میکند که با تعریف یک واسط بین دو مولفه نرم افزاری میتوان میزان اتصال نرم افزار را کاهش داد. بدین ترتیب وظیفه هماهنگی ارتباط دو مؤلفه، به عهده این واسط خواهد بود و نیازی نیست دادههای ورودی و خروجی دو مؤلفه، هماهنگ باشند. در اینجا واسط، از وابستگی بین دو مؤلفه با پنهان کردن ضوابط هر مؤلفه از دیگری و ایجاد وابستگی ضعیف خود با دو مؤلفه، باعث کاهش اتصال کلی طراحی میگردد.
الگوهای Adapter و Delegate و همچنین نقش کنترلر در الگوی معماری MVC از این اصل پیروی میکنند.
class SenderA { public Mediator mediator { get; } public SenderA() { mediator = new Mediator(); } public void Send(string message, string reciever) { mediator.Send(message, reciever); } } class SenderB { public Mediator mediator { get; } public SenderB() { mediator = new Mediator(); } public void Send(string message) { } } public class RecieverA { public void DoAction(string message) { // انجام عملیات بر اساس پیغام دریافت شده switch (message) { case "create": break; case "delete": break; default: break; } } } public class RecieverB { public void DoAction(string message) { // انجام عملیات بر اساس پیغام دریافت شده switch (message) { case "edit": break; case "rollback": break; default: break; } } } class Mediator { internal void Send(string message, string reciever) { switch (reciever) { case "A": var recieverObjA = new RecieverA(); recieverObjA.DoAction(message); break; case "B": var recieverObjB = new RecieverB(); recieverObjB.DoAction(message); break; default: break; } } } class IndirectionContext { public void Main() { var senderA = new SenderA(); senderA.Send("rollback", "B"); var senderB = new SenderA(); senderB.Send("create", "A"); } }
در این مثال کلاس Mediator به عنوان واسط ارتباطی بین کلاسهای Sender و Receiver قرار گرفته و نقش تحویل پیغام را دارد.
در مقاله بعدی، به بررسی سایر اصول GRASP خواهم پرداخت.