نوشته های Setare Behzadi

خلاصه کتاب Designing Data-Intensive Applications

Setare Behzadi — Mon, 15 Dec 2025 20:02:09 +0330

فصل ۲- Query Languages for Data- قسمت۴پرس‌وجو با MapReduceMapReduce یک مدل برنامه‌نویسی برای پردازش حجمیِ مقدار زیادی داده به‌صورت دسته‌ای (bulk) روی تعداد زیادی ماشین است که توسط گوگل محبوب شد. شکل محدودی از MapReduce توسط برخی دیتابیس‌های NoSQL از جمله MongoDB و CouchDB پشتیبانی می‌شود، به‌عنوان مکانیزمی برای انجام پرس‌وجوهای فقط‌خواندنی (read-only) روی تعداد زیادی سند.به‌طور کلی، MapReduce با جزئیات بیشتری در فصل ۱۰ توضیح داده شده است. فعلاً فقط به‌طور خلاصه به نحوه‌ی استفاده‌ی MongoDB از این مدل می‌پردازیم.MapReduce نه یک زبان پرس‌وجوی کاملاً اعلانی (declarative) است و نه یک API پرس‌وجوی کاملاً امری (imperative)، بلکه جایی بین این دو قرار می‌گیرد: منطق پرس‌وجو با تکه‌کدهایی بیان می‌شود که توسط چارچوب پردازش به‌صورت تکرارشونده فراخوانی می‌شوند. این مدل بر پایه‌ی توابع map (که collect هم نامیده می‌شود) و reduce (که fold یا inject نیز گفته می‌شود) است؛ توابعی که در بسیاری از زبان‌های برنامه‌نویسی تابعی وجود دارند.برای مثال، تصور کنید یک زیست‌شناس دریایی هستید و هر بار که حیوانی را در اقیانوس مشاهده می‌کنید، یک رکورد مشاهده (observation) به دیتابیس خود اضافه می‌کنید. حالا می‌خواهید گزارشی تولید کنید که نشان دهد در هر ماه چند کوسه دیده‌اید.در PostgreSQL می‌توانید این پرس‌وجو را به این شکل بنویسید:SELECT date_trunc('month', observation_timestamp) AS observation_month, sum(num_animals) AS total_animals FROM observations WHERE family = 'Sharks' GROUP BY observation_month; تابع date_trunc('month', timestamp) ماه تقویمی‌ای را که timestamp در آن قرار دارد مشخص می‌کند و timestamp دیگری را که نشان‌دهنده‌ی ابتدای آن ماه است برمی‌گرداند. به عبارت دیگر، این تابع یک timestamp را به نزدیک‌ترین ماهِ پایین‌تر گرد می‌کند.این پرس‌وجو ابتدا مشاهده‌ها را فیلتر می‌کند تا فقط گونه‌هایی از خانواده‌ی Sharks باقی بمانند، سپس مشاهده‌ها را بر اساس ماه تقویمی‌ای که در آن رخ داده‌اند گروه‌بندی می‌کند، و در نهایت تعداد حیوانات دیده‌شده در همه‌ی مشاهده‌های آن ماه را با هم جمع می‌کند.همین کار را می‌توان با قابلیت MapReduce در MongoDB به شکل زیر بیان کرد:db.observations.mapReduce( function map() { var year = this.observationTimestamp.getFullYear(); var month = this.observationTimestamp.getMonth() + 1; emit(year + "-" + month, this.numAnimals); }, function reduce(key, values) { return Array.sum(values); }, { query: { family: "Sharks" }, out: "monthlySharkReport" } ); فیلتر مربوط به در نظر گرفتن فقط گونه‌های کوسه می‌تواند به‌صورت اعلانی مشخص شود (این یک افزونه‌ی مخصوص MongoDB به MapReduce است).تابع JavaScriptِ map یک بار برای هر سندی که با query مطابقت دارد فراخوانی می‌شود، به‌طوری که this به شیء سند اشاره می‌کند.تابع map یک کلید (رشته‌ای شامل سال و ماه، مثل "2013-12" یا "2014-1") و یک مقدار (تعداد حیوانات در آن مشاهده) را emit می‌کند.جفت‌های کلید–مقدارِ تولیدشده توسط map بر اساس کلید گروه‌بندی می‌شوند. برای تمام جفت‌های کلید–مقداری که کلید یکسانی دارند (یعنی همان ماه و سال)، تابع reduce یک بار فراخوانی می‌شود.تابع reduce تعداد حیوانات مربوط به همه‌ی مشاهده‌های یک ماه مشخص را با هم جمع می‌کند.خروجی نهایی در کالکشنی به نام monthlySharkReport نوشته می‌شود.برای مثال، فرض کنید کالکشن observations شامل این دو سند باشد:{ observationTimestamp: Date.parse("Mon, 25 Dec 1995 12:34:56 GMT"), family: "Sharks", species: "Carcharodon carcharias", numAnimals: 3 } { observationTimestamp: Date.parse("Tue, 12 Dec 1995 16:17:18 GMT"), family: "Sharks", species: "Carcharias taurus", numAnimals: 4 } در این حالت، تابع map یک بار برای هر سند فراخوانی می‌شود و در نتیجه emit("1995-12", 3) و emit("1995-12", 4) تولید می‌شود. سپس تابع reduce با reduce("1995-12", [3, 4]) فراخوانی شده و مقدار ۷ را برمی‌گرداند.توابع map و reduce تا حدی در کارهایی که اجازه دارند انجام دهند محدود هستند. آن‌ها باید توابعی خالص (pure functions) باشند؛ یعنی فقط از داده‌ای که به‌عنوان ورودی به آن‌ها داده می‌شود استفاده کنند، نمی‌توانند پرس‌وجوی دیگری به دیتابیس بزنند و نباید هیچ اثر جانبی (side effect) داشته باشند. این محدودیت‌ها به دیتابیس اجازه می‌دهد این توابع را در هر جایی، با هر ترتیبی اجرا کند و در صورت بروز خطا دوباره آن‌ها را اجرا کند. با این حال، این توابع همچنان قدرتمند هستند: می‌توانند رشته‌ها را پردازش کنند، توابع کتابخانه‌ای را فراخوانی کنند، محاسبات انجام دهند و کارهای بیشتری انجام دهند.MapReduce یک مدل برنامه‌نویسی نسبتاً سطح پایین برای اجرای توزیع‌شده روی خوشه‌ای از ماشین‌ها است. زبان‌های پرس‌وجوی سطح بالاتر مانند SQL را می‌توان به‌صورت یک خط لوله (pipeline) از عملیات MapReduce پیاده‌سازی کرد (به فصل ۱۰ مراجعه کنید)، اما پیاده‌سازی‌های توزیع‌شده‌ی زیادی از SQL وجود دارند که از MapReduce استفاده نمی‌کنند. توجه کنید که در خود SQL هیچ چیزی وجود ندارد که آن را محدود به اجرا روی یک ماشین واحد کند، و MapReduce هم انحصار اجرای پرس‌وجوهای توزیع‌شده را در اختیار ندارد.امکان استفاده از کد JavaScript در میانه‌ی یک پرس‌وجو ویژگی بسیار خوبی برای پرس‌وجوهای پیشرفته است، اما این قابلیت فقط محدود به MapReduce نیست—برخی دیتابیس‌های SQL نیز می‌توانند با توابع JavaScript توسعه داده شوند.یکی از مشکلات کاربری MapReduce این است که باید دو تابع JavaScript که با دقت با هم هماهنگ شده‌اند بنویسید، که اغلب سخت‌تر از نوشتن یک پرس‌وجوی واحد است. علاوه بر این، یک زبان پرس‌وجوی اعلانی فرصت‌های بیشتری به بهینه‌ساز پرس‌وجو می‌دهد تا عملکرد پرس‌وجو را بهبود دهد. به همین دلایل، MongoDB در نسخه‌ی 2.2 پشتیبانی از یک زبان پرس‌وجوی اعلانی به نام aggregation pipeline را اضافه کرد.در این زبان، همان پرس‌وجوی شمارش کوسه‌ها به شکل زیر نوشته می‌شود:db.observations.aggregate([ { $match: { family: "Sharks" } }, { $group: { _id: { year: { $year: "$observationTimestamp" }, month: { $month: "$observationTimestamp" } }, totalAnimals: { $sum: "$numAnimals" } }}]);زبان aggregation pipeline از نظر قدرت بیان شبیه به زیرمجموعه‌ای از SQL است، اما به‌جای نحوِ جمله‌مانند SQL از نحو مبتنی بر JSON استفاده می‌کند؛ تفاوتی که شاید بیشتر به سلیقه برگردد. پیام نهایی داستان این است که یک سیستم NoSQL ممکن است ناخواسته در حال بازآفرینی SQL باشد، هرچند در لباسی مبدل.Graph-Like Data Modelsاین بخش دقیقاً جاییه که انتخاب مدل داده از «کدنویسی» می‌ره توی «تفکر معماری».ایده‌ی اصلی در یک جمله وقتی ارتباط بین داده‌ها زیاد و پیچیده می‌شه، جدول و داکیومنت اذیت می‌کنن؛ گراف طبیعی‌ترین مدل می‌شه.1️⃣ اول مسئله رو درست بفهمیمسه نوع رابطه‌ی رایج بین داده‌ها1. بدون رابطه یا خیلی کممثلاً:لاگ‌هاeventهاپیام‌ها📌 Document DB عالیه (Mongo)2. One-to-Many (درختی)مثلاً:بلاگ → پست‌ها → کامنت‌هاسفارش → آیتم‌ها📌 Document Model هنوز خوبه{ "post": "Graph DB", "comments": [ { "text": "good" }, { "text": "nice" } ] } 3. Many-to-Many (اینجا درد شروع می‌شه)مثلاً:کاربر ↔ گروهدانشجو ↔ درسآدم‌ها ↔ آدم‌ها (دوستی، ازدواج، فالو)📌 اینجا Relational سخت می‌شه📌 Document تقریباً شکست می‌خوره📌 Graph می‌درخشه2️⃣ چرا Many-to-Many با Document خوب نیست؟مثال:یک کاربر در ۱۰۰ گروههر گروه ۱۰۰۰ کاربراگر embed کنی:دیتا تکراریآپدیت کابوسconsistency مشکلاگر reference بدی:query پیچیدهjoin دستیperformance بد3️⃣ Relational چقدر جواب می‌ده؟Relational می‌گه:users groups user_groups تا اینجا اوکیه 👌اما وقتی:depth زیاد می‌شهرابطه روی رابطه می‌خوایtraversal می‌خوایمثلاً:دوستِ دوستِ دوستِ من کیه؟SQL شروع می‌کنه به زجر دادن.4️⃣ اینجا گراف وارد می‌شه 🔥گراف از چی تشکیل شده؟Vertex (Node)آدمشهرپسترویدادEdge (Relation)دوستِازدواج بازندگی می‌کند درشرکت کرده در5️⃣ مثال ساده از گراف(Lucy) --[married_to]-- (Alain) | | [lives_in] [lives_in] | | (London) (London) همه چیز رابطه‌محوره.6️⃣ چرا گراف طبیعی‌تره؟چون سؤال‌هامون رابطه‌ایه:لوسی کجا زندگی می‌کنه؟همسرش کیه؟دوستان همسرش کیان؟کیا توی لندن هستن و متأهلن؟در گراف:اینا traversal هستن، نه join7️⃣ مثال Query (حسی، نه سینتکس)SQL:JOIN JOIN JOIN Graph:Lucy → married_to → Alain → lives_in → London خواناطبیعینزدیک به مدل ذهنی انسان8️⃣ کاربردهای واقعی Graph DB1️⃣ شبکه‌های اجتماعیدوستفالولایککامنت📌 Facebook, LinkedIn2️⃣ Recommendationاینو دیدی → اونا رو هم دیدندوستات چی دوست دارن؟📌 Netflix, Spotify3️⃣ Fraud Detectionارتباط مشکوک بین حساب‌هاپول از کجا به کجا می‌چرخه؟📌 بانک‌ها4️⃣ مسیر‌یابیshortest pathcheapest route📌 Google Maps5️⃣ دانش‌نامه‌هاWikiKnowledge Graph📌 Google Search9️⃣ نکته‌ی خیلی مهمGraph DB برای «data with rich relationships» است، نه برای همه‌چیز❌ جایگزین همه دیتابیس‌ها نیست✔ کنار بقیه می‌درخشهجمله‌ی طلایی مصاحبه 🎯«وقتی پرسش‌های اصلی سیستم حول traversal رابطه‌ها می‌چرخد، Graph DB طبیعی‌ترین انتخاب است.»1️⃣ دو مدل اصلی گراف دیتا1️⃣ Property Graph Model(Neo4j، Titan، InfiniteGraph)تعریف سادهدر Property Graph:Node (Vertex) داریمEdge (Relationship) داریمهر دو می‌تونن Property داشته باشن (key-value)مثال ذهنی(:Person {name: "Lucy", from: "Idaho"}) -[:MARRIED_TO {since: 2015}]-> (:Person {name: "Alain", from: "France"}) ویژگی مهمNode و Edge هر دو دیتا دارنEdge فقط لینک نیست، خودش معنا داره📌 خیلی نزدیک به مدل ذهنی انسان📌 برای شبکه‌های اجتماعی عالیکاربرد واقعیSocial NetworkRecommendationFraud detection2️⃣ Triple-Store Model(Datomic، AllegroGraph، RDF)تعریف سادههمه‌چیز می‌شه سه‌تایی:(subject, predicate, object) مثال(Lucy, marriedTo, Alain) (Lucy, livesIn, London) حتی ویژگی‌ها:(Lucy, age, 30) ویژگی مهمساختار خیلی عمومیSchema آزادمناسب knowledge graph📌 رسمی‌تر📌 semantic web📌 استاندارد محور2️⃣ زبان‌های Query گراف (Declarative)1️⃣ Cypher (برای Property Graph)حس و حالCypher طوری طراحی شده که:Query مثل نقاشی گراف نوشته بشهمثالMATCH (p:Person)-[:MARRIED_TO]->(s:Person) RETURN p.name, s.name تقریباً شبیه جمله‌ی انگلیسی 😄📌 خیلی خوانا📌 محبوب برای Neo4j2️⃣ SPARQL (برای Triple Store)حس و حالSPARQL رسمی و استاندارده (W3C)SELECT ?person ?city WHERE { ?person :livesIn ?city . } 📌 شبیه SQL📌 مناسب knowledge graph و وب معنایی3️⃣ Datalogتعریف سادهDatalog یه زبان Rule-based استancestor(X, Y) :- parent(X, Y). ancestor(X, Y) :- parent(X, Z), ancestor(Z, Y). 📌 فکر کردن منطقی📌 مناسب inference و تحلیل عمیق3️⃣ Declarative بودن این زبان‌ها چرا مهمه؟همون حرف‌های قبلی ولی در گراف:✔ فقط می‌گی «چی می‌خوای»✔ traversal رو engine انجام می‌ده✔ optimizer مسیر رو انتخاب می‌کنه✔ parallelization ممکنه4️⃣ زبان‌های Imperative گراف (برای مقایسه)Gremling.V().has("name","Lucy").out("marriedTo").out("livesIn") اینجا:step به step می‌گی کجا برهtraversal مشخصه📌 انعطاف‌پذیر❌ سخت بهینه‌سازی❌ وابسته به ترتیبPrege (مثل Pregel)پردازش گراف‌های خیلی بزرگالگوریتم محور (PageRank)📌 analytics❌ query روزمره نیست5️⃣ چه موقع کدومو انتخاب کنیم؟ (خیلی مهم)Property Graph + Cypher✔ اپلیکیشن✔ query تعاملی✔ business logicTriple Store + SPARQL✔ knowledge graph✔ ontology✔ semantic dataGremlin / Pregel✔ تحلیل سنگین✔ batch processing✔ الگوریتم‌های گرافی6️⃣ جمع‌بندی سینیوری نهاییGraph DB خودش یک دنیا است:مدل داده + زبان پرس‌وجو + فلسفه‌ی فکر کردن.برای query روزمره، declarative؛ برای الگوریتم، imperative.جمله‌ی طلایی مصاحبه 🎯«Property graph برای اپلیکیشن‌ها طبیعی‌تر است، در حالی که triple-store برای داده‌های معنایی و inference مناسب‌تر است.»

