פרויקט ב-#C - מחשבון פשוט - חלק 5
default.Operations עם ערכים add, subtract, multiply ו-divide. המשתנה מקבל רק ערכים מהרשימה, והקומפיילר מזהה טעות כתיב כבר בזמן הכתיבה.פרקי ההרצאה: פרויקט ב-#C - מחשבון פשוט - חלק 5
תמלול ההרצאה: פרויקט ב-#C - מחשבון פשוט - חלק 5
הטקסט המלא של הדקות הראשונות בהרצאה «פרויקט ב-#C - מחשבון פשוט - חלק 5» בקורס הווידאו של PracticU – כתוביות בעברית עם זמן התחלה לכל פסקה. כך תוכלו לקרוא ולחפש את הנושאים לפני שמתחילים ללמוד.
הרצאה של היום תהיה על if-else ועל switch-case ועל enum. אז קודם כל בואו נציג את הבעיה. אם אני הולך ל-valuables וסליחה ל-operation ובואו נגיד שבפונקציה equals שלי כאן שיפט F5 רגע בלי כוונה ישתרבב לו רווח.
בואו נביא את זה עכשיו נראה מה קורה. 123 ועוד 321 שווה, לא עושה כלום. למה הוא לא עושה כלום? כי האופרציה עצמה היא פלוס והיא לא פלוס רווח.
בואו נשים פה breakpoint ונראה את התקלה. אני אומר לו שווה, והוא אומר לי אוקיי, Operation שווה לפלוס, אבל בלי רווח, מכיוון שזה לא מתאים, אז הוא מדלג על זה.
בואו נדבק ונראה, F10, הוא מדלג על זה. הוא גם מדלג, כמובן שפלוס לא שווה למינוס, הוא מדלג גם על זה, גם על הכפול, גם על החלקים, הוא מדלג על כולם ולא עושה אף אחד מהם.
יפה. אז אולי מה שהיינו רוצים לעשות זה איזשהו לטפל בעצם במקרה שזה לא אף אחד מהם. איך עושים את זה? אז בוא נגיד שדרך אחת לעשות את זה זה לשים בסוף כל אחד ריטרן.
סיימנו, אז נעשה ריטרן. ואז אם הגענו לפה, אז נציג הודעה שיש לנו תקלה. no touch operation ונריץ נסיר את הברייק פוינט נחזור לכלכלתור ו-123 ועוד 321 שווה יפה arrow no touch operation אז זה סוג של טיפול אבל יש עם זה בעיה זה לא כל כך בריא לעשות את זה ככה בואו נראה
משהו הרבה יותר הרמטי במקום להגיד לו if וזה ו-return אני אגיד לו כאן אלס ככה אם בעצם נשאיר פה את הרווח אם האופריישן זה זה אז תעשה את זה ואז אני גם יכול להוציא את הריטרן אם זה לא זה אלס אז תבדוק האם זה זה תוציא את הריטרן ושוב גם כאן נוסיף אלס אם זה לא זה אז רגע אולי זה בואו נבדוק אולי זה זה נציג גם מפה את הריטרן ונשים פה אלס אולי זה זה יפה עכשיו
אם אני אוציא מפה את הריטיון, אז אם זה לא זה ולא זה ולא זה, האמת שבכל מקרה כרגע אני מגיע להודעה הזו. אז בואו נגיד אלס אם זה לא זה ולא זה ולא זה ולא זה, אז תציג את זה.
בואו נריץ עכשיו, 123 ועוד 321 שווה, אירו נוס אופריישן, יפה. אז זו דרך יותר טובה וגם יותר בריאה לכתוב את הקוד. בואו עכשיו נסיר את הרווח מפה ונריץ שוב 123 ועוד 321 שווה 444 מצוין.
עדיין אפשר להגיד שיש לנו בעיה עם הקוד הזה. מה הבעיה? הבעיה היא שהקוד הזה לא כל כך קריא. הבעיה שאני רואה if lc זה לא בדיוק קריא שבעצם אני בודק מה הערך של אופריישן ולפי זה אני עושה או פלוס או מינוס או כפול או חלקי. מי שרואה את זה בפעם הראשונה בכלל לא רואה את הסדר, הוא לא רואה את המכנה המשותף
בין כולם שבעצם אנחנו בודקים פה את הערך של Operation בין כולם. אז אולי נשתמש במנגנון הרבה יותר קריא שזה מנגנון ה-Sw Case. אז במקום להגיד לו if Operation שווה לזה אני אגיד לו which all operation ואני אפתח פה בלוק ואני אכתוב פה case וכאן נקודותיים אז אם הוא זה נעשה את זה ופה אני חייב לשים break ונסגור פה את הבלוק והוא מעצב הוא לא מעצב אידיאלי
בואו אולי נסיר את הסוגר הזה ואת הסוגר הזה יפה ונשים אוקיי, יפה, כן, הוא לא רוצה לעצב, באופן טבעי כשאני בדרך כלל סוגר דברים אז הוא מעצב אוטומטית, כרגע הוא לא מעצב אוטומטית כי ה-L סעיף הזה תקוע פה בלי שום היגיון.
אז כאן נכתוב גם case.2, שוב נסיר את זה, נסיר את זה, ו-brake, וגם כאן case.2, נסיר את הסוגריים, נוסיף break, וגם כאן, קייס, נקודותיים, נסיר את זה, נסיר את זה, וברייק.
והאלס האחרון, השוואר שלו בסוויץ' קייס, זה דיפולט. אני אסגור את זה, וכנראה שהכל כן מעוצב משום מה. בואו נריץ ונראה איך הוא מתנהג.
הרצה, no, פספסנו משהו, F8, Operation, מה הבעיה? סוגר, expected, כן, פספסנו פה סוגר. פתחנו פה את הסוויץ' קייס הזה, אה פה, כן, סגרנו את ה... כן, ועכשיו הוא גם מוצב הרבה יותר יפה, וזה הרבה יותר קריא.
מיד זה ברור לכל קורא שאנחנו עושים סוויץ' על אופריישן, ובמקרה כזה מתנהגים ככה, במקרה כזה מתנהגים ככה, ובמקרה הדיפולטי מתנהגים ככה, הרבה יותר קריא.
אם עכשיו, טוב בואו קודם כל נראה את זה עובד, עדיין יש לו איזושהי בעיה, מה הבעיה? סוויץ' cannot fall through from one case level Able to another, כן חסר לנו גם בדפולט ברייק, ננסה עכשיו, עדיין יש לו בעיה, מה הבעיה, F8, בואו נלך, בואו נראה את
השגיאה הראשונה, יפה, עכשיו יש לנו משתנה שחוזר על עצמו בהגדרה, אז האמת היא שאני כן יכול לשים סוגריים אם אני לא טועה, ככה, כדי שהמשתנים לא יתנגשו אחד לשני, ו-123 ועוד 321 שווה 444, אם עכשיו בלי כוונה נשים פה רווח ושוב נריץ 123 ועוד 321 שווה אין לנו no such operation בואו נשים breakpoint ונראה איזה מתרחש
123, 123 ועוד 321 שווה הגענו ל-operation הערך שלו זה פלוס בלי רווח כשאני עושה פה F11 אני מגיע ישר לסוף מיד המערכת מזהה שזה לא מתאים הערך פלוס גרשיים פלוס גרשיים בלי רווח אחרי הפלוס לא מתאים לאף אחד מהקייסים.
יפה, אז נתקן את זה, יפה מאוד. עכשיו עדיין יש לנו בעיה, זאת אומרת אפשר להגיד שכשאנחנו מריצים את המערכת עם השגיאה של הרווח אז אנחנו עולים על השגיאה הזו בזמן ריצה.
מה החיסרון של לעלות על שגיאה בזמן ריצה? היתרון הוא שנחייב להריץ את המערכת כדי לעלות על השגיאה. הרבה יותר כיף לו הקומפיילר עולה על השגיאה.
הרבה אנשים חושבים שהקומפיילר והודעות שגיאה זה משהו שעובד לרעתנו, אבל למעשה אין שום בעיה לכתוב שפת תוכנה שמקבלת הכל, ובזמן ריצה המשתמש או התחנת יעלה על כל השגיאות.
הקומפיילר והיכולת שלו לעלות על שגיאות היא העזרה הטובה ביותר שהתחנת מקבל מהמערכת על מנת שבעצם הדבר הזה על מנת שהקומפיילר יעזור לנו ולא נצטרך להריץ את המערכת ואולי לפספס בהרצאה את הבדיקה נכון יכולנו רק לבדוק את זה עם מינוס כפול חלקי ולפספס לך את הבדיקה על הפלוס ולא לעלות עליה אפילו בזמן ריצה ואולי רק הלקוח
שלנו היה עולה על השגיאה הזו על מנת לתפוס את כל השגיאות בהקדם בזמן קומפילציה אנחנו נלך לקומפיילר ונגיד לו שאנחנו רוצים להגדיר טיפוס של פלוס וטיפוס של מינוס ואת הטיפוס אופריישן כטיפוס של פלוס ומינוס וכפול וחלקי.
בואו נעשה את זה, אנחנו נלך, סליחה, לווריאבל, בואו נצמצם רגע שלא נלך לאיבוד, נלך לווריאבל שלנו ופה יש לנו סטרים אופריישן לא עוד.
נגדיר משהו שנקרא enum operations וב-enum ב-Operations נגדיר פעולת Add, Subtract, Multiply ו-Divide. אז הגדרנו עכשיו טיפוס חדש ואנחנו רואים שהוא טיפוס חדש, כי Operations הוא ירקרק.
ירקרק זה אומר שהוא טיפוס חדש, כמו ש-Form 1 הוא ירקרק וכמו ש-Form הוא ירקרק, גם-Form וגם-Form 1, שעוד נחזור אליהם בהרחבה מאוד גדולה, הם טיפוסים.
אז Operations הוא טיפוס חדש. דרך אגב, מילים שמורות זה בכחול, כל השאר זה בשחור. במקום להגדיר את Operation שיהיה מסוג String, אנחנו נגדיר את Operation שיהיה מסוג Operations.
שימו לב שכשאני מתחיל לכתוב Opera, Visual Studio, IntelliSense וה-AutoComplete מזהים את האפשרות. כן, אני רוצה לבחור ב-Operations בתור הטיפוס שממנו אני אגדיר את Operation.
אם אני עכשיו אנסה להריץ את המערכת שלי, אני אקבל הודעות שגיאת קומפילציה. מה השגיאה? הידיעה היא שפלוס כסטרינג לא יכול להיות מוכל בתוך משתנה מסוג אופריישן שאם נרחף מעליו נראה שהוא מסוג אופריישנז מצוין.
הסטרינג הוא מאוד גמיש אני יכול לשים מה שאני רוצה בתוך סטרינג אבל זה יותר מדי גמיש אני לא רוצה פה משהו גמיש אני רוצה הפוך אני רוצה משהו הרמטי משהו בטוח אז אני בעצם רוצה להפסיק לעבוד עם סטרינגים בגלל זה עברנו בעצם לעבוד עם האינם וככה אני אגיד לו כאן למעשה אני אמחק את מה שכתוב פה ואני אגיד, אוקיי, Operation שווה ל...
שימו לב עכשיו מה יקרה כשאני נלחץ על הרווח. המערכת עכשיו היא כל כך הרמטית שלמעשה כל מה ש-Operation יכול להיות שווה ל... זה רק Operation משהו. בואו נבחן את Operation ונגיד לו נקודה.
Operation יכול עכשיו לקבל רק את אחד מהערכים האלה. הטעות שיכולנו לעשות כאשר Operation היה סטרינג, היא בלתי אפשרית כרגע בכלל לבצע, ניתן לומר אפילו בזמן כתיבת הקוד.
אז אנחנו נבחר במקרה של פלוס כמובן ב-add. יפה, השגיאה הבאה מדברת על המינוס. בדיוק באותה מידה נמחק את כל זה ונגיד לו שווה ל-enter ונבחר הפעם, אנחנו בפונקציה sub, אז נבחר את sub, נקודה פסיק.
השגיאה הבאה אותו דבר, נמחק.