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

תודה רבה מראש.

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

התחזוק המהיר שלו אחרי, וההיגיון שבקוד

בתוכנה הקטנה זה לא כל כך משנה, יכול להיות ש OOP יפריע, אבל כאשר יש לך תוכנה עם עשרות אוביקטים, ולכל אוביקט כמה אוביקטים יורשים, OOP פשוט יותר נוח זה הכל


eXtruct אני לא יודע אם ל PHP יש OOP מובנה, אבל אתה יכול לעשות משהו דמוי OOP, להריץ קובץ php חיצוני עם include שמכיל את הפונקציות וההגדרות של אותו אוביקט שאתה רוצה לכתוב לו מחלקה, זה יהיה קצת פחות נוח, אבל אולי כדאי לך לשקול את זה

אני לא קשור, באתי לשבוע ואני יעזוב אחריו

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

עריכה:
טעות בשירשור..

http://www.fresh.co.il/vBulletin/sh...ht=%E2%E0%EE%E0

ראה את התגובה של Silver Strike

סבבה אבל איך זה מתקשר לשאלה שלי? שאלתי האם כדי להיתשמש ב OOP בתיכנות ברשת ואיך אתרים גדולים/מערכות ממומשים?

כל המערכות הגדולות משתמשות ב-OOP...קח לדוגמא את vBulletin ו-IPB - שניהן משתמשות בזה.

וכן, זה כדאי.

בתגובה של Silver Strike אתה יכול לראות שהוא כתב:

ציטוט:

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

אחלה, כנראה לא שמתי לב אוה בנתי לא נכון את התגובה שלו אתמול. תודה רבה על התשובה!

יש בPHP תיכנות מונחה-אובייקטים (OOP) מובנה, והוא דומה לC++ במבנה שלו:

קוד:

<?php

class ClassName {

var $variable;
public $variable2;
protected $variable3 = 'some';

function Func1( $var1 ) {
 // Do something...
}

function Func2( $var2 ) {
 // Do something...
}

}


//Call a function:
ClassName::Func1('some');

//Or:
$Class = new ClassName;
$Class->Func1('something');

?>

לא הייתי קורא למה ש vB עושה "תכנות OOP". יש כולה שני class בכל הקוד - אחד לחיבור למסד הנתונים והשני לשליחת דוא"ל... (לפחות בגירסא שיש לנו היום זה כך). זה ממש לא קוד OOP.

בוא נשווה את זה למספר הפונקציות: קצת מעל 1000 במספר...

הממ...

אולי בגלל זה הוא מהיר ועובד אחלה

נמאס לכם לזכור סיסמאות? לחצו כאן!

תראה, למען האמת, אין לי מושג איך VB בנוי (אני משתמש בעיקר בIPB), אבל ראיתי באחת ההודעות שציינו שVB בנוייה בOOP ולא פסלתי.

ללא קשר, במערכת vBulletin הדגש על יעילות יחסית נמוך, ולא בהכרח יותר מהיר מIPB.

בכל אופן, כל עוד יש "class" בקוד, יש שימוש, קטן ככל שיהיה, בOOP.

vB כבדה, אבל זה לא בגלל שהקוד שלה הוא לא OOP, אלא בגלל שהיא מפוצצת בפיצ'רים...

הטענה שלך מוזרה מאוד. אם כתבתי 10 מליון שורות קוד, כולן בתכנות פרוצדוריאלי, וכתבתי בנוסף class של עשר שורות, אז המוצר שלי הפך למוצר שבנוי על טהרת ה OOP? איך אומרים... I don't think so.

ככלל, OOP דורש, למיטב ידיעתי, כוח מחשוב גדול יותר מתכנות פרוצדוריאלי עבור אותן פעולות, לפחות בצורה הנפוצה של שתי השיטות בעולם...

נמאס לכם לזכור סיסמאות? לחצו כאן!