خلاصه کتاب Designing Data-Intensive Applications

Setare Behzadi — Sun, 14 Dec 2025 22:43:39 +0330

فصل ۲- Query Languages for Data- قسمت۳تفاوت Imperative و Declarative1️⃣ Imperative یعنی «چطور انجام بده»وقتی با زبان‌های برنامه‌نویسی معمولی مثل Python / JS / Java کار می‌کنی، داری دستورالعمل می‌دی:اول این کار رو بکنبعد برو سراغ بعدیاگه شرط درست بود فلان کارحلقه بزن، متغیر عوض کن، ادامه بدهمثلاً:for (...) { if (...) { push(...) } } اینجا داری الگوریتم رو دقیق می‌نویسیکامپیوتر حق فکر کردن نداره، فقط اجرا می‌کنه.2️⃣ Declarative یعنی «چی می‌خوام»اما SQL اینجوری نیست. تو فقط می‌گی:من حیواناتی رو می‌خوام که خانواده‌شون Sharks باشهSELECT * FROM animals WHERE family = 'Sharks'; ❌ نمی‌گی:از کدوم ایندکس استفاده کناول کدوم رکورد رو بخونحلقه بزن یا نزنترتیب چطوره✔ فقط نتیجه مهمه، نه مسیر رسیدن بهش.چرا این فرق خیلی مهمه؟🧠 1. دیتابیس از تو باهوش‌ترهتو به عنوان برنامه‌نویس:حجم دیتا رو دقیق نمی‌دونیایندکس‌ها ممکنه عوض بشندیتابیس ممکنه توی چند ماشین پخش شده باشهQuery Optimizer داخل DB:می‌فهمه از کدوم ایندکس استفاده کنهjoin رو با چه الگوریتمی بزنهحتی ترتیب اجرا رو عوض می‌کنهاگر imperative بنویسی، دست دیتابیس بسته‌ست.🧱 2. پنهان شدن جزئیات پیاده‌سازیفرض کن:دیتابیس برای بهینه‌سازی، رکوردها رو جابه‌جا می‌کنهترتیب فیزیکی داده روی دیسک عوض می‌شهSQL می‌گه:من هیچ تضمینی روی order نخواستمپس دیتابیس آزاده.اما توی کد imperative:animals[0] ممکنه ناخواسته به ترتیب وابسته باشیو دیتابیس نمی‌تونه ریسک کنه.🚀 3. بهینه‌سازی بدون تغییر کداین خیلی مهمه:دیتابیس می‌تونه سریع‌تر بشهبدون اینکه تو حتی یک خط Query رو تغییر بدیچرا؟چون الگوریتم دست دیتابیسه، نه دست تو.⚡ 4. اجرای موازی (Parallelism)CPUها دیگه خیلی سریع‌تر نمی‌شن؛فقط core بیشتر دارن.Imperative:ترتیب مشخصstep به stepموازی‌سازی خیلی سختDeclarative:فقط می‌گه «نتیجه چی باشه»دیتابیس می‌تونه:دیتا رو تکه‌تکه کنهروی چند core / چند ماشین اجرا کنهآخرش نتیجه رو merge کنهجمع‌بندی🟢 Imperativeکنترل کامل داری، ولی مقیاس‌پذیری و بهینه‌سازی فاجعه می‌شه🟢 Declarative (مثل SQL)کنترل کمتر، ولی:سریع‌ترامن‌ترمقیاس‌پذیرترآینده‌دارتریک جمله طلایی برای یادت:SQL به دیتابیس می‌گه «چی می‌خوام»، نه «چطوری بهش برسی» — و همین باعث قدرتمند بودنشه.بریم یک لِول عمیق‌تر؛ همون توضیح قبلی، ولی این‌بار با نگاه معماری و تجربه‌ی واقعی پروژه(همونی که سینیورها بعد از یکی‌دو سیستم دردناک می‌فهمن 😄)1️⃣ Declarative vs Imperative در ORMها (جایی که همه زمین می‌خورن)ORM چی کار می‌کنه؟ORM (مثل Django ORM، SQLAlchemy، Hibernate):ظاهراً imperative می‌نویسیولی در واقع داری Declarative Query می‌سازیمثلاً:User.objects.filter(age__gt=18, is_active=True) این الگوریتم نیستاین فقط تعریف یک Query است.❌ هنوز اجرا نشده❌ هنوز دیتا نخونده✔ فقط یک AST / Query Plan ساختهاشتباه جونیوری رایج ❌users = User.objects.all() active_users = [u for u in users if u.is_active] مشکل:همه دیتا کشیده شدهفیلتر رفته توی اپلیکیشندیتابیس هیچ شانسی برای بهینه‌سازی نداره✔ نسخه درست:User.objects.filter(is_active=True) قانون طلایی ORMتا وقتی می‌تونی، دیتابیس رو مجبور کن فکر کنه، نه اپلیکیشن رو2️⃣ Declarative بودن یعنی «Lazy Execution»این خیلی مهمه 👇qs = User.objects.filter(is_active=True) اینجا:کوئری هنوز اجرا نشدهفقط تعریف شدهاجرا کی اتفاق می‌افته؟list(qs) qs.first() qs.count() این یعنی:ORM می‌تونه کوئری رو merge کنهفیلترها رو ترکیب کنهorder رو تغییر بدهDeclarative ⇒ قابل بهینه‌سازی3️⃣ وقتی Declarative رو می‌شکنی (Anti-patternهای خطرناک)❌ loop + queryfor user in users: user.posts.count() نتیجه:N+1 Queryدیتابیس خفه می‌شه✔ Declarative:User.objects.annotate(post_count=Count("posts")) اینجا:دیتابیس خودش JOIN می‌زنهaggregate می‌کنهبا یک query برمی‌گردونه4️⃣ Declarative در برابر Cache (Redis + DB)اینجا می‌رسیم به سؤال سینیوری 👀سناریو:دیتابیس: PostgreSQLکش: RedisQuery declarativeDB رکورد رو lock کرده (transaction)چی می‌شه؟DB: نسخه‌ی جدید رکورد داخل transactionRedis: هنوز نسخه‌ی قدیمیDeclarative بودن کمک می‌کنه چون:تو وابسته به order یا state نیستیفقط state نهایی مهمهالگوی درست:Cache Aside Patternبعد از commit → invalidate redisیا TTL کوتاهDeclarative Query کمک می‌کنه چون:نتیجه مهمه، نه مسیر رسیدن بهش5️⃣ Declarative ⇒ Parallel Execution (واقعی، نه شعاری)SQL:SELECT family, COUNT(*) FROM animals GROUP BY family; DB می‌تونه:جدول رو تکه کنههر core یه chunk رو بشمارهآخر merge کنهImperative code:for animal in animals: ... ❌ ترتیب مهمه❌ موازی‌سازی خطرناکه❌ race condition6️⃣ Declarative باعث می‌شه سیستم «آینده‌دار» باشهفرض کن:امروز دیتابیس کوچیکهفردا sharding می‌کنیپس‌فردا replica اضافه می‌کنیاگر کوئری‌هات declarative باشه:بدون تغییر کد scale می‌کنیاگر imperative باشه:کل بیزینس لاجیک باید rewrite بشه7️⃣ جمع‌بندی خیلی خلاصه🟢 Declarative:SQLORM QuerySetMap / ReduceElasticsearch DSL🔴 Imperative:loopifmutable stateorder-dependent logicجمله‌ای که باید حک کنی تو مغزت:هرجا دیتا زیاد می‌شه، Imperative می‌میره و Declarative زنده می‌مونه.Declarative Queries on the Webاین دقیقاً همون قسمتی است که مفهوم Declarative از دیتابیس میاد توی زندگی واقعی وب.ایده‌ی اصلی این بخش چیه؟ (یک جمله‌ای)Declarative فقط مخصوص SQL نیست؛ هرجا «چی می‌خوام» رو بگی و «چطور انجام بده» رو بسپاری به سیستم، داری declarative کار می‌کنی.وب (CSS، XSL، حتی React) پر از declarative است.1️⃣ سناریو سادهسایت درباره‌ی حیوانات دریایی داریم 🐟کاربر روی صفحه‌ی Sharks هست.HTML:

Sharks

Whales

می‌خوای:عنوان صفحه‌ی انتخاب‌شده آبی بشه2️⃣ راه Declarative (CSS) ✅li.selected > p { background-color: blue; } این خط چی می‌گه؟من دنبال

می‌گردمکه پدرش

باشهو اون

کلاس selected داشته باشههمونا رو آبی کن❗ نکته مهم:نگفتی loop بزننگفتی چک کن چندتا هستنگفتی کی اضافه کن یا حذف کنفقط الگو (pattern) رو گفتی.3️⃣ چرا این فوق‌العاده‌ست؟مزیت 1: اتوماتیک به تغییرات واکنش می‌دهاگر:

← حذف بشه CSS خودش:می‌فهمه rule دیگه match نمی‌کنهرنگ آبی رو حذف می‌کنه❌ هیچ کدی دوباره اجرا نمی‌کنی✔ سیستم خودش sync می‌مونه4️⃣ راه Imperative (JavaScript DOM) ❌var liElements = document.getElementsByTagName("li"); for (var i = 0; i < liElements.length; i++) { if (liElements[i].className === "selected") { var children = liElements[i].childNodes; for (var j = 0; j < children.length; j++) { if (child.tagName === "P") { child.setAttribute("style", "background-color: blue"); } } } } این کد چی می‌گه؟برو همه liها رو بگیردونه‌دونه loop بزنشرط بذاربچه‌هاشو بگرداگه p بود، style ست کن🤮 طولانی🤮 fragile🤮 سخت نگهداری5️⃣ مشکل‌های خطرناک Imperative (خیلی مهم)❌ مشکل 1: حالت برنمی‌گردهاگر بعداً:li.className = "" چی می‌شه؟رنگ آبی باقی می‌مونه 😐باید کد جدا برای remove بنویسیدر حالی که CSS:✔ خودش اضافه و حذف رو مدیریت می‌کنه❌ مشکل 2: وابستگی به APIاگر مرورگر:API سریع‌تر بدهالگوریتم داخلی رو عوض کنهتو باید:کدت رو rewrite کنیولی CSS:✔ مرورگر بهینه‌سازی می‌کنه✔ کدت ثابت می‌مونه6️⃣ تشبیه مستقیم با دیتابیس (اینجا مغز قفل می‌کنه 🔥)CSS در وب ≈ SQL در دیتابیسوب دیتابیسCSS در وب ≈ SQL در دیتابیسli.selected > p مثل:WHERE family = 'Sharks' 7️⃣ کاربردهای واقعی Declarative در وب (خیلی مهم)1️⃣ CSSStylingResponsive designDark mode@media (max-width: 768px) { ... } 2️⃣ React / Vue / Angular{isSelected && } تو نمی‌گی:createElementappendChildremoveChildDeclarative UI 😎3️⃣ XPath / XSLتبدیل XMLگزارش‌گیریPDF generation4️⃣ حتی QuerySelectordocument.querySelector("li.selected > p") Declarative‌تر از loop.8️⃣ جمله‌ی مهم نهایی (حفظ کن)«CSS هم مثل SQL یک زبان declarative است؛ من فقط الگوی نتیجه را مشخص می‌کنم و موتور اجرا خودش تصمیم می‌گیرد چطور آن را اعمال کند.»جمع‌بندی خیلی خلاصه🟢 Declarative:کوتاهقابل بهینه‌سازیخودکار با تغییرات sync می‌مونهآینده‌دار🔴 Imperative:verbosefragileپر از edge caseسخت نگهداری

خلاصه کتاب Designing Data-Intensive Applications

Setare Behzadi — Sun, 14 Dec 2025 21:56:56 +0330

