Web Devs
640 subscribers
218 photos
22 videos
17 files
233 links
Articles, News, Jokes, Quotes, Back-End and UI/UX for web developers.
Github : https://github.com/fullStackDevsGroup
Advertising: @adsfullStackDevs
Download Telegram
#Algorithm #Sliding_window
#SlidingWindow #CSharp



🧩 الگوریتم Sliding Window:

الگوریتم Sliding Window یکی از تکنیک‌های مهم برای حل مسائل آرایه‌ها و رشته‌ها به طور بهینه است. این روش با استفاده از دو نشانگر برای بررسی بخش‌های مختلف داده، به سرعت جواب رو پیدا می‌کنه.

🔑 چطور کار می‌کنه؟
- دو نشانگر (`left` و `right`) برای نمایش پنجره (قسمتی از داده) استفاده می‌کنیم.
- نشانگر راست حرکت می‌کنه و هر بار یک کاراکتر یا مقدار جدید بررسی می‌شه.
- وقتی که شرایط خاصی مثل وجود مقدار تکراری یا رسیدن به اندازه‌ای خاص محقق بشه، نشانگر چپ حرکت می‌کنه تا پنجره رو کوچکتر کنیم.

مزیت اصلی: زمان اجرا به O(n) کاهش می‌یابد که نسبت به روش‌های سنتی با O(n²) بسیار سریع‌تر است.

💡 مثال: طول بزرگ‌ترین زیررشته بدون کاراکتر تکراری
ورودی: "abcabcbb"
خروجی: 3 (زیربرنامه "abc" بزرگ‌ترین زیررشته بدون تکرار است)



using System;
using System.Collections.Generic;

class Solution {
public int LengthOfLongestSubstring(string s) {
HashSet<char> set = new HashSet<char>();
int left = 0, maxLength = 0;

for (int right = 0; right < s.Length; right++) {
while (set.Contains(s[right])) {
set.Remove(s[left]);
left++;
}
set.Add(s[right]);
maxLength = Math.Max(maxLength, right - left + 1);
}

return maxLength;
}
}


کاربردها:
- پیدا کردن طول بزرگترین زیررشته یا زیرآرایه
- جستجوی زیرمجموعه‌ها با ویژگی‌های خاص
- مسائل مربوط به جمع یا مقایسه زیرآرایه‌ها و زیررشته‌ها



این الگوریتم خیلی مفیده برای حل مسائل بهینه در آرایه‌ها و رشته‌ها، خصوصاً وقتی نیاز به
بررسی بخش‌های مختلف داریم!



@fullStackDevs
👍5
🔰وقتی سیستم‌ها با هم حرف می‌زنند:
Command vs Event vs Pub/Sub

معمولا پیام هایی که در بین سیستم ها تبادل می شود در دو دسته قرار دارن.

در دسته اول فرستنده پیام هایی میفرسته که مشخص کننده اینکه یک عملیات باید انجام بشه، مثل PlaceOrder که به معنی "ثبت سفارش‌جدید " هست. این نوع پیام‌ها Command نام دارند.

در مورد Command، بین فرستنده (sender) و گیرنده (receiver) یک وابستگی منطقی (logical coupling) وجود داره، چون فرستنده می‌دونه که گیرنده باید با اون دستور چی کار کنه.

این یعنی فرستنده دقیقاً مشخص می‌کنه چه کاری باید انجام بشه (مثلاً "سفارش ثبت کن") و فرض می‌گیره که گیرنده توانایی انجامش رو داره.

دستورها (Commands) معمولاً فقط توسط یک گیرنده پردازش می‌شن، که این موضوع باعث انعطاف‌پذیری کمتری می‌شه.

📌 برای مثال: اگر بخوای چند سیستم همزمان به یک Command پاسخ بدن، باید تغییراتی در منطق اون Command ایجاد کنی که برخلاف اصل Open/Closed هست.

در دسته دوم Event ها هستن، Event ها فقط اطلاع میدن که "یه اتفاق افتاده"، مثلاً OrderCreated یعنی "سفارش ثبت شد".

🚨 فرقش با Command اینه که Event یه گزارشه از یه چیزیه ک تموم‌شده، نه درخواست اجرای یه عملیات.

و Eventها loosely coupled هستن چون فرستنده اصلاً نمی‌دونه که چه کسی قراره به این پیام واکنش نشون بده یا چطور باهاش برخورد بشه. فرستنده فقط می‌گه: "این اتفاق افتاد" .

دلیل این موضوع هم اینه که Event ها معمولاً بر اساس الگوی(Publish/Subscribe) کار می‌کنن. یعنی یه نفر Event رو publish می‌کنه، و هر کسی که به اون Event علاقه‌منده (subscriber) اون رو دریافت می‌کنه.

به‌خاطر این وابستگیه کمی که Publish/Subscribe در بین Publisher و Subscriber ایجاد می‌کنه، در خیلی از موارد استفاده از Event ها ترجیح داده میشن نسبت به Commandها.

یکی از مزایای مهم Event اینه که می‌تونی Subscriber جدید اضافه کنی بدون اینکه کدهای موجود رو تغییر بدی.

💡 این خیلی ارزشمنده چون توسعه سیستم رو بدون درگیر شدن با بقیه بخش‌ها ممکن می‌کنه.

یعنی تیم بیزینس می‌تونه یه Bounded Context جدید به راحتی اضافه کنه، بدون اینکه به کدهای فعلی دست بزنه یا کار تیم‌های دیگه رو مختل کنه.

📌 مثلاً در مثال فروشگاه اینترنتی، اگر OrderCreated منتشر بشه، تیم مارکتینگ فقط با Subscribe کردن به اون Event می‌تونه وارد جریان بشه، بدون اینکه توی سیستم سفارش‌گذاری اصلی دخالتی ایجاد کنه.

@fullStackDevs
👍5