Конвенция за именуване, методи/функции, SOLID (SRP, OCP, LSP, ISP, DIP)

Здравейте ...

след като прочетох няколко фрагмента код тук се ужасих от лошият стил (липсващ) на повечето.

Държа да кажа че това най - вероятно ще остане единствената тема в която пиша нещо смислено. Ако българският ми не е перфектен, простете и се опитайте да се концентрирате върху съдържанието.

1. Абсолютно начало:

1.1. Когато именувате някаква единица в програмата си ползвайте повсеместни имена на английски, за да може да говорите за програмата си с хора които не са програмисти, но познават домейна на проблема.

1.2. Бъдете кратки, бъдете логични.Не използвайте brake или еквиваленти за да прекратите изпълнение.

Ето пример, който е написал някой от форума:

if($all_user_gold >= $maxres && $all_user_iron >= $maxres && $all_user_wood >= $maxres && $all_user_food >= $maxres) {

break;

}

Ето как би изглеждал фрагмента логично:

if (!condition) {...}

Избягвайте continue и goto, ако го правите може лесно да създадете код спагети.

Мислете по следният начин, за да бъде изпълнен един метод трябва да важат условия N, след изпълнение трябва да важат условия М. Старайте се да пишете кода, така че да става явно какви са тези условия.

2. Абсолютно начало - СОЛИДен код:

С - С ... Всеки клас трябва да има една причина за съществуване

О - Отворен за разширение, затворен за промени

Л - Лисковият Принцип за заместване на единици от програмата

И - Интерфейсите трябва да не бъдат дебели

Д - Д ... Единици функционалност трябва да зависят от абстрактни единици, не една от друга. Абстрактни единици не трябва да зависят от Детайли около една единица, Детаилите около единицата трябва да зависят от Абстракции.

С: Това е сравнително просто. Ако имам клас който да описва птици, то той трябва да се занимава само с птици, а не и с алигатори.

------------------------------

О: Когато се правят промени по един клас, те не бива да променят поведението му.

------------------------------

Л: Е много теоретично изкаване, аз ще го опростя максимално.

Инстанциите на клас, разширяващ друг клас, трябва дамогат да се обработят от неговите инстанции, без това да води до непредвидено поведение.

Още по просто:

Причината даден клас да разщирява друг е сходно поведение, а не логическа сходност.

------------------------------

Пример за И:

Лош Интерфейс:

interface Bird {

void eat();

void fly();

}

class Duck : Bird {

public void eat() {

...

}

public void fly() {

...

}

}

class Ostrich : Bird {

public void eat() {

...

}

public void fly() {

... ЩРАУСИТЕ НЕ ЛЕТЯТ ...

КАКВО ДА ПРАВИМ ТУК С ТОЗИ ИНТЕРФЕЙС

}

}

-----------------------------

Пример за Д:

public void doSomethingWith(Person p); противоречи на последният принцип.

Person, трябва да зависи от Абстракция, например Интерфейса IPerson.

Тогава кода може да изглежда така:

public void doSomethingWith(IPerson p); не Противоречи на последният принцип

-----------------------------------------------------------------------------

Препоръчвам тази книжка за по пълна информация. http://www.amazon.de/Clean-Code-Handbook-Software-Craftsmanship/dp/013235088