فصل ۲- Data Models and Query Language- قسمت۲Are Document Databases Repeating History?خلاصهٔ ایده اصلیکتاب می‌گوید:آن‌چیزی که امروز در Document Databaseها می‌بینیم، قبلاً در دهه ۶۰–۸۰ هم در سیستم‌های قدیمی اتفاق افتاده بود.یعنی Document DBها چیز کاملاً جدیدی نیستند؛بلکه نسخه مدرن مدل‌های hierarchical و network databases قدیمی هستند.📌 داستان تاریخی کوتاه🔹 دهه ۶۰–۷۰:قبل از SQL، دیتابیس‌ها دو مدل اصلی داشتند:1) Hierarchical Modelداده‌ها در قالب درخت ذخیره می‌شدند→ دقیقاً مثل Document DBمثال:Company ├── Departments │ ├── Employees │ ├── Projects هر داده فقط یک parent داشت.2) Network Modelدارای لینک‌های پیچیده بین رکوردها بود (شبیه گراف)ولی کار با آن وحشتناک سخت بود:باید مسیر traversal را خودت بنویسیاگر ساختار عوض می‌شد، کل برنامه می‌ریخت🔹 چرا SQL انقلاب شد؟SQL آمد و گفت:«شما فقط بگو چه داده‌ای می‌خواهی،من خودم چطور پیدا کردنش را انجام می‌دهم.»یعنی زبان declarative+ساختار زیرین abstract شد+join آسان شددر نتیجه:maintenance بهترتوسعه سریع‌ترکد کمترquery قوی‌تربه همین دلیل relational model سلطه پیدا کرد.⭐ پیام کتاب: Document DBها در حال تکرار آن تاریخ هستندDocument databaseها (مثل MongoDB):مدلشان درختی (hierarchical) استjoin ندارند (یا ضعیف)هر document یک “parent document” دارد → شبیه همان مدل ۶۰ سال پیشوقتی data interconnected شود، مجبور می‌شوی reference و join دستی بسازیو دوباره همان مشکلات مدل‌های قدیمی بر می‌گرددکتاب می‌گوید:possibility دارد دوباره به همان مشکلات تاریخی برسیم.🔥 مثال مهم که کتاب اشاره می‌کندمثالی که از رزومه لینکدین (Bill Gates profile) زد، دقیقاً همین را نشان می‌دهد:در JSON:{ "user": { ... }, "positions": [...], "education": [...], "contact_info": {...} } تا اینجا همه‌چیز خوب است چون ساختار درختی است.اما وقتی این نیازها اضافه می‌شوند:school خودش یک entity استorganization خودش یک entity استrecommendation بین دو user ایجاد می‌شود (many-to-many)این entityها باید share شوندdata به هم لینک می‌شودjoin لازم می‌شودنتیجه؟→ درختی بودن مدل document فرو می‌ریزد→ دوباره به همان دردسر مدل network / hierarchical برمی‌گردیم→ باید خودت join بنویسی→ پیچیدگی explode می‌شوداین همان historical repeat است.🎯 کاربرد عملی این بخش برای یک برنامه‌نویسیک برنامه نویس باید یاد بگیرد کجا Document DB انتخاب کند و کجا نه.📌 Document DB عالی است زمانی که:داده ساختار درختی داردتغییرات schema زیاد استنیاز به read تک-document سریع داریمداده روابط پیچیده نداردمثال:فروشگاه → سفارش → آیتم‌های سفارشBlog → پست → کامنت‌هاEvent → ticket → attendeesجریان فعالیت‌ها (activity feed)📌 Document DB بد است زمانی که:داده روابط زیاد و پیچیده داردmany-to-many زیاد داریمjoinهای متعدد لازم استداده shared بین entityهای مختلف استمثال:شبکه اجتماعی مثل لینکدینسیستم حقوقی / ارتباطات قضاییERP / حسابداریسیستم دانشگاهی (درس، استاد، واحد، ترم…)CRM پیچیدهسیستم بیمه (که خودت هم توش کار می‌کنی)در این سیستم‌ها:→ SQL بهتر است→ یا حتی Graph DB (مثل Neo4j)⭐ جمع‌بندی Document DBها در اصل نسخه مدرن مدل‌های قدیمی hierarchical هستند.این مدل‌ها در داده‌هایی که روابط زیاد دارند، سریع می‌ترکند.join نداشتن باعث پیچیدگی کد و duplication می‌شود.SQL اختراع شد تا همین مشکلات را حل کند و هنوز هم بهترین ابزار برای relational data است.یک برنامه‌نویس باید انتخاب کند:tree-like → Document DBgraph/relationship-heavy → Relational DB

Designing Data-Intensive Applicationsخلاصه کتاب

Setare Behzadi — Fri, 12 Dec 2025 18:07:34 +0330

فصل ۲- Data Models and Query Language- قسمت۱Relational Model vs Document Model1️⃣ Relational Model (مدل رابطه‌ای)ساختار: داده‌ها در جدول‌ها (tables) با ردیف (row) و ستون (column) ذخیره می‌شوند.Schema: حتماً schema ثابت دارد؛ یعنی قبل از ذخیره‌سازی، باید ساختار جدول‌ها مشخص باشد.Query: با SQL می‌گیریم: SELECT * FROM users WHERE age > 30ACID: تراکنش‌ها قوی هستند؛ یک رکورد یا چند رکورد با اطمینان کامل update/delete می‌شوند.مثال عملی:بانک، سیستم حسابداری، ERPهر جایی که داده‌ها مرتب، دقیق، و تراکنش محور هستندنکته:وقتی consistency مهم است و روابط بین موجودیت‌ها زیاد است، relational بهترین گزینه است.2️⃣ Document Model (مدل سندی)ساختار: داده‌ها به صورت اسناد (documents) ذخیره می‌شوند، معمولاً JSON یا BSON.Schema: schema می‌تواند dynamic باشد؛ هر سند می‌تواند فیلدهای متفاوت داشته باشد.Query: با query مخصوص DB:db.users.find({ age: { $gt: 30 } }) ACID: معمولاً تراکنش‌ها محدود به یک سند هستند (MongoDB recent versions چند سند را هم پشتیبانی می‌کند)مثال عملی:اپلیکیشن وب با داده‌های user-generated مثل پروفایل، پست، کامنتسیستم‌هایی که تغییرات schema زیاد است و انعطاف می‌خواهندنکته :وقتی سرعت read/write مهم است، یا schema مدام تغییر می‌کند، document model راحت‌تر و سریع‌تر است.3️⃣ تفاوت کلیدی به زبان سادهویژگیRelationalDocumentSchemaثابت انعطاف‌پذیرRelationstable join embedded یا reference Query SQL JSON-like query Use Caseتراکنش حساس اپلیکیشن web/mobile4️⃣ مثال واقعی برای یک پروژهفرض کن داری سیستم رزرو کلاس آنلاین می‌سازی:Relational:جدول users, courses, enrollmentsjoin‌ها زیاد، query پیچیده اما تراکنش‌ها امن هستندDocument:collection users با embed کردن enrollmentsراحت read/write، schema تغییر می‌کند (مثلاً اضافه شدن field جدید در enrollments)💡 نکته حرفه‌ای:هیچ وقت “یک مدل برای همه پروژه‌ها” نیست. اگر داده‌ها transactional و مرتب هستند → relational. اگر سریع، flexible و JSON-friendly هستند → document.The Birth of NoSQL1️⃣ چی شد که NoSQL به وجود آمد؟در دهه ۲۰۱۰، بعضی شرکت‌ها به مقیاس‌پذیری خیلی بالا نیاز داشتند، چیزی که relational DBها به سختی می‌توانستند بدهند.همچنین خیلی‌ها می‌خواستند schema انعطاف‌پذیر داشته باشند تا با تغییرات سریع اپلیکیشن هماهنگ شوند.نام NoSQL در اصل یک هشتگ توییتر بود، ولی بعداً معنای واقعی آن شد: Not Only SQL → یعنی فقط SQL نیست!2️⃣ چرا NoSQL محبوب شد؟Scalability بالا: دیتاست‌های بزرگ یا write-heavy workloads راحت‌تر مدیریت می‌شوند.Open-source: ترجیح شرکت‌ها به جای DBهای تجاری، DBهای رایگان و متن‌باز.Query خاص: بعضی عملیات query مثل search روی JSON یا graph، در relational سخت یا کند است.Flexibility: schema dynamic → راحت می‌توان فیلد جدید اضافه کرد بدون migration پیچیده.3️⃣ کجاها کاربرد دارد؟مثال کاربردی:Social Media : ذخیره پست‌ها و کامنت‌ها به صورت document (MongoDB)Analytics / Logs : ذخیره لاگ‌ها با write-heavy workload (Cassandra)Real-time Recommendations: کش و دیتاست dynamic (Redis, DynamoDB)Graph-like Data شبکه اجتماعی، روابط کاربران (Neo4j)💡 نکته مهم:NoSQL قرار نیست جای relational را بگیرد؛ بلکه مکمل آن است. ایده polyglot persistence یعنی برای هر بخش اپلیکیشن، بهترین دیتاست را انتخاب می‌کنیم.مثال: کاربران و تراکنش‌ها → relational؛ پست‌ها و کامنت‌ها → document DB؛ لاگ‌ها → wide-column DB.4️⃣ مثال عملی کد (Document DB)فرض کن داری سیستم شبکه اجتماعی می‌سازی و می‌خوای پست‌ها و کامنت‌ها را ذخیره کنی:db.posts.insertOne({ userId: "123", content: "Hello world!", comments: [ { userId: "456", text: "Nice post!" }, { userId: "789", text: "Great!" } ], tags: ["fun", "intro"], createdAt: new Date() }); اگر می‌خواستی همین کار را با relational انجام دهی، باید جدول‌های جداگانه بسازی و join بزنی → پیچیده و کند برای حجم بالا.💡 جمع‌بندی :NoSQL = ابزار مناسب برای داده‌های بزرگ، write-heavy، یا schema-dynamic.Relational = ابزار مناسب برای تراکنش‌ها و consistency بالا.Hybrid approach = اغلب بهترین راه.The Object-Relational Mismatch1️⃣ مسئله اصلیتو داری اپلیکیشن با OOP می‌نویسی: کلاس‌ها و آبجکت‌ها.مثال:class User: def __init__(self, id, first_name, last_name, positions): self.id = id self.first_name = first_name self.last_name = last_name self.positions = positions # لیست شغل‌ها دیتابیس relational: جدول، ردیف، ستونجدول users: فقط id, first_name, last_nameجدول positions: user_id, job_title, organizationمشکل: آبجکت تو یک ساختار tree-like (User → Positions → Education) دارد ولی relational DB flat است.برای fetch یک user با همه positions، باید چند query یا join پیچیده انجام دهی.این disconnect بین آبجکت و جدول را می‌گویند impedance mismatch ⚡2️⃣ راه‌حل‌های معمولالف) Traditional SQL (Normalized)هر child object → جدول جداforeign key برای ارتباطSELECT * FROM users u JOIN positions p ON u.id = p.user_id WHERE u.id = 251; ✅ مزیت: تراکنش‌ها امن، consistency❌ عیب: query پیچیده، fetch یک آبجکت کامل سختب) Structured / JSON column در SQLبرخی DBها مثل PostgreSQL، MySQL، SQL Server اجازه می‌دهند که ستون‌ها JSON یا XML باشندمی‌توان چند value را در یک row ذخیره کردquery روی داخل JSON هم امکان‌پذیر استSELECT data->'positions' FROM users WHERE id = 251; ✅ ساده‌تر، locality بهتر⚠ هنوز تراکنش‌ها محدود به row، و بعضی queryها پیچیده هستندج) Full Document / JSON in Document DBکل object → یک سند JSONمثال MongoDB:db.users.insertOne({ user_id: 251, first_name: "Bill", last_name: "Gates", positions: [ { job_title: "Co-chair", organization: "Bill & Melinda Gates Foundation" }, { job_title: "Co-founder, Chairman", organization: "Microsoft" } ], education: [ { school_name: "Harvard University", start: 1973, end: 1975 } ], contact_info: { blog: "...", twitter: "..." } }); ✅ یک query کافی برای fetch کل object✅ ساختار tree-like آبجکت حفظ می‌شود✅ schema flexible، می‌توان فیلد جدید اضافه کرد بدون migration⚠ تراکنش multi-document محدودتر⚠ query پیچیده نیاز به index و aggregation داردمثال واقعی و تصمیم‌گیریپروژه شبکه اجتماعی:کاربران و پروفایل‌ها → Document DB (MongoDB)چون user → posts, comments → tree-like استیک query کافی کل اطلاعات را fetch می‌کندتراکنش مالی یا حسابداری → Relational DB (PostgreSQL)ACID مهم است، consistency باید حفظ شودجمع‌بندی :وقتی داده‌ها self-contained و tree-like هستند، Document DB بهترین انتخاب است.وقتی transaction-heavy و consistency-critical هستند → Relational DB بهترین است.در دنیای واقعی اغلب hybrid approach یعنی ترکیب هر دو، رایج است.Many-to-One and Many-to-Many Relationshipsموضوع دربارهٔ اینه که چرا بعضی فیلدها رو به جای متن، باید به صورت ID ذخیره کنیم و این موضوع چطور باعث ایجاد رابطه‌های many-to-one و many-to-many می‌شه — و چرا این روابط در document DBها (مثل MongoDB) دردسر بیشتری دارن.🔶 1) چرا region و industry رو به صورت ID ذخیره می‌کنیم، نه متن؟کتاب میگه در مثال رزومه (مثل پروفایل لینکدین)، به‌جای این‌که:"region": "Greater Seattle Area", "industry": "Philanthropy" بیایم و ذخیره کنیم:"region_id": 23, "industry_id": 7 ❗ چرا؟ ۵ دلیل خیلی مهم:1️⃣ یکپارچگی در املاء و ظاهراگر ۱۰ میلیون کاربر وجود داشته باشه، هرکی یه جور می‌نویسه:seattleSeattleGreater Seattle AreaSeattle areaبا ID این مشکل حل می‌شود.2️⃣ جلوگیری از ابهامدو تا شهر هم‌نام وجود داره:Paris در فرانسهParis در تگزاساگر فقط string ذخیره کنیم، ambiguity داریم.با ID هیچ ابهامی نیست.3️⃣ تغییر نام بدون مشکلاگر فردا به دلیل سیاسی نام منطقه عوض شود،→ فقط یک بار در جدول region تغییر می‌دهی→ تمام پروفایل‌ها به‌روز می‌شناگر متن مستقیم ذخیره شده بود؟→ باید میلیون‌ها رکورد را update کنی→ احتمال inconsistency خیلی زیاد می‌شه4️⃣ امکان ترجمه‌ی اتوماتیک (localization)وقتی عبارت "Greater Seattle Area" یک ID باشد،→ نمایش آن در UI می‌تواند مطابق زبان کاربر نمایش داده شود.مثلاً کاربر آلمانی:„Großraum Seattle“کاربری در ایران:«منطقه بزرگ سیاتل»بدون تغییر در دیتابیس اصلی.5️⃣ بهبود جستجواگر ID باشد: دیتابیس می‌داند Seattle در Washington است.اما اگر فقط متن باشد:دیتابیس این معنی را نمی‌فهمد مگر خودت بنویسی.⭐ نتیجهٔ این بخش:استفاده از ID باعث می‌شود اطلاعات ثابت فقط در یک جا ذخیره شود→ این همان Normalization است.🔶 2) چرا این کار باعث ایجاد many-to-one می‌شود؟مثال:میلیون‌ها کاربرولی فقط ۲۵۰۰ شهریا فقط ۲۰۰ صنعتیعنی:many users → one industry many users → one region ➡️ این خودِ many-to-one است.در relational database → کاملاً طبیعیدر document database → مشکل‌زا، چون join سخت است و باید دستی انجام شود.🔶 3) نقش Document DB و مشکل Joinدر MongoDB:join وجود نداردیا فقط aggregate lookup هست ولی ضعیف‌تر از SQLبنابراین معمولاً embedding ترجیح دارداما در این مثال‌ها، embedding بد است چون:اگر industry تغییر کند → باید همه رزومه‌ها update شونداگر اسم region عوض شود → همه را باید تغییر بدهییعنی duplication خطرناک می‌شوداین یعنی:document model برای داده‌هایی با روابط زیاد، مناسب نیست.🔶 4) وقتی سیستم بزرگ می‌شود، داده‌ها interconnected می‌شوندکتاب می‌گوید:حتی اگر اول پروژه ساده باشد، در آینده روابط زیاد می‌شود و از کنترل خارج می‌شود.مثال‌هایی که کتاب می‌زند:1️⃣ Company و School را از string تبدیل به entity کنیمابتدا ذخیره می‌کردی:"company": "Microsoft" ولی می‌خواهی یک صفحه برای شرکت داشته باشی(لوگو، توضیحات، news feed و …)پس تبدیل می‌شود به:"company_id": 55 حالا:میلیون‌ها رزومه به یک company_id وصل هستند→ many-to-one2️⃣ توصیه‌نامه (Recommendation)کاربر A به کاربر B توصیه‌نامه می‌دهد.در رزومه‌ی B نمایش داده می‌شود.ولی اطلاعات A مثل عکس پروفایل اگر عوض شود باید همه‌جا آپدیت شود.پس در recommendation ذخیره می‌کنی:"author_user_id": 123 → باز هم ID→ باز هم join لازم→ باز هم many-to-oneاما رزومه B شامل توصیه‌نامه‌های متفاوت از چند نفر است→ پس می‌شود many-to-many:User (writers) →← Recommendations →← User (receivers) 🔶 5) مثال کامل و ساده‌سازی شکل کتاب (شکل 2-4)تصور کن رزومه مثل لینکدین است:یک کاربر می‌تواند:در چند شرکت کار کندچند مدرک تحصیلی داشته باشداز چند نفر توصیه‌نامه بگیردبه چند نفر توصیه‌نامه بدهدسازمان‌ها و مدرسه‌ها خود entity شوندregion / industry هم entity باشددر نتیجه:user ←→ company → many-to-manyuser ←→ school → many-to-manyuser ←→ recommendation ←→ user (دوربرگرد)یعنی:هر ویژگی جدید → یک رابطه جدید → پیچیدگی بیشتر → نیاز به join بیشتربه همین دلیل document DBها به مشکل می‌خورند.🔥 جمع‌بندی به زبان سادهاطلاعات انسانی تکرارشونده باید با ID ذخیره شونداین کار Normalization استاین باعث Many-to-One و Many-to-Many می‌شودSQL برای join فوق‌العاده استDocument DBها برای join ضعیف هستندپروژه‌ها وقتی بزرگ می‌شوند، داده‌ها interconnected می‌شونددر نهایت، مدل Document صرفاً برای موارد tree-like خوب استمثل سفارش → آیتم‌های سفارشپست → کامنت‌هااما برای شبکه‌های اجتماعی، رزومه، سیستم‌های جستجو:Relational یا Graph DB بهتر است

