סאָליד וואָס זענען די 5 פּרינציפּן פון כייפעץ אָריענטיד פּראָגראַממינג

סאָליד איז אַן אַקראַנים, ריפערינג צו די פינף פּרינציפּן פון כייפעץ-אָריענטיד פּלאַן (OOD אָדער OOP). דאָס זענען גיידליינז אַז דעוועלאָפּערס קענען נוצן צו שאַפֿן ווייכווארג וואָס איז גרינג צו פירן, טייַנען און פאַרברייטערן. אויב איר פאַרשטיין די קאַנסעפּס, איר וועט ווערן אַ בעסער דעוועלאָפּער און ויסמיידן ווייכווארג פאַרוואַלטונג פּראָבלעמס. וואָס טוט עס מיינען צו זיין אַ גוטע פּראָגראַמיסט?

עסטימאַטעד לייענען צייט: 7 minuti

ווער עס יז מיט עטלעכע דערפאַרונג אין ווייכווארג פּראָגראַממינג ריכטער סאָפטווער קאָד געשריבן דורך אנדערע, ניצן משפט פּאַראַמעטערס באזירט אויף זייער קאַריערע דרך.

אין לויף פון מיין פאַכמאַן קאַריערע, איך קען פילע דעוועלאָפּערס און איך האָבן געזען טויזנטער שורות קאָד, און ווען איך דאַרפֿן צו אָפּשאַצן די דעוועלאָפּער 'ס פיייקייט, איך קוק צוויי הויפּט:

• פּאַשטעס אין לייענען די קאָד;
• ווי מסתּמא זייער קאָד איז צו אַרבעטן און יוואַלוו איבער צייט.

צומ גליק, עס זענען עטלעכע פאַנדאַמענטאַלז אָדער פּרינסאַפּאַלז וואָס מאַכן עס גרינג צו זיין בעסער צו קאָדירן.

די אַקראַנים סאָליד שטייט פֿאַר:
S: פּרינציפּ פון איין פֿאַראַנטוואָרטלעכקייט
O: אָפֿן-פארמאכט פּרינציפּ
L: ליסקאָוו סאַבסטיטושאַן פּרינציפּ
I: פּרינציפּ פון צובינד סעגרעגאַציע
D: פּרינציפּ פון ינווערסיאָן פון דעפּענדענסיעס

זאל ס אָנהייבן מיט דילינג אין דער ערשטער סאָליד פּרינציפּ, ניימלי די

פּרינציפּ פֿאַר איין רעספּאָנסיביליטי

א קלאַס (אָדער מאָדולע) זאָל האָבן בלויז איין סיבה צו טוישן, צו אַנטוויקלען.

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

אָבער וואָס? 

פארוואס איז עס אַזוי וויכטיק צו האָבן בלויז איין סיבה צו טוישן?

