יצירת פונקציות "עוקבות" - כאובייקט של פונקציות או ככמה פונקציות קטנות?

[ארכיטקט]

לא נהוג לעשות מחלקה על ערך בודד, ערך בודד ופרימיטיבי הוא בדרך כלל פורפרטי במחלקה. ומחלקה אמורה להחזיק יותר מפרופרטי אחד.
כמו"כ נהוג ליצור מחלקה אחת "המייצגת ערכים" כגון User ועוד מחלקה "מטפלת בערכים" כגון UsersRepository. ושם יש בעיקר פונקציות גישה.
זה נקרא בעגה המקצועית repository pattern. וזה מאוד מאוד מאוד מאוד מאוד מאוד נוח וטוב לתחזוקה.
מסגנון שאלותיך נראה שאתה בשל לשלב הבא בעולם התוכנה, שהוא הארוך והקשה מכולם (ושלא מסתיים לעולם ובו נבדלים המתכנתים זה מזה), הלא הוא שלב התיכנון והארכיטקטורה, ממליץ לך בחום לקרוא את הספר Code Complete (יש מהדורה בעברית).

[צדיק תמים]

@ארכיטקט מה זה אומר ערך בודד ופרימיטיבי?
זה פונקציות שעושות משהו, לא מחזירות ערך (לפחות בחלקן).

[ארכיטקט]

@צדיק-תמים
מה שעשית נקרא רפוזיטורי, וכפי שזה נראה תפקידו של הרפוזיטורי להחזיר ערכים בודדים, וזה לגיטימי לחלוטין, אבל מבין הדברים אני מבין שאתה מחפש ID של משהו, שהוא ככל הנראה אובייקט. מומלץ לגמרי להצהיר על אובייקט שחוזר מהרפוזיטורי, ואז יש לך יתרון תחזוקתי ארוך טווח כי אובייקט ניתן להרחבה ולשינויים "בשקט" ללא שבירות קוד כל כך.
ערך פרימיטיבי הוא למשל int או string וכדומה, אלו הערכים הראשוניים שבדרך כלל נמצאים "בתחתית העץ" כשמדובר באובייקטים.
הרפוזיטורי שלך צריך להיקרא בשם יותר נורמלי המתאר מחלקה למשל User. והפונקציות נקראות "פונקציות גישה" שמאפשרות תחזוקה שקטה יחסית לפי עיקרון הכימוס.
בקיצור יש מה ללמוד.

[צדיק תמים]

@ארכיטקט אמר ביצירת פונקציות "עוקבות" - כאובייקט של פונקציות או ככמה פונקציות קטנות?:

מה שעשית נקרא רפוזיטורי