نحوه پیاده سازی Rate Limiting در لاراول 8

Setare Behzadi — Sun, 13 Feb 2022 18:41:56 +0330

برای من جای سوال بود که آیا می توان میزان ترافیک یک route یا گروهی از route های معین را در لاراول با استفاده از یک محدود کننده(Rate Limiting)محدود کنید؟ یعنی یک فرم رو فقط یکبار سابمیت کنید و چندین بار درخواست ثبت فرم ارسال نشود. البته راههای زیادی برای فرانت وجود دارد اما بک اند چگونه میتواند هندل کند؟ مفهوم Rate Limitingفهوم Rate Limiting یعنی این‌که ما می‌توانیم میزان ترافیک ورودی برای یک روت یا گروهی از روت‌ها را محدود کنیم، برای اضافه کردن یک ریت‌لیمیتر (Rate Limiter) ابتدا باید آن را در متد configureRateLimiting در کلاس App\Providers\RouteServiceProvider اضافه نماییم.لاراول شامل سرویس‌های rate-limiting قدرتمند و قابل تنظیم است و با استفاده از آن سرویس می‌توانیم تعداد درخواست‌هایی را برای یک مسیر یا گروهی از مسیرها محدود کنیم.بنابراین در این آموزش به شما نشان خواهم داد که چگونه می توانیم با استفاده از میدلور throttle، محدودیت نرخ ( rate-limiting)را در لاراول پیاده سازی کنیم. بنابراین در این آموزش خواهید آموخت که چگونه می‌توانیم سیستم dynamic rate limiting لاراول را ایجاد کنیم تا درخواست‌های بیش از حد کاربران را مسدود کنیم.ما برای ساخت rate limiting در سیستم اپلیکیشنی لاراول خود از فساد RateLimiter استفاده میکنیم.در نمونه کد زیر throttle لاراول با کلاس rate limiter class پیاده سازی شده است.app\Providers\RouteServiceProvider.phpnamespace App\Providers; use Illuminate\Cache\RateLimiting\Limit; use Illuminate\Foundation\Support\Providers\RouteServiceProvider as ServiceProvider; use Illuminate\Http\Request; use Illuminate\Support\Facades\RateLimiter; use Illuminate\Support\Facades\Route; class RouteServiceProvider extends ServiceProvider { public const HOME = '/home'; public function boot() { $this->configureRateLimiting(); } protected function configureRateLimiting(): void { RateLimiter::for('test', function (Request $request) { return Limit::perMinute(1); }); } }همانطور که میبینید در روش configureRateLimiting بالا، ما فقط یک درخواست در دقیقه ارسال کرده‌ایم. حال چگونه می توانیم از این در مسیر خود استفاده کنیم:routes/web.phpuse Illuminate\Support\Facades\Route; Route::middleware(['throttle:test'])->group(function () { Route::get('/', function () { return view('welcome'); }); });همانطور که میبینید ما باید از میدلور throttle استفاده کنیم و بعد از clone، باید نام rate limitter خود را پاس دهیم. این نام بطور دلخواه نامگذاری میشود.امیدوارم این مطلب برای شما یاری دهنده باشد. منبع: مکتب شریف و سایت کد شف

نوشتن پیام های Commit در گیت

Setare Behzadi — Fri, 17 Dec 2021 12:33:31 +0330

وقتی در تیمی شروع به کار و کدزنی می کنید یکی از مهمترین ابزارها برای تعامل در کدزنی استفاده از گیت است. پیام های کامیت خیلی مهم هستند و چالشی که شاید اکثر برنامه نویس ها استفاده کننده از گیت با آن روبرو هستند، انتخاب متنی مناسب برای commit است. در این مقاله به مواردی که میتواند در commit نویسی تمیز و خوانا موثر باشد، پرداخته شده است. 1- خلاصه کوتاه از کاری که کردید را بنویسید. 2- هر لاینی بهتر است که بیشتر از 50 تا کاراکتر(حرف) نباشد چون در یک صفحه باید قابل نمایش باشد. هرچه لاین کمتر باشد خوانایی بیشتر است و بهتر خوانده میشود. البته میشود خط رو هم بشکونید یک خط سفید و در خط های بعدی توضیحات کاری رو که کردید رو دنبال کنید که البته این مورد اختیاری است. اما اگر این خط را نذارید گیت همه را در یک خط قرار میدهد و مانند wordProcessor های دیگر مثل microsoft word نیست که خودش خط را بشکوند. به عبارتی دیگر کامیت های گیت word wrap ندارد. 3- پیام ها را بصورت فعل حال (present tense )بنویسید نه فعل ماضی(past tense). مثال درست fix bug. 4- بجای استفاده از بولت پوینت ها از ستاره و یا خط فاصله استفاده کنید. برای مرتب کردن متن .5- البته برای سریعتر خواندن میتوانید از شماره گذاری هم استفاده کنید. [js,css,htm] message در مثال بالا نشان میدهد که پیامتون در مورد فرانت هست و در مورد programming نیست .bugfix: messageیعنی باگی را درست کردین و پیام مربوط به باگی که فیکس شده جلوش قرار میدهید. #23 - messageشماره گذاری کنید. هشتگ نماد معرف شماره کامیت میباشد. در تصویر زیر نمونه ایی از کامیت های نادرست و درست آورده شده است. مقایسه کامیت های خوب و یددر عکس بالا مورد آخر، بدترین شکل کامیت کردن هست که تغییرات را نمایش نمیدهد و حالت یک مکالمه است که اصلا درست نیست. در تصویر زیر یک نمونه کامیت درست را نمایش می دهد : نمونه ای از کامیت صحیحکه کامیت شماره گذاری دارد و بعد با یک خط خالی آنرا جدا کرده است و بقیه متن را نوشته است. شما چه استانداردها و الگوهایی رو برای کامیت نویسی رعایت میکنید. کامنت بزارید که من هم استفاده کنم. منبع: پارس کلیک

آمار بازدید پست‌های من در سال ۹۹

Setare Behzadi — Sat, 03 Apr 2021 09:53:30 +0430

در طول تاریخ از اعداد استفاده کردیم تا اغلب داد و ستد کنیم و آن‌چیزی که شمردنی است را بشماریم. برای هر عدد واحد درست کردیم تا عددهای زندگی قاطی نشوند و از اعداد، شفاف‌تر استفاده کنیم؛ مثلا وقتی می‌گوییم ده هزار تومان به پول اشاره داریم و وقتی می‌گوییم ده هزار بلیط به بلیط!روز به روز که در زندگی جلو‌تر رفتیم عددها فرقی نکردند ولی این واحدها بودند که زیاد شدند. واحد کریپتو، واحد اصله درخت، واحد فاصله و …«واحد» یک توافق عمومی است برای شمردن؛ تا همانطور که گفتم شمردن‌ها قاطی نشود. مشاهده افراد دارای ثروت (اجتماعی یا مالی) به من ثابت کرده اینکه چه چیزی را بشماریم از اینکه چطور بشماریم مهم‌تر است. هرکس با واحد خاصی مسائل زندگی را می‌شمارد. اینطور به نظرم آمده که مشخص کردن واحد یعنی مشخص کردن اینکه من در زندگی برای چه چیزهایی ارزش قائلم و می‌خواهم چه چیزهایی را در زندگی بشمارم. https://cdn.virgool.io/annual-report/1399/ehj1caqedojr-nrX1Y.mp4 اعدادی که بدون واحد ثبت کردمبه ویدیویی که ویرگول برایم ساخته که نگاه می‌کنم میبینم که در سال ۹۹، من در مجموع ۷,۵۱۱ کلمه در ویرگول نوشتم و منتشر کردم و مخاطبین، پست‌های من را ۱۱۲ مرتبه پسندیدند و ۱۱ بار هم نظر خود را روی پست‌های من به اشتراک گذاشتند. در سال ۹۹، ۶۹ نفر در ویرگول من را دنبال کردند تا پست‌های بعدیم را بخوانند. این اعداد نشان میدهند من کاری کرده‌ام. هرکدام به واحدی وصل هستند. از خودم می‌پرسم من کدام واحد را شمارش کرده‌ام؟ کدامیک از واحدهای بالا از همه برای من مهم‌تر است؟ ادامه ویدیو را می‌بینم.آمار از اثر بیرونی می‌گویندطبق آمار پست‌های من ۲,۸۴۴ بار خوانده شدند و ۴۲۷,۵۵۸ ثانیه صرف مطالعه آنها شده است، که با توجه به جمعیتی که در ایران به اینترنت دسترسی دارند، ویرگول به من می‌گوید که توانستم ۰/۰۰۵۸۶۱۷۷۷ ثانیه، سرانه مطالعه دیجیتال کشور را بالا ببرم.از طرف دیگر ویرگول به من می‌گوید که اگر قرار بود پست‌هایم را چاپ و به دست تک تک خوانندگان برسانم باید ۸,۶۵۵ کاغذ مصرف می‌کردم.آن عددهای کوچک ابتدای ویدیو حالا تبدیل شده‌اند به عددهای بزرگ به اینکه من جلوی مصرف این تعداد کاغذ را گرفتم یا به اینکه من ۰/۰۰۵۸۶۱۷۷۷ ثانیه، سرانه مطالعه دیجیتال کشور را جابه جا کرده‌ام. واحد این عددها برای من ملموس‌تر است.واحد نوشتن چیست؟همه عددهای بالا و همینطور اثر بیرونی که روی خوانندگان و همینطور در مقیاس بزرگتر طبیعت و جامعه اطرافم گذاشتم اعدادی هستند که من دوستشان دارم و به آنها افتخار می‌کنم. اگر چنین ویدیویی دست شما نیز رسید به شما بابت تک تک اعداد تبریک می‌گویم.اثر هر نوشته تا حدودی معلوم است، اگر بنویسید جلوی قطع درخت را می‌گیرید، به سرانه مطالعه کشور اضافه می‌کنید و خوانندگانی جذب می‌کنید که شما را از طریق نوشته‌هایتان می‌شناسند و …به نظرم می‌رسد که نوشته‌های من و شما واحد ندارند ولی اثر بیرونی دارند.

معرفی Trait Class بعنوان یک Mixin Class

Setare Behzadi — Mon, 22 Mar 2021 22:48:59 +0430

