📂 نظم و ترتیب در #C: همه چیز درباره namespace (از روش کلاسیک تا 10 #C)
وقتی پروژههاتون بزرگ میشه و تعداد کلاسها زیاد میشه، چطور ازش یه آش شلهقلمکار نسازیم؟ ابزار اصلی #C برای سازماندهی و جلوگیری از تداخل اسمی، namespace هست.
این namespace مثل یه سیستم پوشهبندیه (folders) برای کدهاتون. شما میتونید کلاسهای مرتبط رو تو یه namespace بذارید تا هم پیداکردنشون راحتتر باشه و هم اگه دو تا کلاس با اسم یکسان تو دو تا پوشه مختلف داشتید، با هم قاطی نشن.
1️⃣ روش کلاسیک تعریف namespace
در روش سنتی، شما یک بلوک namespace تعریف میکنید و کلاسهاتون رو داخلش قرار میدید. برای ایجاد ساختار تودرتو، میتونید از نقطه استفاده کنید.
// روش تودرتو با استفاده از نقطه (روش پیشنهادی)
namespace MyProject.Services.Authentication
{
class AuthService { }
class TokenService { }
}
// این کد معادل کد بالاست ولی باعث تو رفتگی (indentation) بیشتر میشه
namespace MyProject
{
namespace Services
{
namespace Authentication
{
class AuthService { }
class TokenService { }
}
}
}
برای استفاده از یک کلاس، باید اسم کاملش رو به همراه namespace وارد کنید، مگر اینکه اون namespace رو بالای فایل using کرده باشید.
2️⃣ روش مدرن (از 10 #C): File-Scoped Namespaces ✨
تیم #C دید که معمولاً تمام کلاسهای یه فایل، تو یه namespace مشترک هستن. پس از 10 #C به بعد، یه راه خیلی تمیزتر معرفی کردن که کل فایل رو داخل یه namespace قرار میده و از یه لایه تو رفتگی اضافی جلوگیری میکنه.
قبل از 10 #C:
namespace MyNamespace
{
class Class1
{
// Code...
}
class Class2
{
// Code...
}
}
از 10 #C به بعد:
namespace MyNamespace; // این برای کل فایل اعمال میشه و تمام!
class Class1
{
// Code...
}
class Class2
{
// Code...
}
این قابلیت، کد شما رو خیلی تمیزتر و خلاصهتر میکنه.
🤔 حرف حساب و تجربه شما
استفاده درست از namespaceها، اولین قدم برای نوشتن یه پروژه بزرگه که قابل نگهداری باشه.
شما تو پروژههاتون چقدر روی ساختار namespaceها وقت میذارید؟ از قابلیت جدید File-Scoped Namespaces استفاده میکنید؟
خب، اینجا که نمیشه همه حرفا رو زد! 😉
ادامهی بحث، سوالات، غر زدنها و گپ و گفتهای خودمونی، فقط تو گروه.
[C# Geeks Hangout]
🔖 هشتگها:
#CSharp #Programming #Developer #DotNet #CleanCode #BestPractices #Namespace
🏛 اصول SOLID: پنج ستون اصلی برای ساخت نرمافزار حرفهای
تا حالا شده به کدی برگردید که چند ماه پیش نوشتید و دیگه هیچی ازش نفهمید؟ یا بخواید یه تغییر کوچیک بدید و ببینید کل برنامه به هم ریخت؟
💡این مشکلات یه راه حل معروف دارن: اصول SOLID.
اینSOLID مجموعهای از پنج اصل بنیادی در طراحی شیءگراست که توسط "رابرت مارتین (عمو باب)" معرفی شدن. این اصول، مثل ستونهای یه ساختمون بزرگ، به شما کمک میکنن کدی بنویسید که انعطافپذیر، قابل نگهداری و توسعهپذیر باشه.
حالا SOLID مخفف چیست؟ 🤔
هر حرف در SOLID، نماینده یک اصله:
1️⃣ S - Single Responsibility Principle (اصل تک مسئولیتی):
یک کلاس باید فقط و فقط یک دلیل برای تغییر داشته باشه.
2️⃣ O - Open/Closed Principle (اصل باز/بسته):
کد شما باید برای "توسعه" باز، ولی برای "تغییر" بسته باشه.
3️⃣ L - Liskov Substitution Principle (اصل جایگزینی لیسکوف):
باید بتونید یک نمونه از کلاس فرزند رو به جای کلاس پدر استفاده کنید، بدون اینکه برنامه به مشکل بخوره.
4️⃣ I - Interface Segregation Principle (اصل تفکیک اینترفیسها):
کلاسها نباید مجبور بشن اینترفیسهایی رو پیادهسازی کنن که بهشون نیازی ندارن.
5️⃣ D - Dependency Inversion Principle (اصل وارونگی وابستگی):🚀 شروع مینی-سریال جدید!
ماژولهای سطح بالا نباید به ماژولهای سطح پایین وابسته باشن؛ هر دو باید به "انتزاع" (Abstraction) وابسته باشن.
امروز، قراره یه مینی-سریال داشته باشیم و هر کدوم از این ۵ اصل رو به صورت جداگانه، با زبون ساده و مثالهای عملی در #C کالبدشکافی کنیم.
این سری، سطح شما رو از "کدنویس" به "معمار نرمافزار" نزدیکتر میکنه.
با ما همراه باشید!
💬 بحث و گفتگوی بیشتر در گروه کامیونیتی:
[C# Geeks Community]
🔖 هشتگها:
#CSharp #Programming #Developer #SOLID #SoftwareArchitecture #CleanCode #BestPractices
1️⃣ اصل اول SOLID: تک مسئولیتی (Single Responsibility Principle)
تا حالا یه کلاسی نوشتید که اولش کوچیک بوده، ولی کم کم اونقدر بزرگ و پیچیده شده که دیگه دست زدن بهش ترسناک بوده؟ این مشکل معمولاً از زیر پا گذاشتن اولین و مهمترین اصل SOLID یعنی اصل تک مسئولیتی (SRP) میاد.
این اصل چی میگه؟ 🎯
به زبان ساده:
✨️یک کلاس باید فقط و فقط یک دلیل برای تغییر داشته باشه.
یعنی هر کلاس باید یه وظیفه مشخص و واحد داشته باشه و فقط همون رو به بهترین شکل انجام بده.
مثال از دنیای واقعی: یه چاقوی سوئیسی رو تصور کنید که هم چاقوئه، هم پیچگوشتی، هم در باز کن. شاید به نظر کارآمد بیاد، ولی هیچکدوم از کارها رو به خوبی یه ابزار تخصصی انجام نمیده. تو کدنویسی هم همینه.
مثال عملی: کد "بدبو" 👎 در برابر کد "تمیز" 👍
فرض کنید یه کلاسی برای ثبتنام کاربر داریم.
مثال بد (نقض اصل تک مسئولیتی):
public class UserService
{
public void RegisterUser(string username, string password)
{
if (string.IsNullOrWhiteSpace(username))
{
// مسئولیت اول: لاگ کردن خطا در فایل
File.WriteAllText("errors.log", "Username is empty");
}
// مسئولیت دوم: ثبت کاربر در دیتابیس
// ... code to save user to database ...
// مسئولیت سوم: ارسال ایمیل خوشآمدگویی
// ... code to send a welcome email ...
}
}
مشکل چیه؟ این کلاس الان سه تا دلیل برای تغییر داره: ۱. اگه منطق ثبتنام عوض بشه. ۲. اگه نحوه لاگ کردن عوض بشه. ۳. اگه متن ایمیل عوض بشه. این یعنی یه کلاس شلوغ و شکننده!
مثال خوب (رعایت اصل تک مسئولیتی):
حالا میایم و هر مسئولیت رو به یه کلاس جدا و متخصص میسپاریم.
// ۱. کلاسی فقط برای لاگ کردن
public class FileLogger
{
public void LogError(string message) { /* ... */ }
}
// ۲. کلاسی فقط برای ارسال ایمیل
public class EmailService
{
public void SendWelcomeEmail(string username) { /* ... */ }
}
// ۳. کلاس اصلی که حالا فقط روی منطق کاربر تمرکز داره
public class UserService
{
private readonly FileLogger _logger;
private readonly EmailService _emailService;
public UserService(FileLogger logger, EmailService emailService)
{
_logger = logger;
_emailService = emailService;
}
public void RegisterUser(string username, string password)
{
if (string.IsNullOrWhiteSpace(username))
{
_logger.LogError("Username is empty");
return;
}
// ... code to save user to database ...
_emailService.SendWelcomeEmail(username);
}
}
حالا هر بخش، کار تخصصی خودش رو انجام میده. کد تمیز، قابل تست و قابل نگهداریه!
🔖 هشتگها:
#CSharp #Programming #Developer #SOLID #SoftwareArchitecture #CleanCode #SRP
2️⃣ اصل دوم SOLID: باز/بسته (Open/Closed Principle)
تا حالا شده یه تیکه کد بنویسید که خوب کار میکنه، ولی هر بار که یه قابلیت جدید میخواید، مجبور میشید برگردید و همون کد قدیمی و حساس رو دستکاری کنید؟ این کار ریسک ایجاد باگهای جدید رو خیلی بالا میبره.
اصل باز/بسته (OCP) برای حل همین مشکل اومده.
این اصل چی میگه؟ 🎯
به زبان ساده:
کلاسها و ماژولهای شما باید برای "توسعه" (Extension) باز، ولی برای "تغییر" (Modification) بسته باشند.
یعنی شما باید بتونید رفتار جدیدی به سیستم اضافه کنید، بدون اینکه نیاز به تغییر کدهای موجودی که قبلاً تست شده و کار میکنه، داشته باشید.
مثال عملی: کد "شکننده" 👎 در برابر کد "انعطافپذیر" 👍
فرض کنید یه کلاسی داریم که مساحت اشکال مختلف رو محاسبه میکنه.
مثال بد (نقض اصل باز/بسته):
این کد برای تغییر "بسته" نیست. اگه بخوایم یه شکل جدید مثل "مثلث" رو اضافه کنیم، مجبوریم این کلاس رو باز کنیم و یه if جدید بهش اضافه کنیم. این یعنی دستکاری کد قدیمی و ریسک ایجاد باگ.
public class AreaCalculator
{
public double CalculateTotalArea(object[] shapes)
{
double totalArea = 0;
foreach (var shape in shapes)
{
if (shape is Rectangle r)
{
totalArea += r.Width * r.Height;
}
if (shape is Circle c)
{
totalArea += Math.PI * c.Radius * c.Radius;
}
// برای اضافه کردن مثلث، باید این کلاس رو دستکاری کنیم!
}
return totalArea;
}
}
مثال خوب (رعایت اصل باز/بسته):
حالا با استفاده از یک انتزاع (Abstraction) مثل interface، کد رو جوری بازنویسی میکنیم که برای توسعه "باز" باشه.
قدم اول: ساختن یک قرارداد (Interface)
public interface IShape
{
double CalculateArea();
}
قدم دوم: پیادهسازی قرارداد برای هر شکل
public class Rectangle : IShape
{
public double Width { get; set; }
public double Height { get; set; }
public double CalculateArea() => Width * Height;
}
public class Circle : IShape
{
public double Radius { get; set; }
public double CalculateArea() => Math.PI * Radius * Radius;
}
قدم سوم: کلاس محاسبهگر انعطافپذیر
حالا کلاس AreaCalculator ما دیگه به نوع مشخصی وابسته نیست، فقط با قرارداد IShape کار میکنه.
public class AreaCalculator
{
public double CalculateTotalArea(IShape[] shapes)
{
double totalArea = 0;
foreach (var shape in shapes)
{
totalArea += shape.CalculateArea();
}
return totalArea;
}
}
جادو اینجا اتفاق میفته: حالا اگه بخوایم شکل جدید "مثلث" رو اضافه کنیم، هیچ نیازی به تغییر کلاس AreaCalculator نداریم! فقط یه کلاس جدید میسازیم:
public class Triangle : IShape
{
public double Base { get; set; }
public double Height { get; set; }
public double CalculateArea() => 0.5 * Base * Height;
}
کد ما برای توسعه (اضافه کردن کلاس جدید) باز بود، ولی برای تغییر (دستکاری AreaCalculator) بسته بود!
🔖 هشتگها:
#CSharp #Programming #Developer #SOLID #SoftwareArchitecture #CleanCode #OCP
3️⃣ اصل سوم SOLID: جایگزینی لیسکوف (Liskov Substitution Principle)
تا حالا شده یه کلاس فرزند بسازید که از یه کلاس پدر ارثبری میکنه، ولی وقتی ازش به جای پدر استفاده میکنید، یهو همه چی به هم میریزه و برنامه رفتار غیرمنتظرهای نشون میده؟
اصل جایگزینی لیسکوف (LSP) دقیقاً برای جلوگیری از همین فاجعه طراحی شده.
این اصل چی میگه؟ 🎯
به زبان ساده:
شما باید همیشه بتونید یک نمونه از کلاس فرزند (Subclass) رو به جای یک نمونه از کلاس پدر (Superclass) استفاده کنید، بدون اینکه برنامه به مشکل بخوره یا رفتارش عوض بشه.یعنی کلاس فرزند نباید "قراردادها" و انتظاراتی که از کلاس پدر میره رو زیر پا بذاره. اگه کلاس پدر قول داده یه کاری رو انجام بده، کلاس فرزند هم باید همون قول رو بده، نه اینکه بزنه زیرش!
مثال عملی: کابوس معروف مربع و مستطیل!
این یه مثال کلاسیکه که نقض LSP رو به بهترین شکل نشون میده.
مثال بد (نقض اصل جایگزینی لیسکوف):
در نگاه اول، به نظر منطقی میاد که Square (مربع) از Rectangle (مستطیل) ارثبری کنه، چون مربع یه نوع خاص از مستطیله. ولی این کار، قرارداد رو میشکنه!
public class Rectangle
{
public virtual int Width { get; set; }
public virtual int Height { get; set; }
}
public class Square : Rectangle
{
// برای اینکه مربع باقی بمونه، وقتی عرض رو تغییر میدیم،
// باید ارتفاع رو هم تغییر بدیم (و برعکس).
public override int Width
{
set { base.Width = base.Height = value; }
}
public override int Height
{
set { base.Width = base.Height = value; }
}
}
مشکل کجاست؟
حالا یه متدی رو تصور کنید که یه Rectangle میگیره و انتظار داره با تغییر عرض، ارتفاع ثابت بمونه. اگه ما بهش یه Square پاس بدیم، کل منطقش به هم میریزه!
public void SomeMethod(Rectangle r)
{
// این متد انتظار داره با تغییر عرض، ارتفاع ثابت بمونه
r.Width = 10;
r.Height = 5;
// اگه r یک مستطیل واقعی باشه، مساحت 50 میشه
// ولی اگه یه مربع بهش پاس داده باشیم، مساحت 25 میشه! (چون ارتفاع هم 5 شده)
// این یعنی رفتار برنامه غیرمنتظره شده!
Console.WriteLine(r.Width * r.Height);
}
اینجا کلاس فرزند (Square) نتونست بدون دردسر جای پدرش (Rectangle) رو بگیره.
مثال خوب (رعایت اصل جایگزینی لیسکوف):
راه حل اینه که به جای وراثت مستقیم، از یه انتزاع مشترک مثل interface استفاده کنیم.
public interface IShape
{
double CalculateArea();
}
public class Rectangle : IShape
{
public int Width { get; set; }
public int Height { get; set; }
public double CalculateArea() => Width * Height;
}
public class Square : IShape
{
public int Side { get; set; }
public double CalculateArea() => Side * Side;
}
حالا دیگه هیچکدوم قرارداد اون یکی رو نمیشکنه و هر کدوم زندگی خودشون رو دارن.
🔖 هشتگها:
#CSharp #Programming #Developer #SOLID #SoftwareArchitecture #CleanCode #LSP
4️⃣ اصل چهارم SOLID: تفکیک اینترفیسها (Interface Segregation Principle)
تا حالا شده یه اینترفیس (Interface) رو پیادهسازی کنید و ببینید مجبورید کلی متد رو به صورت خالی یا با پرتاب Exception پیادهسازی کنید، چون اصلاً به کار کلاس شما نمیان؟
این مشکل معمولاً از طراحی اینترفیسهای بزرگ و "چاق" (Fat Interfaces) به وجود میاد. اصل تفکیک اینترفیسها (ISP) برای حل همین مشکل طراحی شده.
این اصل چی میگه؟ 🎯
به زبان ساده:
کلاسها نباید مجبور بشن اینترفیسهایی رو پیادهسازی کنن که به متدهای اون نیازی ندارن.
به عبارت دیگه، به جای ساختن یک اینترفیس بزرگ و همهکاره، بهتره چندین اینترفیس کوچک، تخصصی و مجزا بسازیم.
مثال عملی: کابوس پرینترهای همهکاره!
فرض کنید یه اینترفیس برای کار با دستگاههای اداری طراحی میکنیم.
مثال بد (نقض اصل تفکیک اینترفیسها):
اینجا یه اینترفیس "چاق" داریم. اگه یه پرینتر ساده و ارزون داشته باشیم که فقط قابلیت پرینت داره، باز هم مجبوره متدهای Scan و Fax رو پیادهسازی کنه، که این کار منطقی نیست و کد رو کثیف میکنه.
// ❌ اینترفیس "چاق" و بد
public interface IMultiFunctionDevice
{
void Print(string content);
void Scan(string content);
void Fax(string content);
}
public class CheapPrinter : IMultiFunctionDevice
{
public void Print(string content)
{
// OK
}
public void Scan(string content)
{
// این پرینتر اسکنر نداره! مجبوریم خطا برگردونیم
throw new NotImplementedException();
}
public void Fax(string content)
{
// این پرینتر فکس هم نداره!
throw new NotImplementedException();
}
}
مثال خوب (رعایت اصل تفکیک اینترفیسها):
حالا میایم و اون اینترفیس بزرگ رو به چند اینترفیس کوچکتر و تخصصیتر میشکنیم.
// ✅ اینترفیسهای کوچک و تخصصی
public interface IPrinter
{
void Print(string content);
}
public interface IScanner
{
void Scan(string content);
}
حالا هر کلاسی، فقط اینترفیسی رو پیادهسازی میکنه که واقعاً بهش نیاز داره.
// این پرینتر ساده، فقط قرارداد پرینت رو امضا میکنه
public class CheapPrinter : IPrinter
{
public void Print(string content)
{
// OK
}
}
// این دستگاه همهکاره، هر دو قرارداد رو امضا میکنه
public class AllInOnePrinter : IPrinter, IScanner
{
public void Print(string content)
{
// OK
}
public void Scan(string content)
{
// OK
}
}
کد ما حالا خیلی تمیزتر، انعطافپذیرتر و قابل فهمتره!
🔖 هشتگها:
#CSharp #Programming #Developer #SOLID #SoftwareArchitecture #CleanCode #ISP
5️⃣ اصل پنجم SOLID: وارونگی وابستگی (Dependency Inversion Principle)
تا حالا شده یه کلاس بنویسید که داخلش یه کلاس دیگه رو با new میسازید و بعداً برای تغییر اون کلاس داخلی، مجبور میشید کلاس اصلی رو هم دستکاری کنید؟ این یعنی کدهای شما به هم سفت و سخت (Tightly Coupled) وصل شدن.
اصل وارونگی وابستگی (DIP) برای حل همین مشکل و ایجاد کدهای انعطافپذیر طراحی شده.
این اصل چی میگه؟ 🎯
این اصل دو بخش مهم داره:
ماژولهای سطح بالا نباید به ماژولهای سطح پایین وابسته باشند. هر دو باید به انتزاع (Abstraction) وابسته باشند.به زبان ساده: کلاسهای اصلی و سطح بالای شما (مثلاً بیزنس لاجیک) نباید به جزئیات پیادهسازی (مثلاً نحوه کار با دیتابیس یا ارسال ایمیل) وابسته باشن. در عوض، هر دو باید به یک قرارداد مشترک (Interface) وابسته باشن.
انتزاعها نباید به جزئیات وابسته باشند. این جزئیات هستن که باید به انتزاعها وابسته باشند.
مثال عملی: سیستم اطلاعرسانی
فرض کنید یه سیستمی برای اطلاعرسانی به کاربر داریم.
مثال بد (نقض اصل وارونگی وابستگی):
اینجا کلاس سطح بالای Notification مستقیماً به کلاس سطح پایین EmailSender وابسته است. اگه فردا بخوایم به جای ایمیل، با SMS اطلاعرسانی کنیم، مجبوریم کلاس Notification رو تغییر بدیم. این یعنی وابستگی سفت و سخت.
// ❌ این کلاس سطح پایین است
public class EmailSender
{
public void Send() => Console.WriteLine("Email sent!");
}
// ❌ این کلاس سطح بالاست و مستقیماً به کلاس پایینی وابسته است
public class Notification
{
private readonly EmailSender _emailSender = new EmailSender();
public void SendNotification()
{
_emailSender.Send();
}
}
مثال خوب (رعایت اصل وارونگی وابستگی):
حالا با استفاده از یک Interface، این وابستگی رو "وارونه" میکنیم.
قدم اول: ساختن قرارداد (Interface)
این قرارداد در لایه سطح بالا تعریف میشه.
public interface IMessageSender
{
void SendMessage();
}
قدم دوم: کلاسهای سطح پایین از قرارداد پیروی میکنند
public class EmailSender : IMessageSender
{
public void SendMessage() => Console.WriteLine("Email sent!");
}
public class SmsSender : IMessageSender
{
public void SendMessage() => Console.WriteLine("SMS sent!");
}
قدم سوم: کلاس سطح بالا به قرارداد وابسته است، نه به جزئیات
public class Notification
{
private readonly IMessageSender _sender;
// وابستگی از طریق Constructor تزریق میشود (Dependency Injection)
public Notification(IMessageSender sender)
{
_sender = sender;
}
public void SendNotification()
{
_sender.SendMessage();
}
}
جادو اینجا اتفاق میفته: حالا کلاس Notification دیگه کاری نداره که پیام چطوری ارسال میشه (با ایمیل یا SMS). اون فقط "قرارداد" رو میشناسه. ما میتونیم موقع ساختن آبجکت Notification، هر نوع IMessageSender که دوست داریم رو بهش پاس بدیم، بدون اینکه یک کلمه از کدش رو تغییر بدیم!
🤔 حرف حساب و تجربه شما
این DIP قلب معماریهای تمیز و مدرنه و اساس کار تزریق وابستگی (Dependency Injection) هست. رعایت این اصل، کد شما رو فوقالعاده انعطافپذیر، قابل تست و توسعهپذیر میکنه.
شما چقدر به این اصل در پروژههاتون اهمیت میدید؟ بهترین مثالی که از کاربرد این اصل تو ذهنتون دارید چیه؟
💬 بحث و گفتگوی بیشتر در گروه کامیونیتی:
[C# Geeks Community]
🔖 هشتگها:
#CSharp #Programming #Developer #SOLID #SoftwareArchitecture #CleanCode #DIP
🛡 دستور using در #C: بهترین دوست IDisposable و راهی برای جلوگیری از نشت منابعوقتی با فایلها، دیتابیس، ارتباطات شبکه یا هر منبع خارجی دیگهای کار میکنید، یه خطر بزرگ وجود داره: یادتون بره منابعی که باز کردید رو ببندید! این کار باعث "نشت منابع" (Resource Leaks) و مشکلات جدی در پرفورمنس و پایداری برنامه میشه.
سیشارپ یه راه حل خیلی شیک، امن و حرفهای برای این مشکل داره: دستور using.
1️⃣ مشکل کجاست؟ IDisposable و مدیریت منابع
بعضی از آبجکتها در داتنت، منابعی رو مدیریت میکنن که Garbage Collector به صورت خودکار نمیتونه اونها رو آزاد کنه (مثل دستگیره فایل در سیستمعامل). این کلاسها، اینترفیس IDisposable رو پیادهسازی میکنن که فقط یک متد به اسم Dispose() داره.
وظیفه ما به عنوان برنامهنویس اینه که همیشه و تحت هر شرایطی، بعد از تموم شدن کارمون با این آبجکتها، متد Dispose() اونها رو صدا بزنیم.
2️⃣ راه حل قدیمی (و زشت): try...finally 👎
راه سنتی برای اینکه مطمئن بشیم Dispose() همیشه صدا زده میشه (حتی اگه وسط کار یه Exception رخ بده)، استفاده از بلوک try...finally هست:
StreamReader reader = null;
try
{
reader = new StreamReader("myFile.txt");
// ... کار کردن با فایل ...
}
finally
{
if (reader != null)
{
reader.Dispose(); // تضمین میکنه که فایل همیشه بسته میشه
}
}
این کد کار میکنه، ولی طولانی و زشته.
3️⃣ راه حل مدرن و شیک: دستور using ✨
دستور using یه "شکر سینتکسی" (Syntactic Sugar) برای همون بلوک try...finally هست.
به محض اینکه اجرای کد از بلوک using خارج بشه (چه به صورت عادی و چه به خاطر یه Exception)، کامپایلر به صورت خودکار متد Dispose() رو روی اون آبجکت صدا میزنه. اینجوری کد شما خیلی تمیزتر، کوتاهتر و امنتر میشه.
// این کد دقیقاً معادل کد try...finally بالاست
using (StreamReader reader = new StreamReader("myFile.txt"))
{
// ... کار کردن با فایل ...
}
// reader.Dispose() اینجا به صورت خودکار در هر حالتی صدا زده میشه
4️⃣ فرم جدیدتر (از C# 8): using declarations 🚀
از C# 8 به بعد، کار حتی از این هم سادهتر شده. اگه متغیر using رو به این شکل تعریف کنید، دیگه نیازی به آکولاد {} ندارید و اون متغیر در انتهای اسکوپ فعلی (معمولاً در انتهای متد) به صورت خودکار Dispose میشه.
void ReadFile()
{
using var reader = new StreamReader("myFile.txt");
using var writer = new StreamWriter("log.txt");
// ... کار کردن با فایلها ...
} // reader.Dispose() و writer.Dispose() اینجا به صورت خودکار صدا زده میشن
🤔 حرف حساب و قانون طلایی
قانون طلایی: هر کلاسی که IDisposable رو پیادهسازی کرده، باید داخل یه بلوک using (یا با سینتکس جدیدش) ازش استفاده بشه.
شما بیشتر از کدوم فرمت using استفاده میکنید؟ کلاسیک با براکت یا فرمت جدید بدون براکت؟
🔖 هشتگها:
#CSharp #Programming #Developer #DotNet #BestPractices #CleanCode #IDisposable
💾 حافظه کلاسها در #C: راهنمای کامل Fields, readonly و const
تا حالا شده از خودتون بپرسید فرق بین یه فیلد readonly و یه const چیه؟ یا اینکه متغیرهایی که داخل یه کلاس تعریف میکنیم (فیلدها) چطور و کِی مقداردهی میشن؟
امروز میخوایم بریم تو دل کلاسها و با اعضای دادهای اونها و قوانین حاکم بر اونها آشنا بشیم.
1️⃣ فیلدها (Fields):
حافظه داخلی یک آبجکت فیلدها، متغیرهایی هستن که داخل یه کلاس یا struct تعریف میشن و "وضعیت" یا "داده"های اون آبجکت رو در طول عمرش نگه میدارن. هر نمونه (instance) از کلاس، یک کپی مستقل از فیلدهای خودش رو داره.
💡نکته حرفهای (قرارداد نامگذاری):مقداردهی اولیه فیلدها:
یه قرارداد رایج و خوب، استفاده از آندرلاین (_) برای فیلدهای private هست تا به راحتی از متغیرهای محلی و پارامترها تشخیص داده بشن (مثلاً name_).
مقداردهی اولیه به فیلدها اختیاریه. اگه مقداری بهشون ندید، مقدار پیشفرض نوعشون رو میگیرن. نکته مهم اینه که این مقداردهی قبل از اجرای اولین خط کد در سازنده (constructor) انجام میشه.
2️⃣ کلید readonly: فیلدهای فقط-خواندنی 🔒
اگه میخواید یه فیلد فقط یک بار مقداردهی بشه و بعد از ساخته شدن آبجکت دیگه هرگز تغییر نکنه، از readonly استفاده کنید. این برای مقادیری که در زمان ساخت آبجکت مشخص میشن ولی بعدش باید ثابت بمونن، عالیه.
قانون مهم: فیلدهای readonly فقط در دو جا میتونن مقدار بگیرن: یا موقع تعریف اولیه، یا داخل سازنده (constructor) اون کلاس.
public class UserProfile
{
// مقداردهی موقع تعریف
public readonly Guid UserId = Guid.NewGuid();
// تعریف بدون مقدار اولیه
public readonly DateTime RegistrationDate;
public UserProfile()
{
// مقداردهی در سازنده
RegistrationDate = DateTime.UtcNow;
}
public void UpdateProfile()
{
// UserId = Guid.NewGuid(); // ❌ خطای زمان کامپایل!
}
}
3️⃣ دوئل بزرگ: const در برابر static readonly ⚔️
این یکی از کلاسیکترین سوالات مصاحبه و یکی از مهمترین نکات در طراحی حرفهایه. هر دو برای مقادیر ثابت به کار میرن، ولی تفاوتهای حیاتی دارن.
🔵 const (ثابت زمان کامپایل):
• مقدارش باید در زمان کامپایل مشخص و ثابت باشه
(const double Pi = 3.14;).
• کامپایلر مقدارش رو مستقیماً در کد جایگزین میکنه (مثل ماکرو).
• فقط برای انواع داده ساده (عددی، رشته، بولین و...) قابل استفادهست.
🔴 static readonly (ثابت زمان اجرا):
• مقدارش در زمان اجرا (معمولاً موقع استارت برنامه) مشخص میشه.
• یه فیلد واقعیه و در حافظه نگهداری میشه، مقدارش جایگزین نمیشه.
• برای هر نوع دادهای، حتی آبجکتهای پیچیده، قابل استفادهست.
public static readonly DateTime StartupTime = DateTime.Now;
😈تله خطرناک public const:
اگه شما یه public const رو در یک کتابخانه (Assembly A) تعریف کنید و در یک پروژه دیگه (Assembly B) ازش استفاده کنید، مقدار اون ثابت موقع کامپایل در Assembly B "پخته" یا "bake in" میشه. حالا اگه شما مقدار const رو در Assembly A عوض کنید، تا وقتی که Assembly B رو دوباره کامپایل نکنید، همچنان از همون مقدار قدیمی استفاده خواهد کرد! این میتونه منجر به باگهای فاجعهبار بشه. static readonly این مشکل رو نداره و همیشه آخرین مقدار رو میخونه، بنابراین انتخاب امنتریه.
🤔 حرف حساب و تجربه شما
انتخاب درست بین const و static readonly یکی از نشانههای یه توسعهدهنده باتجربهست که به نگهداری بلندمدت کد فکر میکنه.
شما بیشتر از const استفاده میکنید یا static readonly؟ آیا تا حالا به مشکل اسمبلی با const برخورد کرده بودید؟
🔖 هشتگها:
#CSharp #Programming #Developer #DotNet #OOP #CleanCode #BestPractices
🛠 متدهای مدرن در #C
Expression-bodied و Local Methods
سیشارپ مدرن، پر از قابلیتهای شیک و کاربردیه که به ما کمک میکنه کدهای کوتاهتر، خواناتر و منظمتری بنویسیم. امروز با دو تا از این تکنیکهای خفن برای کار با متدها آشنا میشیم.
1️⃣ متدهای Expression-bodied (=>): خداحافظی با return و {}
اگه متد شما فقط از یک عبارت (Expression) تشکیل شده، دیگه نیازی به نوشتن بلوک {} و کلمه کلیدی return ندارید! میتونید با استفاده از "فت ارو" (=>)، اون رو در یک خط بنویسید.
این کار، کد شما رو فوقالعاده تمیز و مینیمال میکنه.
// روش قدیمی
int Double(int x)
{
return x * 2;
}
// روش مدرن و شیک با Expression-bodied
int DoubleModern(int x) => x * 2;
// این قابلیت برای متدهای void هم کار میکنه
void SayHello() => Console.WriteLine("Hello!");
2️⃣ متدهای محلی (Local Methods): متد در دل متد!
گاهی وقتا یه منطق کمکی دارید که فقط و فقط داخل یک متد دیگه استفاده میشه. به جای اینکه اون رو به عنوان یه متد private تو کل کلاس تعریف کنید و کلاس رو شلوغ کنید، میتونید اون رو به عنوان یه متد محلی، دقیقاً داخل همون متدی که بهش نیاز دارید، تعریف کنید.
مزایای این کار:
• کپسولهسازی عالی: اون متد کمکی، فقط همونجا قابل دسترسه و هیچ جای دیگهای از کلاس رو آلوده نمیکنه.
• دسترسی به متغیرهای محلی: متد محلی میتونه به متغیرهای محلی و پارامترهای متد بیرونی دسترسی داشته باشه.
void WriteCubes()
{
Console.WriteLine(Cube(3));
Console.WriteLine(Cube(4));
// این متد، فقط داخل WriteCubes قابل دسترسه
int Cube(int value) => value * value * value;
}
💡نکته حرفهای (static local methods):
از C# 8 به بعد، اگه متد محلی شما نیازی به دسترسی به متغیرهای متد بیرونی نداره، میتونید اون رو با کلمه کلیدی static تعریف کنید. این کار به کامپایلر کمک میکنه بهینهسازیهای بهتری انجام بده و جلوی دسترسیهای ناخواسته رو هم میگیره.
🤔 حرف حساب و تجربه شما
این تکنیکهای مدرن، ابزارهای شما برای نوشتن کدهایی هستن که هم کار میکنن و هم خوندنشون لذتبخشه.
شما از کدوم یکی از این قابلیتها بیشتر استفاده میکنید؟ آیا متدهای Expression-bodied جزو استایل کدنویسی شما هستن؟
🔖 هشتگها:
#CSharp #Programming #Developer #DotNet #CleanCode #ModernCSharp #BestPractices