מה זה אומר רפוזיטורי?! זה לא מאגר?
זה בעצם מטפל בשמירת ושליפת מידע מlocalStorage.
יש אחת לקבלת המידע, אחת לשמירתו, ואחת לבדיקה האם כבר שמור או לא (מחזיר בוליאני).
זה מחזיר אובייקט, אבל כjson (ואז אני ממיר אותו לאובייקט ג'אוהסקריפטי רגיל), כי localStorage מוגבל למפתח:ערך בלבד. ככה שלמעשה get מחזיר סטרינג, set מגדיר לוקאל חדש, וCheck בודק האם לוקאל מסוים קיים ומחזיר בוליאני.
הארגומנט id הוא בעצם המפתח של הלוקאל הנידון.
איזה שם נורמלי מתאים לדוגמה בכזה מקרה?

@ארכיטקט אמר ביצירת פונקציות "עוקבות" - כאובייקט של פונקציות או ככמה פונקציות קטנות?:

בקיצור יש מה ללמוד.

לכן שאלתי פה...

[גמליאל]

@יוסף-בן-שמעון אמר ביצירת פונקציות "עוקבות" - כאובייקט של פונקציות או ככמה פונקציות קטנות?:

זה השיטה הרווחת היום

משאלתו של @צדיק-תמים (כאן ובשאלות נוספות) ניכר כי הוא מתכנת בJS ולא בשפות אחרות
אתה בטוח שזו השיטה הרווחת גם בJS?

[ארכיטקט]

@גמליאל אמר ביצירת פונקציות "עוקבות" - כאובייקט של פונקציות או ככמה פונקציות קטנות?:

אתה בטוח שזו השיטה הרווחת גם בJS?

חד משמעית
זה לא קשור לשפה זה קשור למוח האנושי ותפיסתו, ניהול סטייט מפומפם כבר הרבה שנים בעולם האינטרנט, טייפסקריפט, אנגולר, כל אלו דוחפים חזק מאוד לתיכנות אובייקטאלי ובשיטות הנ"ל.

@צדיק-תמים אמר ביצירת פונקציות "עוקבות" - כאובייקט של פונקציות או ככמה פונקציות קטנות?:

מה זה אומר רפוזיטורי?! זה לא מאגר?
זה בעצם מטפל בשמירת ושליפת מידע מlocalStorage.

רפוזיטורי הוא מאגר וזה תרגום מילולי (ללא קשר לטכנולוגיית git), וזה בדיוק הרעיון שלו הפשטה גמורה של מה שזה עושה, אתה לא יודע איפה המאגר שומר, מאיפה הוא שולף, מה הוא עושה כדי להגיע לתוכן, אתה פשוט מבקש ממנו יפה "תביא לי את האובייקט הזה והזה".
מי אמר לך שתמיד תשמור בלוקל סטורג' אולי תחליט לשמור בצורות אחרות? אינדקסד דיבי או פשוט לשמור משתנה בזיכרון וכן הלאה. אולי לשמור בשרת ולשלוף אותו מידי פעם. מה אתה יודע מה יהיה?
לכן הרעיון הוא לבצע הפשטה מוחלטת של מה שאתה עושה, והחוזה שלך עם הפונקציה הוא על אספקת מידע. מאיפה? לא מעניין, איך? גם לא מעניין. כמה זמן זה לוקח? לא עניינך, כמה משאבים? מי ביקש ממך לדחוף את האף. בקיצור כל מה שאומרים ללקוח, הפונקציה אומרת למי שמשתמש בה.

[איש נחמד]

@ארכיטקט אמר ביצירת פונקציות "עוקבות" - כאובייקט של פונקציות או ככמה פונקציות קטנות?:

@גמליאל אמר ביצירת פונקציות "עוקבות" - כאובייקט של פונקציות או ככמה פונקציות קטנות?:

אתה בטוח שזו השיטה הרווחת גם בJS?

חד משמעית
זה לא קשור לשפה זה קשור למוח האנושי ותפיסתו, ניהול סטייט מפומפם כבר הרבה שנים בעולם האינטרנט, טייפסקריפט, אנגולר, כל אלו דוחפים חזק מאוד לתיכנות אובייקטאלי ובשיטות הנ"ל.

@צדיק-תמים אמר ביצירת פונקציות "עוקבות" - כאובייקט של פונקציות או ככמה פונקציות קטנות?:

מה זה אומר רפוזיטורי?! זה לא מאגר?
זה בעצם מטפל בשמירת ושליפת מידע מlocalStorage.

רפוזיטורי הוא מאגר וזה תרגום מילולי (ללא קשר לטכנולוגיית git), וזה בדיוק הרעיון שלו הפשטה גמורה של מה שזה עושה, אתה לא יודע איפה המאגר שומר, מאיפה הוא שולף, מה הוא עושה כדי להגיע לתוכן, אתה פשוט מבקש ממנו יפה "תביא לי את האובייקט הזה והזה".
מי אמר לך שתמיד תשמור בלוקל סטורג' אולי תחליט לשמור בצורות אחרות? אינדקסד דיבי או פשוט לשמור משתנה בזיכרון וכן הלאה. אולי לשמור בשרת ולשלוף אותו מידי פעם. מה אתה יודע מה יהיה?
לכן הרעיון הוא לבצע הפשטה מוחלטת של מה שאתה עושה, והחוזה שלך עם הפונקציה הוא על אספקת מידע. מאיפה? לא מעניין, איך? גם לא מעניין. כמה זמן זה לוקח? לא עניינך, כמה משאבים? מי ביקש ממך לדחוף את האף. בקיצור כל מה שאומרים ללקוח, הפונקציה אומרת למי שמשתמש בה.

האם לא כדאי ליצור פונקציות נפרדות עבור כל סוג זיכרון?
עד כמה שהטיפול בשליפת נתונים ושמירתם למקומות אחסון שונים נעשה בדרכים שונות, יהיה צורך להתייחס אליהם בנפרד, לא? או שזה לא סותר?

[צדיק תמים]

@ארכיטקט אמר ביצירת פונקציות "עוקבות" - כאובייקט של פונקציות או ככמה פונקציות קטנות?:

פשוט לשמור משתנה בזיכרון

כלומר? המשתנים לא מתאפסים בכל רענון של הדף?

[ארכיטקט]

@צדיק-תמים אמר ביצירת פונקציות "עוקבות" - כאובייקט של פונקציות או ככמה פונקציות קטנות?:

כלומר? המשתנים לא מתאפסים בכל רענון של הדף?

מתאפסים, וזה דווקא טוב לפעמים, תלוי בהרבה שיקולים שעלולים לצוץ בהמשך.

[ארכיטקט]

@איש-נחמד אמר ביצירת פונקציות "עוקבות" - כאובייקט של פונקציות או ככמה פונקציות קטנות?:

האם לא כדאי ליצור פונקציות נפרדות עבור כל סוג זיכרון?
עד כמה שהטיפול בשליפת נתונים ושמירתם למקומות אחסון שונים נעשה בדרכים שונות, יהיה צורך להתייחס אליהם בנפרד, לא?

אם כבר אז פונקציות פנימיות פרטיות, זה לא אמור להיות עניינו של צרכן הפונקציה הראשית איפה מאחסנים ומאיפה שולפים.
כשאתה נכנס לחנות מכולת אתה (בדרך כלל) לא שואל אותו מי היה הסוכן שסיפק לו את הסחורה ומה הדגם של המשאית, גם נהג המשאית לא בהכרח שואל אותו למי הוא מוכר את הסחורה ואיך הוא מסדר את זה במדפים
כזו היא פונקציה ביחס לצרכנים שלה, כומסת אחריות ומספקת בסופו של דבר את המהות שאליה היא התחייבה בלבד.