קוד שנכתב בתכנות מונחה עצמים אינו מהיר יותר ב99% מהמקרים, אבל היכולת לנהל את הקוד בצורה נוחה יכולה לעזור לך ליעל את התוכנית ביעילות

הגלריה שלי בפליקר

לפחות כשמדובר בקוד מקומפל זה לא נכון. הקוד הזה:

קוד:

void f() {
	printf("Hello\r\n"");
}

int main() {
	f();
	return 0;
}

והקוד הזה:

קוד:

class c {
public:
	void f() {
		printf("Hello!\r\n");
	}
}

int main() {
	c o;
	o.f();
	return 0;
}

יעשו בדיוק את אותו הדבר.

ועל אילו שתי שיטות אתה מדבר?

יש קוד שאינו מקומפל בסופו של דבר כדי לרוץ? enlighten me, please... (אא"כ אתה מאלה שטוענים שיש הבדל מהותי בין bytecode לאסמבלי...)

אני אמרתי שהן לא יעשו אתת אותו הדבר?

אני אמרתי שהן ידרשו יותר משאבים מהמחשב...

רציתי לבדוק קצת, אך לצערי הקוד השני שלך לא מתקמפל אצלי... זה מה שהוא אומר:

קוד:

f2.cpp:10: error: new types may not be defined in a return type
f2.cpp:10: note: (perhaps a semicolon is missing after the definition of 'c')
f2.cpp:10: error: two or more data types in declaration of 'main'
f2.cpp:10: error: '::main' must return 'int'

על השורה של int main...

(ושוב מוכחת הטענה שלי לגבי קוד OO )

נ.ב. "שתי השיטות" הן אלו שבכותרת של האשכול הזה...

נמאס לכם לזכור סיסמאות? לחצו כאן!

תנסה להוסיף פסיק נקודה אחרי הסוגר של הclass, זכור לי איפהשהו שצריך כזה

הגלריה שלי בפליקר

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

נו טוב, אז יש לנו שני קבצים מקומפלים. עשיתי אפילו strip על שניהם, כדי להעיף את ה debugging symbols, והנה התוצאה:

קוד:

$ ls -l f1 f2
-rwxr-xr-x 1 shimi shimi 4720 May 26 10:29 f1
-rwxr-xr-x 1 shimi shimi 4736 May 26 10:29 f2

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

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

לא סתם בקרנל של לינוקס אין שורה אחת ב OO...

נמאס לכם לזכור סיסמאות? לחצו כאן!

יש לך בעיה בקומפיילר/ספריות.

ולמה תמיד התחביר של C מוזר? למה צריך נקודה פסיק אחרי שסוגרים בלוק? בלוק זה סוגר בפני עצמו.

קוד:

struct timespec
  {
	__time_t tv_sec;		   /* Seconds.  */
	long int tv_nsec;		   /* Nanoseconds.  */
  };

היישר מה-CVS של glibc.

אני לא השתמשתי באופטימיזציית קומפיילר. אופטימיזציית קומפיילר זה אומר שהקומפיילר משנה את קוד המקור שלי למשהו שאני לא כתבתי (אולי, למשל, ה OO נפרש לצורה הפשוטה יותר...?)

לגבי ה struct, אתה צודק באופן כללי אם יוצאים מנקודת הנחה שמדובר בבלוק של קוד - רק שלא מדובר בבלוק של קוד, אלא בהגדרה של סוג משתנה מסויים, שמסתיימת שם... במחשבה שנייה, גם ההגדרה של class היא כזו, אז נראה שבנקודה המסויימת הזו אתה צודק...

נמאס לכם לזכור סיסמאות? לחצו כאן!

ואם היית מציג הבדל רציני בקוד רציני הייתי אומר לך "אבל השתמשת בקומפיילר דפוק".

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

אבל אנחנו סוטים מהעניין...

זה לא הפרש רציני בגודל משום שאנחנו לא מדברים על הפרש רציני בקוד. סביר להניח שרוב הבתים בקוד הזה בכלל לא נובעים מהקוד עצמו אלא יותר מה linking וכו'.

נמאס לכם לזכור סיסמאות? לחצו כאן!

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

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

ברור שהפונקציה תיקח אותו מקום, לא טענתי אחרת, טענתי לגבי התוספת של ה OO...

אשמח לדעת, אם קוד OO עובד טוב באותה מידה, יותר קל לתחזוקה, וכו' וכו' וכו', למה לא כותבים את כל הקרנל של לינוקס דווקא ב ++C? מה, הם מפגרים?

נמאס לכם לזכור סיסמאות? לחצו כאן!

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

גם הקרנל של ווינדוס לא כתוב ב-CPP, וגם דרייברים לווינדוס לא כותבים ב-CPP. אתה יכול לקרוא על חלק מהבעיות במאמר הבא: www.osronline.com/article.cfm?article=490
נדמה לי שענייני paging, לדוגמה, רלוונטיים גם ללינוקס.
בדף הבא באתר מייקרוסופט: http://www.microsoft.com/whdc/driver/kernel/KMcode.mspx
תוכל לראות עוד כמה דוגמאות לבעיות.
חשוב להזכיר שנדרשת גם תמיכה בקומפיילר, ומאחר ולינוקס נכתבה במקור ב-C והיה לה code-base גדול ובדוק ב-C לא ראו סיבה להשקיע ולטרוח בכתיבת תמיכה בקומפיילר רק כדי שיצטרכו לשכתב קוד שכבר בדוק ופועל. נשמע לי הגיוני למדי.

מצד שני, גם בעולם הלינוקס והקוד הפתוח יש המון קוד שכתוב ב-CPP. מה? הם מטומטמים?!

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

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

נמאס לכם לזכור סיסמאות? לחצו כאן!

הבעיה היא לא של ביצועים, אלא שיש דברים שבלתי-אפשריים פרקטית.
לדוגמה: ב-CPP קוד רץ באופן משתמע (destructor-ים, adjustor thunk-ים, וכו'). ב-kernel-mode אתה לא תמיד יכול להריץ כל קוד. יכול להיות שהקוד שאתה רוצה להריץ paged-out, ואתה לא יכול לטפל בפסיקה של page-fault כדי להחזיר אותו (מה שאומר ש-page fault יגרור kernel panic). מה תעשה?
יש לך רעיון לקומפיילר קסום שידע לנתח את הקוד, לזהות מקרים כאלה, ובמקרים כאלה לשים את הקוד שנקרא באופן משתמע כך שהוא תמיד יהיה באותו page עם מי שקורא לו?
העולם ישמח לשמוע.

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

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

אגב, אתה מזכיר לי מישהו ששמו אלכס.

נמאס לכם לזכור סיסמאות? לחצו כאן!

אם אתה טוען שהם איטיים כי מדובר ב-OO ולא ב-bytecode-ים כושלים, אתה בבעיה רצינית של ניתוק מהמציאות. הייתי אומר שאתה בעל תפישה חדה מאוד, אבל הפעם זה בכלל לא היה אתגר, אז זה לא יהיה נכון מצדי להגיד את זה.

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

נמאס לכם לזכור סיסמאות? לחצו כאן!

תכנות OOP לאו דווקא יותר טוב או יותר נוח.
הכל תלוי במימוש שלך..

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

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

כמובן, לעתים גם תיכנות לא-מונחה עצמים יכול להיות יעיל יותר.

המטרה של OOP היא שהקוד יהיה קריא יותר ומחולק בצורה יותר אנושית ומובנת לקריאה ושינוי.

במערכות קוד פתוח או כאלו שנערכות לעתים קרובות, חשוב שהקוד יהיה קריא יותר ולכן גם ב- vBulletin ו- IPB יש שימוש נרחב בOOP.