פֿאַר בייַשפּיל, אויב עס זענען צוויי פאַרשידענע סיבות פֿאַר טשאַנגינג, עס איז קאַנסיוואַבאַל אַז צוויי פאַרשידענע טימז קען אַרבעטן אויף די זעלבע קאָד פֿאַר צוויי פאַרשידענע סיבות. יעדער וועט האָבן צו ינסטרומענט זייער אייגענע לייזונג, וואָס אין דעם פאַל פון אַ צונויפגעשטעלט שפּראַך (אַזאַ ווי C ++, C # אָדער Java), קען פירן צו מאַדזשולז וואָס זענען ינקאַמפּאַטאַבאַל מיט אנדערע טימז אָדער אנדערע פּאַרץ פון די אַפּלאַקיישאַן.

אן אנדער בייַשפּיל, אויב איר נוצן אַן ינטערפּראַטאַד שפּראַך, איר קען האָבן צו פּרובירן די זעלבע קלאַס אָדער מאָדולע פֿאַר פאַרשידענע סיבות. דעם מיטל מער אַרבעט, צייט און מי פֿאַר קוואַליטעט קאָנטראָל.

צו ידענטיפיצירן די איין שטריך וואָס אַ קלאַס אָדער מאָדולע זאָל האָבן איז פיל מער קאָמפּליצירט ווי נאָר קוק אין אַ טשעקליסט צו דורכפירן טעסץ. 

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

עטלעכע ביישפילן פון מאַדזשולז און זייער נוצן:

• וישאַלט מאָדולע: דער באַניצער איז קאַמפּרייזד פון דייטאַבייס אַדמיניסטראַטאָרס און ווייכווארג אַרקאַטעקץ.
• ריפּאָרטינג מאָדולע: דער באַניצער באשטייט פון אָפיס טוערס, אַקאַונטאַנץ און פּראָדוקציע.
• צאָלונג כעזשבן מאָדולע פֿאַר אַ פּייראָול פאַרוואַלטונג סיסטעם: ניצערס קענען אַרייַננעמען חכמים, מאַנאַדזשערז און אַקאַונטאַנץ.
• טעקסט זוך מאָדולע פֿאַר אַ ביבליאָטעק פאַרוואַלטונג סיסטעם: דער באַניצער קענען זיין רעפּריזענטיד דורך די ליבראַריאַן אָדער וויזאַטערז און קאַסטאַמערז פון דער ביבליאָטעק זיך.

אַזוי אויב דער ערשטער שריט איז צו זוכן פֿאַר די אַקטערז אָדער די אַקטיאָר וואָס האָבן די ראָלע פון ​​ינטערלאַקיאַטער מיט די מאָדולע, עס קען זיין שווער צו פאַרבינדן מענטשן מיט אַלע ראָלעס. אין אַ קליין פירמע איין מענטש קענען שפּילן קייפל ראָלעס, און אין אַ גרויס פירמע קענען זיין קייפל מענטשן וואָס האָבן איין ראָלע. 

עס מיינט צו זיין מער גלייַך צו ידענטיפיצירן ראָלעס ווי מענטשן אָדער וסערס.

דעריבער:

• די נוצן פון די ווייכווארג סיסטעם defiדערקלערט די סיבות פֿאַר די ענדערונג;
• אַ פֿאַראַנטוואָרטלעכקייט איז אַ משפּחה פון פאַנגקשאַנז וואָס סאַטיספייז די באדערפענישן פון אַ באַזונדער אַקטיאָר, וואָס איז דער באַניצער פון די סיסטעם;
• די אַקטיאָרן, דער באַניצער איז אַ מקור פון ענדערונג פֿאַר די פאַנגקשאַנאַליטי משפּחה וואָס מוזן באַפרידיקן דעם באַניצער 'ס נויט;
• די עוואַלושאַן פון באַניצער דאַרף, גוידעס די עוואַלושאַן פון פאַנגקשאַנאַליטי;

זאל ס זען עטלעכע ביישפילן

רעכן מיר האָבן אַ בוך קלאַס וואָס ענקאַפּס די באַגריף פון אַ בוך און זייַן פאַנגקשאַנאַליטי.

קלאַס בוך {

    פונקציע געטטיטלע () {

        צוריקקומען "א גרויס ספר";

    }

    function getAuthor () {

        צוריקקומען "Alessandro Baricco";

    }

    פונקציאָנירן ווייַטער בלאַט () {

        // ווייַטער בלאַט

    }

    פונקציע printCurrentPage () {

        ווידערקאָל "אינהאַלט פון קראַנט בלאַט";

    }

}

דאָס איז אַ זייער נאָרמאַל קלאַס. מיר האָבן אַ בוך, און דער קלאַס קענען געבן אונדז דעם טיטל, זיי קענען געבן אונדז דעם מחבר און זיי קענען גיין ווייטער. לעסאָף, עס קען אויך דרוקן די קראַנט בלאַט אויף דעם עקראַן. 

אָבער, עס איז אַ קליין פּראָבלעם. 

טראכטן וועגן די אַקטיאָרן וואָס זענען ינוואַלווד אין דער פאַרוואַלטונג פון דעם ספר כייפעץ, ווער קען זיי זיין? 

מיר קענען לייכט טראַכטן וועגן צוויי פאַרשידענע אַקטערז דאָ: ספר פאַרוואַלטונג (ווי די ליבראַריאַן) און דאַטן סאַבמישאַן מעקאַניזאַם (ווי ווי מיר ווילן צו צושטעלן אינהאַלט צו די באַניצער: אויף-פאַרשטעלן, גראַפיקאַל באַניצער צובינד, בלויז טעקסט באַניצער צובינד, אפֿשר דרוקן). 

מיר האָבן דעריבער צוויי זייער פאַרשידענע אַקטיאָרן וואָס ינטעראַקטינג מיט די קלאַס.

אין אַ נויט, דעם קלאַס מאכט אַ מישן צווישן:

• געשעפט לאָגיק מיט 
• די פּרעזענטירונג 

דאָס קען זיין אַ פּראָבלעם ווייַל דאָס ווייאַלייץ דעם פּרינציפּ פֿאַר איין אַכרייַעס (SRP). 

ווי קענען מיר טוישן, ווי קענען מיר פֿאַרבעסערן דעם קאָד צו אָנערקענען דעם פּרינציפּ פון איין פֿאַראַנטוואָרטלעכקייט?

קוק אין די פאלגענדע קאָד:

קלאַס בוך {

    פונקציע געטטיטלע () {

        צוריקקומען "אָסעאַנאָ Mare";

    }

    function getAuthor () {

        צוריקקומען "Alessandro Baricco";

    }

    פונקציאָנירן קער בלאַט () {

        // ווייַטער בלאַט

    }

    פונקציע getCurrentPage () {

        ווידערקאָל "אינהאַלט פון קראַנט בלאַט";

    }

}

צובינד פּרינטער {

    פונקציאָנירן פּרינטפּאַגע ($ בלאַט);

}

קלאַס StampaLibro ימפּלאַמאַנץ פּרינטער {

    פונקציאָנירן פּרינטפּאַגעס ($ בלאַט) {

        echo $ בלאַט;

    }

}

 

קלאַס HTML דרוקער ימפּלאַמאַנץ פּרינטער {

    פונקציאָנירן פּרינטפּאַגעס ($ בלאַט) {

        ווידערקאָל ' '. $ בלאַט. ' ';

    }

}

דער זייער פּשוט ביישפּיל ווייזט ווי צו שיידן די פּרעזענטירונג פון די געשעפט לאָגיק, און אין העסקעם מיט די SRP, עס אָפפערס גרויס אַדוואַנטידזשיז אין די בייגיקייט פון אונדזער פּרויעקט.

זאל ס קוק אין אן אנדער בייַשפּיל:

אַ ביישפּיל ענלעך צו די אויבן איז ווען אַ כייפעץ קענען ראַטעווען און צוריקקריגן זיך פון די פּרעזענטירונג.

קלאַס בוך {

    פונקציע געטטיטלע () {

        צוריקקומען "אָסעאַנאָ Mare";

    }

    function getAuthor () {

        צוריקקומען "Alessandro Baricco";

    }

    פונקציאָנירן קער בלאַט () {

        // ווייַטער בלאַט

    }

    פונקציע getCurrentPage () {

        צוריקקומען "אינהאַלט פון קראַנט בלאַט";

    }

    פונקציע היט () {

        $ פילענאַמע = '/ דאָקומענטן /'. $ דעם-> געטיטאָלאָ (). '-'. $ טהיס-> געטאַוטהאָר ();

        פילע_פּוט_קאָנטענץ ($ פילענאַמע, סיריאַליזע ($ דאָס));

    }

}

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

קלאַס בוך {

    פונקציע געטטיטלע () {

        צוריקקומען "אָסעאַנאָ Mare";

    }

    function getAuthor () {

        צוריקקומען "Alessandro Baricco";

    }

    פונקציאָנירן קער בלאַט () {

        // ווייַטער בלאַט

    }

    פונקציע getCurrentPage () {

        צוריקקומען "אינהאַלט פון קראַנט בלאַט";

    }

}

קלאַס סימפּלעפילעפּערסיסטענסע {

    פונקציע שפּאָרן (ספר $ ספר) {

        $ פילענאַמע = '/ דאָקומענטן /'. $ ספר-> געטטיטלע (). '-'. $ book-> getAuthor ();

        טעקע_פּוט_קאָנטענץ ($ פילענאַמע, סיריאַליזע ($ בוך));

    }

}

אריבערפירן די פּערסיסטאַנס אָפּעראַציע צו אן אנדער קלאַס וועט קלאר באַזונדער ריספּאַנסאַבילאַטיז און מיר וועלן זיין פריי צו וועקסל פּערסיסטאַנס מעטהאָדס אָן אַפעקטינג אונדזער ספר קלאַס. פֿאַר בייַשפּיל, ימפּלאַמענטינג אַ דאַטאַבאַסעפּערסיסטענסע קלאַס וואָלט זיין נישטיק, און אונדזער געשעפט לאָגיק געבויט אַרום בוך אַפּעריישאַנז וועט נישט טוישן.

לייענען די רגע פּרינציפּ עפֿן / קלאָוזד ->

Ercole Palmeri