برای اینکه متوجه مزایا و معایب و کاربردهایی Trait Classشویم بهتر است که ابتدا با مفهوم Mixin Class آشنا شویم. همانطور که می دانیم، جهت پیاده سازی یک شی ابتدا باید یک شی نمونه ایجاد کرد. برای این منظور یک نمونه کلاس تعریف میشود. Mixin Class کلاسی است که شامل متدهای کلاس های دیگر است. به عبارتی عملگرهای کلاس های دیگر را در خود نگه میدارد. این کلاس واسط هایی را فراهم میکند که از طریق آنها میتوان به متدهای درون کلاس دسترسی پیدا کرد. در واقع متدهای مشترکی که اغلب کلاس ها به آن نیاز دارند در Mixin Class تعریف میشوند. چرا که نمیتوان همه ی این متدها را در داخل سایر کلاسها تعریف کرد. بنابراین همه متدها در یک کلاس تعریف میشود تا در صورت نیاز، هرکدام از کلاسها بتوانند از عملگر موردنظر موجود در Mixin Class استفاده کنند و از آن ارث ببرند. کلاس trait ها یک مفهومی است که در php ورژن 5.4 معرفی شد و کاربرد اصلی اونها از بین بردن محدودیتی بود که کلاس های php با آن روبه رو بودند. یکی از مشکلاتی که در PHP به عنوان یک زبان برنامه نویسی وجود دارد این است که تنها می تواند یک ارث بری داشته باشد. این به این معنی است که یک کلاس تنها می تواند از یک کلاس دیگر ارث ببرد.با این حال، در بسیاری از مواقع ارث بری از چندین کلاس می تواند مفید باشد. به عنوان مثال،ارث بری متدها از چندین کلاس مختلف برای جلوگیری از تکرار کدها مطلوب و پرکاربرد است.کلاس trait یک صفت نوعی مانند Mixin است که اجازه می دهد کلاس های Trait را به یک کلاس موجود اضافه کنید. این بدان معنی است که شما می توانید کدهای تکراری را کاهش دهید و مزیت های زیادی را ضمن اجتناب از مشکلات ارث بری چندگانه به دست آورید.برای اینکه بیشتر با مثالها و نحوه ی چگونگی استفاده از کلاس trait آشنا شوید پیشنهاد میکنم مقاله ی "هر آنچه که باید از php trait بدونیم" خوانده شود زیرا مفصلا به مثالها و ارورهای احتمالی و ... پرداخته است.

الگوی طراحی Factory Method و Abstract Factory

Setare Behzadi — Fri, 18 Dec 2020 18:57:11 +0330

