Софтуерно Инженерство
Loading...
+ Нов въпрос
Matrix avatar Matrix 1087 Точки

[Useful Info] OOP - Полезни линкове, съвети и инфо по темата

В хода на моето обучение, последния обектно ориентиран код, който съм писал беше за изпита по ООП, когато бях в Телерик, та оттогава досега бая неща съм позадбравил и реших да си ги преговоря... За щастие имам навика да си водя бързи записки (къде без грешки, къде не) по различни теми и да ги качвам в блога, така че просто се върнах да си припомня какво е било... Видях, че съм писал една полезна тема със съвети за самия изпит по ОПП, който и тук в СофтУни се очертава да бъде май същия, така че ви я споделям, мисля че ще ви влезе в употреба.

С това откривам и самата тема, която можем да я използваме с такава цел - да си споделяме различни полезни ресурси... Честно казано, ООП темата е бая дебела и има доста за четене по нея, така че тук можем да споделяме различни полезни линкове.

9
C# OOP Basics 19/09/2014 15:34:38
RoYaL avatar RoYaL SoftUni Team Trainer 6883 Точки

Темата много ми харесва, за това се включвам веднага :)

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

1. Името на променливата в полето да се пише с малка буква.

2. Автоматичното пропърти трябва да е с главна буква

 

Това, както попитах и в другата тема - не може ли само пропърти. Четох по въпроса и не открих добра причина да се ползва и поле и пропърти.

 

Другото е

4. Параметрите на Конструктора е хубаво да се именуват като стандартни променливи, по-възможност различни от тези в полетата, за да е по-лесно ориентирането после.

 

Няма нужда - нали за това всичко е разделено по неймспейсове, класове и инстанции на обекти. Това все едно да кажеш, че за всяка инстанци на класа, трябва да се казва по различен начин името на пропъртито за Име на човека, понеже може да се объркаш, ако напишеш

personOne.Name = personTwo.Name;

 

В този смисъл се гледа инстанцията, от която е извикан, така и в конструктурите се гледа инстанцията, а именно - this

 

public MyConstructor(string myVar)

{

    this.myVar = myVar;

}

 

Пределно ясно е, че на текущия обект (this) полето myVar получава стойността на myVar

Тук по-скоро грешката, която допускам е, че асайнвам директно към поле, но както по-рано казах, според мен няма нужда и от двете (поле и пропърти)

Всмисъл това за именуването го казвам, защото ми се струва, че ако се опитваме във всеки клас и всеки метод да именуваме всичко по различен начин, се губи смисъла от пакетирането - излиза че все едно всичко е в един global scope и човек се опитва да избегне повтаряемост. Но след като пишем на строго обектно ориентиран език като C# няма нужда излишно да си усложняваме живота търсейки различни имена, за нещо което е едно и също. А и понякога е невъзможно, както дадох примерно с асайнвамено на името на първия човек, към името на втория човек.

В един по-остарял стил на писане се използва ъндърскор пред прайвит пропъртитата на класа за да се стигне до тази четимост, за която се говори.

Ето един полезен линк от мен (от секцията за правете на библиотеки съвместими с .NET Framework т.е. препоръчителните неща са потехния стил на писане)

http://msdn.microsoft.com/en-us/library/ms229060(v=vs.110).aspx

И цитат съответно, по това което коментирах:

√ DO use the same name for constructor parameters and a property if the constructor parameters are used to simply set the property.

5
18/09/2014 15:32:29
Samuil.Petrow avatar Samuil.Petrow 1551 Точки

Единствената полза от поле + проп е да не се занимаваш да пишеш после полето ако изскочи валидация.

2
18/09/2014 16:00:03
g.stoyanov avatar g.stoyanov 760 Точки

Ако искаш не ползвай поле - prop (tab-tab) и си ползваш само пропърти - С Главна буква, което си създава служебно поле без ти да го виждаш. А ако имаш нужда да правиш нещо различно то това ти подсказва че имаш нужда и от двете. Аз ползвам или Пропърти + поле или само Пропърти. Мисля си че това е правилния вариант.

1
g.stoyanov avatar g.stoyanov 760 Точки

Много е полезно още от сега да се използва StyleCop. Създава добри навици за писане на качествен код и подсказва за пропуснати this. или неправилно подредени полета, конструктори пропъртита и т.н..

2
GalyaGeorgieva avatar GalyaGeorgieva 88 Точки

Имам въпрос?

Клас-наследник има два метода :

- единият се имплементира като интерфейс (Метод Х)

- другият идва като member от абстрактен клас-родител (Метод У), т.е. не е в интерфейс

Класът-наследник трябва да вложи единия метод "У"  в другия метод "Х"...

Та въпросът ми е отделно ли  трябва да овъррайдвам вложения метод "У" (преди да го вложа в другия), защото  Resharper ми се кара, ако не го направя или нещо бъркам?

0
RoYaL avatar RoYaL SoftUni Team Trainer 6883 Точки

Какво разбираш под влагане на методи? Може ли пример?

 

0
GalyaGeorgieva avatar GalyaGeorgieva 88 Точки

Това ми се получи на финал, но направих метода DestroySHip(Ship target) virtual, защото иначе трябваше да го имплементирам навсякъде в класовете наследници.(а си мислех, че като го викам в другия метод няма нужда отделно да го овъррайдвам)

ИНТЕРФЕЙСЪТ: public interface IAttack

    {
        string Attack(Ship target);
    }

КЛАС РОДИТЕЛ: public abstract class BattleShip : Ship, IAttack

public abstract string Attack(Ship target);

public virtual string DestroySHip(Ship target)
        {
            return string.Format("BOMMMMM {0}", target.Name);
        }

КЛАС НАСЛЕДНИК: public class Destroyer : BattleShip

public override string Attack(Ship targetShip)
        {
            this.DestroySHip(targetShip);
            return "Destroyer :  They didn't see us coming!" + this.DestroySHip(targetShip) + " " + targetShip.GetType().Name;
        }

0