همانطور که در مقاله ی "الگوی طراحی simple factory(فکتوری)" گفته شد الگو فکتوری، سه حالت دارد:simple factory، factory methodو static factory. در این مقاله به بررسی دونوع دیگر آن پرداخته میشود. الگوی طراحی Factory Methodبه بیان ساده میتوان گفت که factory method یک راه برای ایجاد و توسعه اشیاء در subclass ها میباشد. زیر کلاسها مسئول ایجاد جزئیات هستند. این الگو داخل کلاس interface یا abstract تعریف شده و instantiation در زیر کلاسها انجام میشود.مقاله ی خود را با یک مثال شروع میکنیم. دپارتمان استخدام نیروی جدید را درنظر بگیرید. وجود یک مصاحبه کننده برای تمام موقعیتهای شغلی غیر ممکن است. چون مصاحبه کننده به تخصص نیاز دارد. به همین دلیل بر اساس فرصتهای شغلی موجود، مدیر استخدام باید در مورد مصاحبه کننده تصمیم بگیرد و این موضوع را به افراد متفاوتی واگذار کند.پیشنهاد این است که بجای ساخت مستقیم یک obj جدید از هریک از مصاحبه کننده ها از factory method استفاده کنید. در نگاه اول ، این حرکت ممکن است بی معنی به نظر برسد: ما فقط تماس سازنده را از یک قسمت برنامه به قسمت دیگر منتقل کردیم. با این حال ، این را در نظر بگیرید: اکنون می توانید روش دپارتمان را در یک زیر کلاس نادیده بگیرید و کلاس مصاحبه کننده ی ایجاد شده با این روش را تغییر دهید.مثال برنامه نویسی در مثال مدیریت استخدام، ابتدا interface مصاحبه کننده و نمونه هایی از آن را برای موقعیتهای شغلی مورد نظرمان پیاده سازی میکنیم.interface Interviewer { public function askQuestions(); }حال کلاسهایی که راجع به موقعیت های شغلی متفاوت هستند و باید این قرارداد تعریف شده در اینترفیس را تعریف کنند را میسازیم.class Developer implements Interviewer { public function askQuestions() { echo 'Asking about design patterns!'; } } class Accounter implements Interviewer { public function askQuestions() { echo 'Asking about wages!'; } }حال نوبت به پیاده سازی مدیر استخدام (HiringManager )است. که در اینجا همان تعریف فکتوری متد ما صورت میگیرد. abstract class HiringManager { // factory method abstract protected function makeInterviewer(): Interviewer; public function takeInterview() { $interviewer = $this->makeInterviewer(); $interviewer->askQuestions(); } }در این کلاس ابسترکت ما دو متد تعریف کردیم. که یکیشون مصاحبه کننده را میگیرد و دیگری مصاحبه کننده موردنظر را میسازد. با دقت در method factory در کلاس بالا متوجه میشوید که با این روش کلاسهای فرزند میتوانند به راحتی آن را توسعه دهند و البته که متد ابسترکت تعریف شده باید حتما با توجه به ماهیت کلاس و متد در کلاس فرزندان تعریف شود(منبع).class DevelopmentManager extends HiringManager { protected function makeInterviewer(): Interviewer { return new Developer(); } } class AccounterManager extends HiringManager { protected function makeInterviewer(): Interviewer { return new Accounter (); } }نحوه ی استفاده:$devManager = new DevelopmentManager(); $devManager->takeInterview(); // Output: Asking about design patterns $marketingManager = new MarketingManager();$marketingManager->takeInterview(); // Output:Asking about wages!قابلیت استفاده: - زمانیکه وابستگی های بین اشیاء نامشخص است و نمیدانید چه زیر کلاسی دقیقا ً ممکن است نیاز باشد. - وقتی چندین کلاس با منطق مشترک دارید و به دنبال راهی برای توسعه اجزای داخلی کلاس های اصلی هستید. method factory باعث میشود یک طراحی قابل تنظیم تر اما پیچیده داشته باشید. این پیچیدگی بد نیست، چون با استفاده از آن به جای نیاز به ایجاد کلاس ها فقط عملیات جدید را پیاده سازی می کنید.شما میتوانید مثال پرداخت را برای این مثال نیز درنظر بگیرید. و در کامنت ها به آن بپردازید. یوزکیس بعدی هم که ازین الگوی طراحی استفاده میکند repository در لاراول است که در آینده به آن پرداخت میشود(منبع). الگوی طراحی Abstract Factoryبه بیان ساده Abstract Factory به شما امکان میدهد که خانواده ای از اشیا مرتبط بدون class concrete آنها را تولید کنید. همچنین به ما این امکان را میدهد که برای ایجاد اشیاء از یک الگوی کلی پیروی کنیم. تعریف concrete classکلاسی که تمام متدهای آن پیاده سازی شده است و متدهای غیر قابل اجرا ندارند.مثال در دنیای واقعیشما یک درب چوبی از فروشگاه درب های چوبی، درب آهنی از فروشگاه درب های آهنی و همچنین درب PVC از فروشگاه مرتبط نیاز دارید که تهیه کنید. به علاوه اینکه نیاز به متخصص برای نصب دربها نیز دارید. نجار برای درب چوبی و جوشکار برای درب آهنی. همانطور که میبینید بین دربها وابستگی هایی وجود دارد (نجار و جوشکار)در ابتدا یک interface از درب و پیاده سازی هایی از آن را داریم:interface Door { public function getDescription(); } class WoodenDoor implements Door { public function getDescription() { echo 'I am a wooden door'; } } class IronDoor implements Door { public function getDescription() { echo 'I am an iron door'; } }سپس برای تعریف متخصص هم یک اینترفیس تعریف میکنیم و برای هرنوع درب یک متخصص خواهیم داشت(نجار و جوشکار)interface DoorFittingExpert { public function getDescription(); } class Welder implements DoorFittingExpert{ public function getDescription() { echo 'I can only fit iron doors'; } } class Welder implements Carpenter{ public function getDescription() { echo 'I can only fit iron doors'; } }تا اینجا کلاس های وابسته/مرتبط را پیاده سازی کردیم. اکنون factory abstract را مینویسیم که امکان تشکیل خانواده اشیاء مرتبط را برای ما فراهم میکند. کارخانه درب چوبی یک درب و متخصص درب چوبی را ایجاد میکند و کارخانه درب آهنی هم یک درب و متخصص درب آهنی را میسازد.interface DoorFactory { public function makeDoor(): Door; public function makeFittingExpert(): DoorFittingExpert; } // Wooden factory(concrete factory) to return carpenter and wooden door class WoodenDoorFactory implements DoorFactory { public function makeDoor(): Door {return new WoodenDoor(); } public function makeFittingExpert(): DoorFittingExpert { return new Carpenter(); } } // Iron door factory(concrete factory) to get iron door and the relevant fitting expert class IronDoorFactory implements DoorFactory { public function makeDoor(): Door { return new IronDoor(); } public function makeFittingExpert(): DoorFittingExpert { return new Welder(); } }شیوه ی استفاده و تست : $woodenFactory = new WoodenDoorFactory(); $door = $woodenFactory->makeDoor(); $expert = $woodenFactory->makeFittingExpert(); $door->getDescription();// Output: I am a wooden door $expert->getDescription(); // Output: I can only fit wooden doorsو برای درب آهنی: // Same for Iron Factory $ironFactory = new IronDoorFactory(); $door = $ironFactory->makeDoor(); $expert = $ironFactory->makeFittingExpert(); $door->getDescription();// Output: I am an iron door $expert->getDescription(); // Output: I can only fit iron doorsقابلیت استفاده - در یک طراحی خوب هر کلاس فقط مسئول یک چیز است. زمانیکه یک کلاس با انواع مختلفی از محصولات سروکار دارد نیاز به پیاده سازی این الگو احساس خواهد شد. - هنگامی که سیستم نیاز به مستقل بودن از چگونگی ایجاد، ترکیب و نمایش آن دارد. - وقتی ایجاد اشیاء مرتبط به سادگی امکانپذیر نیست. در صورتی که وابستگی های متقابل بین اشیاء وجود دارد instantiation آنها به صورت تکی/جداگانه منطقی خواهد بود. برای مشاهده مثال و توضیح متفاوت و بدون درنظر گرفتن زبان خاصی میتوانید به سایت refactoring.guru مراجعه کنید. درخواستی هم که دارم در صورتیکه useCase ای برای این الگو داشتین کامنت بزارید بلکه بتوانیم در زمینه ی برنامه نویسی به روند پیشرفت منابع فارسی کمکی کرده باشیم.

الگوی طراحی Decorator به زبان ساده در لاراول

Setare Behzadi — Mon, 24 Aug 2020 10:19:06 +0430

در این آموزش قصد داریم تا با Decorator Design Pattern در قالب مثالی کاربردی در فریمورک لاراول آشنا شویم. همانطور که میدانیم Decorator یکی از زیرشاخه‌های الگوهای طراحی Structural (ساختاری) است و به‌کارگیری از آن در شرایطی موجب بهبود پروسه ی توسعه ی اپلیکیشن می‌شود که دولوپرها بخواهند تا یکسری فیچر خاص را به کلاس مد نظر خود بیفزایند. بعبارتی دیگر هدف از پیاده سازی الگوی Decorator اضافه کردن یک وضعیت و یا یک رفتار (Behavior) به یک کلاس بدون تغییر دادن آن می باشد. این عمل میتواند کاملا به صورت داینامیک انجام شود. این دو مشخصه (تغییر نکردن کلاس فعلی و داینامیک بودن)، Decorator را تبدیل به یکی از پرکاربردترین الگوهای طراحی شیء گرا کرده است.قبل از اینکه به پیاده سازی مثال برسیم، به این نکته توجه کنیم که خب شاید بشه از ارثبری هم استفاده کرد! ولی به سه دلیل استفاده از این الگو اولویت بالاتری داری:نکته ی اول، با دیدن مثالهای زیر متوجه میشیم که این الگو در نهایت دست ما را خیلی بازتر میگذارد و قابلیت توسعه پذیری بالاتری به ما میدهد، و با اینکه شاید بعضی وقتا برای پیاده سازی، کمی پیچیدگی اضافه کند، ولی در مجموع اگه سر جای خودش استفاده بشود بسیار ساخت یافته تر هست.نکته ی دوم، زمانی که تعداد کلاس کمی ارثبری می کنند شاید بتونیم به یکسری موارد دقت کنیم و سعی کنیم پیچیدگی را کم کنیم، ولی با زیاد شدن کلاسها، این الگو به ما کمک می کند که بتونیم مدیریت بهتری روی آنها داشته باشیم.نکته ی سوم هم اینکه ما با استفاده از ارثبری، در زمان کامپایل تمام ویژگی های کلاس پدر را به فرزندانش و طبیعتاً به همه ی اشیائ اون کلاس ها منتقل میکنیم، در صورتی که با الگوی decorator، میتوانیم در زمان اجرا یا همون runtime، تغییرات دلخواه خود را بر اساس نیازمان، در یک شئ خاص استفاده کنیم.(منبع)طرح مسئلهفرض کنید که ما یک مدل به نام postداریم:class Post Extends Model { public function scopePublished($query) { return $query->where('published_at', '<=', 'NOW()'); } }و در PostController ما متدی مانند زیر را داریم:class PostsController extends Controller { public function index() { $posts = Post::published()->get(); return $posts; } }جهت کش کردن پست ها و جلوگیری از زدن کوئری و اتصال به دیتابیس در هربار فراخوانی لیست پست ها، می توانیم موارد زیر را انجام دهیم:class PostsController extends Controller { public function index() { $minutes = 1440; # 1 day $posts = Cache::remember('posts', $minutes, function () { return Post::published()->get(); }); return $posts; } }اکنون ما پست ها را برای یک روز کش می کنیم. اما با نگاه کردن به کد کنترلر متوجه می شویم که اطلاعات زیادی به کنترلر داده شده است. بطور مثال در کنترلر تعداد روزهایی که ما داده ها را کش می کنیم ، محاسبه و در خود نگه می دارد.همچنین ، تصور کنید که شما دقیقا همین متد کش را برای برچسب ها ، دسته ها ، آرشیو ها که در HomePageController هستند، بخواهید اجرا کنید. که تعداد اتصال به دیتابیس و کوئری زدن خیلی زیاد خواهد بود.الگوی طراحی Repository patternدر بیشتر موارد ، الگوی Repository به الگوی دکوراتور متصل می شود . چگونه؟ در ادامه خواهیم دید.ابتدا بیایید نحوه دریافت پست ها با استفاده از Repository pattern را بررسی کنیم.ابتدا فایل app/Repositories/Posts/PostsRepositoryInterface.php را با کدهای زیر ایجاد می کنیم: namespace App\Repositories\Posts; interface PostsRepositoryInterface { public function get(); public function find(int $id); }در همان آدرس فایل دیگری با نام PostsRepository با محتویات زیر می سازیم:namespace App\Repositories\Posts; use App\Post; class PostsRepository implements PostsRepositoryInterface{ protected $model; public function __construct(Post $model) { $this->model = $model; } public function get() { return $this->model->published()->get(); } public function find(int $id) { return $this->model->published()->find($id); } }حال به PostsController می رویم، و تغییرات زیر را در آن اعمال می کنیم:namespace App\Http\Controllers; use App\Repositories\Posts\PostsRepositoryInterface; use Illuminate\Http\Request; class PostsController extends Controller { public function index(PostsRepositoryInterface $postsRepo) { return $postsRepo->get(); } }الان PostsController ما به شکل قابل قبول درآمد.الان ما به IOC Laravel نیاز داریم تا بتوانیم شیء ساخته شده از اینترفیس Posts را برای دریافت پست های منتشر شده، تزریق کنیم.تنها کاری که ما باید انجام دهیم این است که به IOC Laravel بگوییم که در هنگام استفاده از Interface، کدام کلاس را ایجاد کند. برای اینکار بصورت زیر عمل می کنیم.در فایل app/Providers/AppServiceProvider.php متد bind را اضافه می کنیم. namespace App\Providers; use App\Repositories\Posts\PostsRepositoryInterface; use App\Repositories\Posts\PostsRepository; use Illuminate\Support\ServiceProvider; class AppServiceProvider extends ServiceProvider { public function register() { $this->app->bind(PostsRepositoryInterface::class,PostsRepository::class); } }اکنون هر زمان که ما PostsRepositoryInterface را فراخوانی کنیم، نمونه ای از PostsRepository ایجاد میشود و دیتاهای لازم را به ما برمیگرداند.اجرای کش کردن داده ها از طریق الگوی طراحی Decorator همانطور که گفتیم، الگوی طراحی Decorator اجازه می دهد یک رفتار(متد) بدون اینکه روی سایر اشیاء از همان کلاس تأثیر بگذارد ،روی یک شی خاص از آن کلاس متد اجرا شود.دراینجا، آن object/class از ریپوزیتوری PostsRepository ساخته می شود و آن رفتار خاص، کش کردن (caching) داده هاست. قبل از هرچیزی ابتدا ریپوزیتوری مربوط به کش کردن اطلاعات پست(PostsCacheRepository) را در دایرکتوری app/Repositories/Posts/PostsCacheRepository.php بصورت زیر ایجاد کنیم:namespace App\Repositories\Posts; use App\Post; use Illuminate\Cache\CacheManager;class PostsCacheRepository implements PostsRepositoryInterface { protected $repo; protected $cache; const TTL = 1440; # 1 day public function __construct(CacheManager $cache, PostsRepository $repo) { $this->repo = $repo; $this->cache = $cache; } public function get() { return $this->cache->remember('posts', self::TTL, function () { return $this->repo->get(); }); } public function find(int $id) { return $this->cache->remember('posts.'.$id, self::TTL, function () { return $this->repo->find($id); }); } }در این کلاس، ابتدا شی ای از کلاس cache و پست PostsRepository دریافت می کنیم، سپس از کلاس (دکوراتور) جهت اعمال رفتار کش کردن بر روی نمونه object ساخته شده از PostsReposiory، استفاده می کنیم.ما می توانیم از همین مثال برای ارسال درخواست های HTTP به برخی سرویس ها استفاده کنیم و در صورت عدم موفقیت و fail شدن دوباره به مدل برگردد. تا اینجا، به مزیت های استفاده از الگوی طراحی پی برده شده است.آخرین قدم تعریف کردن PostsCacheRepository در فایل AppServiceProvider است که بجای PostsRepository از PostsCacheRepository استفاده شود.namespace App\Providers; use App\Repositories\Posts\PostsRepositoryInterface; use App\Repositories\Posts\PostsCacheRepository; use Illuminate\Support\ServiceProvider; class AppServiceProvider extends ServiceProvider { public function register() { $this->app->bind(PostsRepositoryInterface::class,PostsCacheRepository::class); } }اکنون هرگاه فایل ها مجدد بررسی شود، متوجه می شویم که خواندن و نگهداری آنها بسیار آسان شده است. همچنین، قابلیت تست کردن و reuse و recode کردن آنها بسیار افزایش یافته است.شما فقط باید اتصالات(binding) را در AppServiceProvider تغییر دهید و نیاز به هیچ کار اضافی برای تغییر نیاز وجود ندارد.نتیجه گیریدر این مقاله آموختیم که اطلاعات مربوط به مدل ها را با استفاده از الگوی طراحی Decorator چگونه کش کنیم. چگونگی اتصال الگوی طراحی Repository با Decorator را نشان داده شد.دیدیم که چگونه Dependecy Injection و IOC Laravel زندگی کدنویسی ما را آسان می کند.متوجه شدیم که امکانات لاراول چقدر قدرتمند هستند.امیدوارم که از خواندن مقاله لذت برده باشید. هدف این مقاله این بود که قدرت الگوهای طراحی و چگونگی آسان سازی حفظ و مدیریت پروژه ها را به نمایش بگذارد. بخش مثال های این مقاله از ترجمه ی مقاله ای که در اینجا هست، گرفته شده است.

چرخه Request ها در لاراول ( Request Life Cycle of Laravel )

Setare Behzadi — Sat, 08 Aug 2020 19:20:42 +0430

هنگامی که شروع به کار بر روی یک فریمورک می کنیم ، ابتدا باید دقیقاً بدانیم که چگونه کار می کند. این دانش کار ما را برای استفاده از این بستر فریمورک راحت تر می کند.این نوشته به شما کمک می کند تا با چرخه درخواست ها در لاراول Request Life Cycle of Laravel آشنا شوید ، یعنی به درک نحوه چگونگی پردازش درخواست ها در مراحل مختلف و ارائه پاسخ به کاربر ، به شما کمک کند. ما برای درک بهتر این روش را به صورت مرحله به مرحله بررسی خواهیم کرد.مرحله اول : Auto Loaderبه عنوان اولین مرحله ، درخواست از مرورگر کاربر شروع می شود ، سپس به سرور وب می رسد. سرور وب (Apache یا Nginx) درخواست داده شده را به فایلی در مسیر Laravel public / index.php هدایت می کند که یک نقطه شروع برای بارگذاری بقیه فریمورک است. این فایل autoloader ای که توسط composer ساخته شده است را لود میکند.سپس با لود شدن autolader ، نمونه ای از برنامه Laravel از اسکریپت bootstrap / app.php بازیابی میشود. یعنی در اولین مرحله ، لاراول خودش نمونه ای از برنامه را ایجاد می کند. بطور مثال بوت استرپ را در این مرحله میشود اینگونه تشبیه کرد که وقتی بعنوان راننده سوار میشید، اولین مرحله چک کردن آینه ها و بستن کمربند و .... میباشد. مرحله دوم: Kernelمرحله بعدی در قسمت هسته برنامه( KERNEL) اعمال خواهد شد.بسته به نوع درخواستی که وارد برنامه می شود ، درخواست دریافتی به HTTP kernel یا console kernel ارسال می شود.این دو نوع KERNEL به عنوان مکان اصلی برای اجرای همه درخواست ها میباشند.هسته یا کرنل HTTP ، در برنامه Http / Kernel.php قرار داده شده است. این kernel فقط یک درخواست دریافت می کند و یک پاسخ ارسال می کند. بوت استرپرهایی که توسط کلاس Kernel تعریف شده اند ، مسئولیت رسیدگی به خطا ، پیکربندی ورود به سیستم (configure logging) ، مسیریابی های تعریف شده در فایل env و سایر کارهایی را که باید قبل از انجام درخواست ارسالی انجام شود را برعهده دارد . کرنل HTTP همچنین لیستی از middleware هایی که قبل از استفاده از برنامه باید مورد توجه قرار بگیرد را نیز تعریف خواهد کرد. مرحله سوم: Service Providersمرحله بعداز گذشتن از kernelها، لود کردن ارائه دهندگان خدمات (Service Providers) هستند که بخشی از عملکرد های bootstrapping میباشند. Service Providers مورد نیاز برای برنامه در فایل onfig/app.php قرار دارند.همینطور که متدهای تعریف شده صدا زده میشوند، تمام providers ثبت می شوند. پس از ثبت و تعریف همه ی providers ، روش های بوت providers ها صدا زده میشود. providers ها روش های بت متفاوتی دارند که در با استفاده از آنها صدا زده میشود که در مقالات آتی به آنها میپردازم. مرحله چهارم: Dispatch Requestپس از راه اندازی برنامه و ثبت و راه اندازی همه Service Providers، درخواست برای ارسال به روتر تحویل داده می شود. که همان web.php یا app.php میباشد. سپس روتر درخواست را به یک مسیر یا کنترلر مدنظر ارسال می کند ، و همچنین در صورت نیاز هر middleware خاصی را برای مسیر اجرا می کند.مرحله پنجم: Routerاکنون درخواست توسط روتر به کنترلر یا مسیر موردنظر منتقل می شود و ریکوئست ارسالی مطابق روند زیر در پایان قابل مشاهده خواهدبود:روتر درخواست های HTTP را به کنترلر هدایت می کند یا با حذف کنترلر ، نمایش یا پاسخ ها را مستقیماً باز می گرداند. این مسیرها در فایل app/routes.php قرار دارند.کنترلر ها که در مسیر app/controllers/ قرار دارند، اقدامات خاصی را انجام داده و داده ها را به یک view ارسال می کند.ویوها که در مسیر app/views/ قرار دارد، قالب داده ها را بصورت مناسبی جهت پاسخ در HTTP آماده میکند و ارائه میدهد. مراحل فوق به طور واضح در نمودار زیر توضیح داده شده است. Request Life Cycle of Laravelقدم اول: یوزر ابتدا آدرس سایت موردنظر را در مرورگر خود تایپ میکند . مثلا: http://xyz.comقدم دوم: پس از وارد کردن این URL توسط کاربر و کلیک کردن، مرورگر درخواست صفحه را از طریق اینترنت به سرور وب ارسال می کند.قدم سوم: وب سرور درخواست را دریافت می کند و اطلاعات درخواست را تجزیه و تحلیل می کند. در فایل config سرور، مسیر اصلی سایت مشخص شده است. بر این اساس ، وب سرور به دنبال فایل index.php در آن مسیر است، زیرا URL شامل هیچ زیر فهرست یا مسیر دیگری نیست.قدم چهارم: سرور درخواست را به فایل index در مسیر public/index.php برنامه لاراول هدایت می کند.قدم پنجم: در این مرحله ، PHP Interpreter کدهای موجود در فایل index.php را اجرا می کند. در این مرحله ، فایلهایauto loader موجود در composer لود می شوند.قدم ششم: سپس نمونه برنامه ای از لاراول را ایجاد کرده و اجزای لاراول را بوت می کند.قدم هفتم: کرنل درخواست را دریافت می کند ، اservice providers ها را لود و به روتر هدایت می کند.قدم هشتم:روتر محتوای فایل viewراrender میکند و به سرور برمیگرداند.قدم نهم:سرور خروجی را بصورت PHP دریافت می کند و آن را از طریق اینترنت به مرورگر وب کاربر ارسال می کند.قدم دهم: مرورگر وب کاربر، response را از سرور دریافت می کند و صفحه وب را در رایانه کاربر ارائه میدهد.نتیجهبا درک چرخه عمر درخواست ها در لاراول، Request Life Cycle of Laravel ، ضمن تهیه یک برنامه ، اعتماد به نفس بیشتری خواهیم داشت. همچنین مهارت کافی برای اشکال زدایی در کد با روشی سریع تر فراهم میشود و ما می توانیم در برخی شرایط غیر منتظره به راحتی مسائل را پیگیری کنیم.

چرایی و چگونگی استفاده از Query Scope در لاراول

Setare Behzadi — Sun, 05 Jul 2020 23:22:35 +0430

در این مقاله به چگونگی ایجاد و استفاده از Query Scopeدرelloquent های مدل لاراول میپردازیم. همچنین نحوه ایجاد و استفاده آن بصورت پویا در برنامه های وب لاراول را نشان میدهیم.هنگامیکه شما روی برنامه های کوچک و بزرگ لاراولی کار میکنید، متوجه میشوید که گرفتن داده ها توسط کوئری ها بعضا تکراری و ممکنه زمانبر باشد که در این شرایط استفاده از Query Scope ها بسیار سودمند است و شما براحتی میتوانید با استفاده از Query Scope ها اطلاعات لازم را از دیتابیس خود دریافت کنید.به عبارتی دیگر شما با استفاده از Query Scope های لاراول در وقت خود برای نوشتن کد دوباره و دوباره، صرفه جویی کرده اید و همچنین می توانید به راحتی کوئری های خود را بارها مورد استفاده قرار دهید.تعریف Query Scope در مدل لاراولساخت Basic Scope در مدلاکنون ، شما می توانید نحوه ایجاد و استفاده از دامنه را در مدل لارول خود بیاموزید. برای ایجاد و استفاده از scope در مدل خود بصورت زیر عمل میکنیم. بطور مثال مدل پستی داریم که از کوئری مربوط به گرفتن پست های فعال بسیار استفاده میکنیم. $query->where('status', 1); بجای استفاده مدام از کوئری بالا در تمام برنامه ی خود به شکل زیر Query Scope تعریف میکنیم.where('status', 1); } } ?>چگونگی استفاده از آن در کنترل یا جاهای دیگرحال شما برای استفاده از query scope فقط لازم است به شکل زیر عمل کنید:Post::status()->get(['id','title']);بدیهی است که شما میتوانید مجموعه شرط هایی داخل اسکوپ خود نیز تعریف کنید. چگونگی تعریف Query Scope پویا (Dynamic) در مدل لاراولمرحله بعدی، دانستن این موضوع است که چگونه Query Scope را میتوان بصورت داینامیک استفاده کرد. خیلی راحت در مدل مثلا پست بصورت زیر:where('status', type); } } ?>و در کنترلر برنامه خودتون بصورت زیر فراخوانی اش میکنید:Post::status(1)->get(['id',title']);استفاده از scope در Relation های لاراولحال وقتشه که بدانیم که در relation ها به چه صورت مورد استفاده قرار میگیرند. مثلا در نظر بگیرید که هر بسته بندی ای تعداد زیادی پست دارد .مانند زیر:class Category extends \Eloquent { public function posts() { return $this->HasMany('Post'); } }به مدل پست رفته و در آن تابعی جهت ایجاد ریلیشن مطابق زیر تعریف میکنیم:class Post extends \Eloquent { public function category() { return $this->belongsTo('Category'); } public function scopePublished($query) { return $query->where('published', 1); } }حال به چه صورت این رابطه را فراخوانی میکنیم؟ بصورت زیر:$categories = Category::with(['posts' => function ($q) { $q->published(); }])->get();حال اگر تا اینجا متوجه داستان شدین و مایل بودین که بیشتر بدانید میتوانید از داکیومنت لاراول کمک بگیرید و اینجا کلیک کنید.

لاراول: چگونگی استفاده از Accessors و mutators

Setare Behzadi — Sun, 31 May 2020 19:54:32 +0430

آیا تاکنون مجبور شده اید قبل از ذخیره کردن داده ها در دیتابیس تغییری بر روی آنها بدهید؟ یا حتی بخواهید ترکیبی از داده های چند ستون متفاوت را نمایش دهید؟ پاسخ احتمالاً بله خواهد بود ، فکر نکنم کسی باشد. اینجاست که مفهوم Accessors و mutators میتواند به مرحله اجرا در بیاید.اجازه بدین تا به شما نشان دهم منظورشان چیست و چگونه کار می کنند.اکسسورس (Accessors )فرض کنید ما در جدول کاربر(user) برای کاربران خود دو فیلد داریم: first_name و last_name. و اگرچه در صورت لزوم می توان از این دو قسمت استفاده کرد ، اما گاهی اوقات برای نشان دادن نام کامل به عنوان یک پارامتر ، نیاز به ترکیب این دو پارامتر میباشیم، به طور کلی باید عملیاتی بر روی آنها انجام دهیم. این کار را به دوصورت میتوان انجام داد:1- روش ساده (لوحانه){{ $user->first_name . ' ' . $user->last_name }}2- به روش لاراول{{ $user->full_name }}در این روش شما با اضافه کردن یک تابع در مدل مربوط به user می توانید به راحتی با یک پارامتر به تمامی پارامترها دست پیدا کنید.ما برای تعریف این تابع به مدل مربوطه رفته و تابع موردنظر را به این صورت تعریف میکنیم:public function getFullNameAttribute() { return $this->first_name . " " . $this->last_name; }بنابراین اتفاقی که در اینجا می افتد، اینگونه است که ما تابعی را ایجاد کرده ایم که هر بار که نام کامل (full_name) فراخوانی می شود از این تابع که در مدل هست نام کامل را با ترکیب نام و نام خانوادگی بر میگرداند. برای تعریف Accessors فقط کافی است از الگوی ()get[attribute_name]Attribute پیروی کنید. امایی وجود دارد.شما نمی توانید از این ویژگی (full_name) درelequent queries استفاده کنید ، می توانید از این ویژگی فقط در collection استفاده کنید ، زیرا همانطور که میدانید elequent queries بر روی فیلدهای دیتابیس پردازش میکنند. بطور مثال کد زیر را درنظر بگیرید:$users = User::orderBy('full_name')->get();این کد کار نمیکند. اما:$users = User::all()->sortBy('full_name');مورد فوق بخوبی کار میکند زیرا sortBy بر روی collection ها کار کند. بنابراین پس از جمع آوری نام کامل کاربران می توانیم با استفاده از تابع sortBy آن را مرتب کنیم.میوتیترز (Mutators)اگر با زبان OOP کار کرده اید ، با روش های setter و getter آشنا هستید. بنابراین ، Accessors نقش getter و Mutators نقش setter را دارد .بعبارتی دیگر، فرض کنید ما یک company_ name داریم و می خواهیم وقتی در دیتابیس ذخیره می شود بصورت حروف بزرگ باشد. ما می توانیم با استفاده از Mutators به آن دست یابیم.public function setCompanyNameAttribute($value) { $this->attributes['company_name'] = strtoupper($value); }و میتوان بصورت زیر استفاده کرد:$user->company_name = Input::get('company');$user->save();در لاراول ، هر شی از مدل دارای دو مقدار اصلی و ویژگی است و با تغییر هر مقدار در collection، ما در واقع مقدار ویژگی را تغییر می دهیم و این همان چیزی است که در دیتابیس ذخیره می شود یا در blade یا هر روشی که مایلید میتوانید استفاده کنید. امیدوارم که این پست را دوست داشته باشید./

تعریف Interface در شی گرایی

Setare Behzadi — Fri, 03 Apr 2020 15:45:04 +0430

همانطور که گفته شد Abstract Class ها میتوانستند شامل مجموعه ای از متدهای abstract باشند یا نباشند و متدها با بدنه درون آنها قرار داشته باشد. ام اینترفیس ها در برنامه نویسی شی گرا لازم است که همه ی متدهایش Abstract باشد. بعبارتی دیگر هیچ متدی که دارای بادی نباید باشد.سوالی که در میان است این است که چرا باید Class ای داشته باشیم که دربرگیرنده ی متدهای abstract که هیچ گونه پیاده سازی ندارد،باشد؟ زیرا یک سری ساختار برنامه نویسی هستند که بصورت قرارداد هستند و با استفاده از آنها یک سری force ها و قوانینی وضع کنیم که بقیه باید از آن قوانین پیروی کنند. خصوصیت Interface ها چیست؟ تمامی متدهایی که در Interface ها قرار دارد همگی abstract هستند ولی عموما از کلمه abstract برای آنها استفاده نمیشود.ویژگی بعدی Interface ها این است که آنها نمیتوانند property داشته باشند و اگر احیانا داشته باشند از نوع ثابت هستند که در php از کلمه کلیدی Const استفاده میشود و property ها را فقط از نوع ثابت داریم. متدها و اعضای Interface باید publicباشند تا بقیه کلاس ها بتوانند آنها را Implement کنند. برای تعریف یک کلاس بصورت Interface باید از کلمه کلیدی Interface استفاده کرد. Interface ویژگی های کلاس countable بصورت Interface تعریف شده است و میگوید هرکسی از این کلاس بخواهد استفاده کند باید آن را ابتدا Implement کند و باید درون خودش متدی به نام count با بادی تعریف کند که در هربار اجرا آن را پیاده سازی کند. برای استفاده از Abstract Class ها از extend استفاده میشود و مفهوم ارث بری را دارد. اما در Interface ها از مفهوم پیاده سازی با کلمه ی کلیدی Implements استفاده میکنیم و باید تمامی متدهای درون آن را در کلاسی که آنرا implement کرده پیاده سازی شود.همانطور در شکل زیر میبینید یک کلاس میتواند چندین Interface را Implement کند، که اصطلاحا به آن multiple inheritance گفته میشود. multiple inheritanceهمانطوری که گفته شد Interface ها شامل متدهایی هستند که بدنه ندارند و ناقص هستند اما قراردادهایی رو الزام میکنند. در این مثال پست باید تمامی متدهای درون لاگر و countable را پیاده سازی کند و از طرفی این کلاس پست میتواند پدر کلاس های دیگر باشد. تفاوت Abstract Class و Interfaceدر Interface ها متدها همه abstract هستند اما Abstract Class میتواند Abstract داشته باشد یا نه، در Abstract Class ها قابلیت functionality میتوانند داشته باشند و میتوانند متدهای با بادی را به اشتراک بگذارند، اما Interface ها صرفا قرارداد دارد و هیچ بادی ای ندارد. اما هردو قرارداد را تعریف میکند. مثال را میتوانید به زبان php در سایت گیگ ببینید .

تعریف abstract class در شی گرایی

Setare Behzadi — Wed, 01 Apr 2020 18:41:43 +0430

برای شروع تعاریف قبلش باید با مفاهیم method signature و method implementation آشنا باشیم که ابتدا به این موارد میپردازم و سپس به کلاس های مذکور. کد زیر را در نظر بگیرید: public static int sum(int a,int b,int c) // به این قسمت میگن method signature // int is format of output { //از اینجا این میشه method implemantation return a+b+c ; }تعریف کلی ساختار متد این است که از دو بخش تشکیل شده است : 1-method signature2-method body(implementation body)این تعریف زمانیکه میخواهیم abstract class رو توضیح دهیم به درد میخورد. تعریف abstract methodدر زبان فارسی abstract به معنی خلاصه است و متد Abstract متدی است که بخش بدنه(body) را ندارد. در برنامه نویسی شی گرایی بدین صورت متدهای Abstract را تعریف میکنند:نمونه ای از تعریف کردن abstract متدهاهمانطور که گفته شد بخش بادی وجود ندارد و کلمه کلیدی Abstract قبل از نام متد بدین منظور است که این متد قسمت پیاده سازی ندارد. اگر قبل از کلاس ایجاد شود به این معناست که میتواند از 0 تا 100 درصد حاوی متد های Abstract است. به عبارتی دیگر یعنی همه ی متدهاش میتونه بصورت abstract پیاده سازی شده باشد یا هیچ متدی بصورت Abstract تعریف نشده است. مفهوم Abstract Class در شی گرایی چیست؟فرض کنید یک شکل هندسی دارید که کلاس است و میتواند یک سری متد داشته باشد. مانند شکل زیر.abstract Class with methodsسه تا از متدها بصورت abstract هستند و یک متد هم بصورت عمومی تعریف شده است که نام شکل هندسی را چاپ میکند. سوالی که مطرح میشود این است که چرا سه متد را بصورت abstract تعریف کرده ایم ؟ برای اینکه شکل هندسی یک مفهوم انتزاعی دارد و میتواند هرچیزی باشد:ذوزنقه، دایره، لوزی و... اما هرچه باشد محیط و مساحت و شکل و شمایل دارد. در اینجا سه زیرکلاس یا بچه برای کلاس شکل هندسی با استفاده از Extend ایجاد کردیم که تمام خصوصیات کلاس shape را دارند و تنها اتفاقی که می افتد هر فرزند باید متدهای abstract را درون خود پیاده سازی کند. به عبارتی دیگر پیاده سازی متدهای abstract را به فرزندان واگذار کرده است. سوالی که ایجاد میشود این است کهabstract class ها برای چی استفاده میشوند؟ در مواردی که مفاهیم انتزاعی داریم. بطور مثال روش پرداخت، یک مفهوم انتزاعی است و از چندین روش میشود پرداخت را انجام داد. در حقیقت شما می دانید چیست اما در واقعیت روش های زیادی دارد. در این حالت کافی است که یک abstract class برای روش پرداخت بنویسید که هر روش پرداخت یک سری کارهای مشخص انجام میدهد. اسم abstract class روش پرداخت، pay باشد. و زیرشاخه هایی که اکستند میشوند مثلا پرداخت نقدی،آنلاین و کارت به کارت و ... باشد و متدهای abstract را باید پیاده سازی کند. اما یک سری نکات برای تعریف abstract class ها باید درنظر گرفت که ضمن دانستن آنها باید آنها را بخاطر سپرد. abstract class نکات مربوط به کلاس abstract میتوان هیچ یا 100% متد abstract داشته باشد.کلاس های abstract نمیتوانند obj بگیرند و باید حتما Extend شوند. باید همه ی متدهای abstract کلاس abstract را پیاده سازی و overrideکرد.

الگوی طراحی simple factory(فکتوری)

Setare Behzadi — Mon, 30 Mar 2020 11:18:28 +0430

الگوی طراحی فکتوری نیز در دسته بندی Creational قرار دارد. در این مقاله به بررسی مسئله و حل و پیاده سازی آن با این الگوی طراحی میپردازیم. افراد متخصص در حوزه برنامه نویسی معتقد هستند که دستور new، دستوری خطرناک و پر هزینه است و باید برای حل این مشکل از این دیزاین پترن استفاده کرد. بطور مثال، یک کلاس یوزر داریم که میخواهیم در جاها و فایل های مختلف(حدود 50 تا فایل) از آن استفاده کنیم، هی مجبوریم new user کرده تا به تابع isLogin دسترسی داشته باشیم. حال این فقط واسه یک کلاس است و اگر تغییری در نام کلاس یا constractor آن داده شود، شما و پروژه اتون رو درگیر میکند. برای حل مسئله و جلوگیری از تکرار کلید واژه new کافی است از الگوی فکتوری استفاده شود. البته باید درنظر داشت که این الگو، سه حالت دارد:simple factory، factory methodو static factory.سیمپل فکتوری همانطور که از اسمش مشخص است میگوید یک کارخانه بسازید و تولید و ساخت Object ها را به آن بسپار و شی را از آن دریافت کن. بدین صورت استفاده از کلید واژه new به حداقل میرسد. پیاده سازی آن به صورت زیر است. فرض کنید سه تا کلاس داریم مربوط به ساخت ماشین های سنگین، اسپرت و شاسی بلند که کلاس ماشین را توسعه دادند. حال چگونه از این سه کلاس بدون استفاده زیادی از کلیدواژه new استفاده کنیم؟ class Car { } class Car_SUV extends Car{ } class Car_Sedan extends Car{ } class Car_truck extends Car{ } // ببینید برای فراخوانی هر کلاس چند تا نیو داریم. پس خوبه از فکتوری استفاده کنیم $truckObj= new Car_truck (); $suvObj= new Car_SUV (); $SedanObj= new Car_Sedan (); $carObj= new Car (); // using carFactory implemention class CarFactory{ public static function build($type) { switch($type){ case 'SUV': return new Car_SUV (); breake; case 'Sedan': return new Car_Sedan (); breake; case 'truck': return new Car_truck (); breake; default : return new Car(); breake; } } $truckObj= CarFactory::build('truck'); $suvObj= CarFactory::build('SUV'); $SedanObj= CarFactory::build('sedan'); $carObj= CarFactory::build('car'); }راه های پیاده سازی متفاوتی وجود دارد، برای همین مثال. در ادامه به یکی دیگر از آنها میپردازیم. vehicleMake = $make; $this->vehicleModel = $model; } public function getMakeAndModel(){ return $this->vehicleMake . ' ' . $this->vehicleModel; } }class CarFactory { public static function create($make, $model) { return new Car($make, $model); } } // have the factory create the car object // متد استاتیک رو با دو پارامتر صدا میزند. بعد برند با مدل به کانستراکتور ماشین ارسال میشود $veyron = CarFactory::create('Bugatti', 'Veyron'); // در اینجا مدل و برند داده شده ساخته میشود و برگردانده میشود برای چاپ print_r($veyron->getMakeAndModel()); // outputs "Bugatti Veyron" یکی دیگر از مزایای استفاده از این الگوی طراحی این است که اگر نام مدلی قرار باشد تغییر کند، فقط در فکتوری تغییر میکند و نیاز به جستجوی زیادی نیست. این مقاله فقط به simple factory پرداخته است و منبع آن اینترنت و البته دوره مجازی سون لرن است. دیزاین پترن آداپتور موضوع مقاله بعدی میباشد.

الگوی طراحی سینگلتون (singleton)

Setare Behzadi — Sat, 28 Mar 2020 15:06:50 +0430

همانطور که گفته شد الگوی طراحی سینگلتون از زیر دسته ی creational میباشد یعنی ما یک مسئله برای ساخت objectها داریم که میخواهیم با این الگو طراحی کنیم. معنای کلمه سینگلتون، یکی بودن است یعنی مشخص است objectای که با استفاده از این الگو طراحی میشود توی کل پروژه یبار ساخته شده است. سوالی که پیش می آید چرا باید فقط یک object از یک کلاس را داشته باشیم؟ بجاش میتونیم یه کلاس با متدهای استاتیک داشته باشیم. جوابی که وجود دارد این که گاهی واقعا نیاز نیست که صدتا objساخته شود و در کل پروژه یک شی از آن کلاس کافیه. مثلا میخواهیم اتفاقاتی که در کل پروژه میفتد را لاگ بگیریم. برای اینکار یک شی بلاگر کافی است و لزومی ندارد که چندبار new کنیم. البته باید توجه داشت هر بار ساخت شی با new بار هزینه ای زیادی برای برنامه دارد که با این الگو میتوانیم کاهش دهیم. البته که usecase های مختلفی دارد و فقط اون یه مثال ساده بود. بعنوان مثال apiهایی که بازای هربار استفاده مبلغ پولی را شارژ میکنند. یا استفاده از یک پلاگین وردپرسی در پروژه، کافیه یکبار new کند و از امکانات اون کلاس استفاده کند. حال در عمل چگونه سینگلتون پیاده سازی میشود؟ البته که دیزاین پترن ها فارغ از زبان هستند اما برای پیاده سازی به یک زبان نیاز است که من زبان php را انتخاب کردم.1- ابتدا یک private constructor برای جلوگیری از ساخت مستقیم شی از کلاس تعریف میشود.2- تنها راه ساخت فقط یک شی از کلاس استفاده از متد استاتیک است که قبلا درست نشده باشد. //general singleton class class singleton { //تعریف متغیر برای نگهداری نمونه کلاس سینگلتون private static $instance = null; // تعریف کانستراکتور بصورت پرایویت // to prevent initiation with outer code. private function __construct() { // The expensive process (e.g.,db connection) goes here. } // اگر کلاس هیچ شی ای نداشت بسازد در غیر اینصورت برگرداند. public static function getInstance() { if (self::$instance == null) { self::$instance = new Singleton(); } return self::$instance; } }حال برای فراخوانی آن میتوان بصورت زیر عمل کرد:// All the variables point to the same object. $object1 = Singleton::getInstance(); // ابتدا شی در اینجا ساخته میشود $object2 = Singleton::getInstance(); // در اینجا شی ساخته شد گرفته میشود. $object3 = Singleton::getInstance();حال اگر بخواهیم یه مثال کاربردی تر بزنیم میتوانیم اتصال به دیتابیس را مطرح کنیم. class ConnectDb { private static $instance = null; private $conn; private $host = 'localhost'; private $user = 'db user-name'; private $pass = 'db password'; private $name = 'db name'; // The db connection is established in the private constructor. private function __construct() { $this->conn = new PDO("mysql:host={$this->host}; dbname={$this->name}", $this->user,$this->pass, array(PDO::MYSQL_ATTR_INIT_COMMAND => "SET NAMES 'utf8'")); } public static function getInstance() { if(!self::$instance) { //اگر وجود نداشت و یا نمونه ای براش ساخته نشده بود self::$instance = new ConnectDb(); //کانستراکتور را براش اجرا میکند و ایجاد میشود. } return self::$instance; } public function getConnection() { return $this->conn; } }تا زمانیکه ما از این کلاس برای چک کردن کانکشن استفاده میکنیم، مهم نیست چندبار شی را خارج از کلاس میسازیم. چون در هربار اجرا فقط یک شی دارد. برای اثبات حرفمون کافیه کدهای زیر اجرا شود.$instance = ConnectDb::getInstance(); $conn = $instance->getConnection(); var_dump($conn); $instance = ConnectDb::getInstance(); $conn = $instance->getConnection(); var_dump($conn); $instance = ConnectDb::getInstance(); $conn = $instance->getConnection(); var_dump($conn);همانطور که خواهیم دید هر سه شی، مقدار یکسانی را برمیگرداند. در مقاله بعدی به بررسی دیزاین پترن فکتوری میپردازم. منبع: اینترنت و سون لرن

الگوهای طراحی در شی گرایی چیست و چه کاربردی دارد؟

Setare Behzadi — Sat, 28 Mar 2020 00:34:18 +0430

دیزاین پترن ها و یا الگوهای طراحی همیشه یکی از دغدغه های برنامه نویس هایی است که با مفاهیم شی گرایی آشنایی دارند اما کاربرد و چرایی استفاده از الگوهای طراحی هنوز برایشان شفاف و روشن نیست. سعی شده است در یک رشته مقاله به بررسی الگوهای طراحی بپردازم که بعنوان سرنخ بتوان مفهوم آنها را متوجه شد. در زمان های قدیم که تازه مباحث شی گرایی مطرح شده بود، برنامه نویسان متوجه شدند که در بحث توسعه نرم افزار بعضی از مشکلات در برنامه های مختلف یکسان است. بدین جهت برای رفع این مشکلات یک سری راهکارها ارائه شد که به آن الگوی طراحی میگویند. به عبارت دیگر، الگوهای طراحی یک روش حل مشکل هستند نه sourse code. بخواهیم توضیحات بالا را با مثال توضیح دهیم، فرض بر این است که من تازه به تهران آمده ام و در چهارراه ولیعصر روبروی تئاتر شهر ایستاده ام و جایی که باید ساکن شوم در ارم سبز قرار دارد. در اینجا مسئله این است: من چگونه میتوانیم با سریعترین و بهترین روش به مقصد بروم؟ امکانات من شامل مترو، اسنپ، آژانس، brt و حتی hitchhiking میباشد. اما چون راجع به ساختارکلی شهر تهران و آدرس هاش اطلاعی ندارم، فردی رو میابم که آگاهی نسبتا کافی و کاملی نسبت به شهر تهران داشته باشد و ایشان به من میگه بهترین راه رسیدن به مقصد ارم سبز، مترو میباشد.(راه حل مسئله)عملا در برنامه نویسی شی گرا، همین موضوع صدق میکند. دیزاین پترن ها توسط افرادی که اشراف کاملی در حوزه برنامه نویسی داشتند، تدوین شد و با ارائه ی این دیزاین پترنها به برنامه نویس ها این آسودگی خیال را میدهند که درگیر موضوعات حاشیه برای حل مسائل نشوند. موضوعات حاشیه چیست؟ در ادامه مقاله متوجه میشید.دیزاین پترن ها در شاخه های مختلفی تقسیم میشوند که سه دسته ی آن عمومیت بیشتری دارند. 1- دسته اول creational design pattern میباشد. این الگوهای طراحی برای ساختن(create) اشیا(object) استفاده میشود. خب چرا باید برای ساخت یه شی از دیزاین پترن باید استفاده شود؟ چون اون افرادی که اشراف داشتن به حوزه برنامه نویسی، استفاده از کلمه ی کلیدی new را خطرناک میدانستن و عقیده داشتن که باید از کلمه new کمتر استفاده شود. (چرا خطرناک؟ در این رشته مقاله نمیگنجد، سرچ کرده و در کامنت ها به آن اشاره کنید). بطور مثال برنامه بسیار بزرگ شده است و ممکنه در 100 ها و یا هزاران کلاس تعریف شده باشد و شما یه obj از آن باید میساختین با استفاده از new، مثلا یک عالمه new user داریم و مدتی بعد متوجه میشویم که باید پارامتر جدیدی به آن اضافه کنیم، پس باید در کل برنامه آنها را پیدا کرده و تغییر بدیم. پس اون آدمای متخصص متوجه شدن که ساخت اشیا با new کار درستی نیست و باید تلاش شود که وابستگی بخش های مختلف نرم افزاری به همدیگر کم باشد. برای رفع این مشکل دیزاین پترن factory را پیشنهاد دادند که یک کلاس میسازیم توی این کلاس factory یک شی را میسازیم و از این فکتوری استفاده میکنیم. یا مثلا میخواهیم فقط یه شی ساخته شود که اونجا از دیزاین پترن singltone استفاده میشود.بطور خلاصه :) creational design pattern ها مشکلات ساخت object ها را حل میکند. 2- دسته دوم الگوهای طراحی ساختاری (structrural design pattern)هستند. این الگوها کمک میکنند که دیزاین،معماری و یا ساختار نرم افزار به مشکل خاصی زمان scale برنخورد و مشکلات ساختاری و دیزاین برنامه را برای شما راحتتر میکند. عملا ممکن است الگویی به شما دهد که برای استفاده از این مدل کار(پروژه)بهترین ساختار چیه.مثلا الگوی طراحی ساختاری adapter میگوید زمانیکه میخواهید از یک کتابخانه ی خارجی یا ماژول خارجی در نرم افزارتون استفاده کنید، بیا و اون adapt کن که اگر بعدها api آن کتابخانه آپدیت شد بیچاره نشوید و فقط adapter رو تغییر دهید.در الگوهای طراحی بیشتر از inheritance یا مفهوم ارث بری استفاده میشود که ارتباط بین کلاسها را برای مورد خاصی مدیریت میکند. پس الگوی طراحی ساختاری میگوید ماست ها را در قیمه ها نریخته و همه چیز را قاطی نکنیم بلکه تا جایی که امکان دارد باید نقاط اتصال و وابستگی کمتری بین دوبخش برنامه باشد. adapter تنها نقطه ی اتصال با کل برنامه میباشد که از یکسر به برنامه و از طرف دیگر به اون کتابخانه خارجی وصل است. 3- دسته سوم الگوهای طراحی رفتاری است . این الگوها عملا برای حل مسئله تعامل و یا interaction بین objectها میباشد. مثلا مهمترین این الگوی طراحی، زنجیره مسئولیت(chain of responsibility) مییاشد. مثلا یک کار رو میخواهیم توی چند بخش انجام بدهیم که خروجی یکی ورودی دیگری است. در حقیقت یک لینک لیست رو میتونه پردازش کنه. یا الگوی مصرف Iterator که وقتی شما میخواهید روی اشیا پیمایش کنید، با استفاده از آن میتوانید راهکار خوب ارائه دهید. یا الگوی رفتاری strategy، خیلی کاربردی است که میگوید هروقت یک کاری یا feature ای میخاد و پیاده سازی شود راه های مختلفی میتونه پیاده سازی بشه باید از الگوی طراحی strategy برای حل مسئله استفاده کرد.نکات دیزاین پترن ها کاملا مستقل از زبان برنامه نویسی هستند و بسیار کاربردی هستند اما به شی گرایی وابسته هستند. کافیه یاد بگیرید بعد در همه ی زبان ها میتوانید استفاده کنید. الگوهای طراحی را کجا و کی باید استفاده کرد؟ قبل از هرچیز ابتدا باید روی همه الگوهای طراحی تسلط داشت. بعبارتی باید متوجه شد که هر الگوی طراحی چه مسئله ای رو چگونه حل میکند.پس برای استفاده از الگوهای طراحی ابتدا باید بفهمیم مسئله چیست؟ الگوی مناسب چیست؟ و نحوه پیاده سازی به چه صورت است.سوال بعدی کی ؟ زمانی باید استفاده کرد که نرم افزارتون چقدر باید بزرگ شود؟ چقدر میخاد توسعه پیدا کند و scale بشه . اگر قراره بزرگ بشه استفاده از دیزاین پترن ها، scale پذیری برنامه رو بسیار بالا میبرد. در مقاله بعدی بعضی از دیزاین پترن ها رو بصورت جزئی تر مورد بررسی قرار میدهم.منبع: کلا سون لرن .

کاربرد کلمه کلیدی final در زبان‌های برنامه نویسی شی گرا

Setare Behzadi — Tue, 24 Mar 2020 12:39:53 +0430

این کلمه کلیدی معمولا برای منع کردن استفاده میشود. اما این منع کردن به چه صورت انجام میشود.در زبان php این کلمه کلیدی قبل از متد و یا کلاس میاد و نمیتواند برای property استفاده شود. اما در زبان جاوا این امکان وجود دارد. مثال زیر را درنظر بگیرید: فاینال بدین معنی است که این کلاس اجازه داشتن بچه رو ندارد و کلاس دیگری نمیشود از آن extend شود و بچه ی آن باشد. این کلمه کلیدی final برای متد به این معناست که اجازه ی overriding و یا توسعه را ندارد.برای property هم بدین معناست که اجازه نمیدهد که محتواش را تغییر دهید و مانع از تغییر محتوای آن متغیر میشود. مثال زیر نحوه کاربرد final برای متد را نشان میدهد . // Program to understand use of // final keyword for methods class Base { //parent class that can have children final function printdata() { // Final method echo " Base class final printdata function" } // Non final method function nonfinal() { echo "\n This is nonfinal function of base class" } } // Class that extend base class class Derived extends Base { // Inheriting method nonfinal function nonfinal() { echo "\n Derived class non final function" } // Here printdata function can // not be overridden } $obj = new Derived; $obj->printdata(); $obj->nonfinal(); ?> خروجی ای که نمایش میدهد : Base class final printdata function Derived class non final functionمنبع: سون لرن و سایت گیگ فورگیگز

کاربرد کلمه کلیدی Static در شی گرایی

Setare Behzadi — Sat, 29 Feb 2020 12:31:39 +0330

در این مقاله قصد دارم تاثیر static بر اعضای یک کلاس را مورد توجه قرار بدم . با مثال زیر که به زبان php هست شروع میکنیم. خروجی بالا بصورت ذیل میباشد:The next value is: 1 The next value is: 2 The next value is: 3 The next value is: 4 The next value is: 5چه موقع از static استفاده میکنیم؟ از کلمه کلیدی زمانی استفاده میکنیم که یک ویژگی و یا متد برای همه ی object های یک کلاس یکسان است. بنابراین هر منطقی که بتواند در چندین نمونه(obj) استفاده شود باید بصورت استاتیک در بیاید.بیشتر فریمورک های php مثل لاراول و CakePHP از متدهای static php استفاده میکنند.منبع: دوره شی گرایی 7learn و سایت geeksforgeeks