Защо трябва да обърнем сериозно внимание на ООП


10

Не знам колко от вас са обърнали Внимание на думите на Наков от първата лекция.

Става въпрос за разговор м/у него и тийм лидери от Телерик. Какъв е минимума което трябва да знаем.

http://www.youtube.com/watch?v=gHjl8KK_utU&feature=youtu.be&t=1h37m4s




Отговори



1
Честно казано, не съм виждал обява за програмист, в който не искат ООП. Няма значение дали е уеб или десктоп, java или c# :)

от SVGN_H (3048 точки)


0
Някой може още да не е гледал обяви :)

от Assi.NET (3050 точки)

0
Срещат се обяви с по два реда, но те не са сериозни.
Срещат се и обяви в които ООП е сложено от някоя ейчарка ей тъй за престиж.
За мен ООП е нещо като категория "С" - по-добре е да я имаш, когато искаш да караш автомобил. Особено, ако е за професионална употреба.

от Dobromir (777 точки)



1
Да знае един програмист ООП е толкова естествено колкото да има климатик в офиса. Никой няма да предположи, че след като кандидатства човек за работа като програмист няма да знае ООП така както никой няма да предположи, че в офиса където кандидатства за същата работа няма да има климатик.
ООП-то е лесно но... "лесно" е разтегливо понятие. Точно вчера си говорихме с един колега за който ООП-то е сложно и объркващо. Е да ама езиците му са лесни. При мен е обратното. Всичко зависи от това как на човек му работи мозъка.

от saykor (8845 точки)


0
Явно миналата година даже са приемали в Телерик хора от Академията без особенно големи познания.

от Assi.NET (3050 точки)

0
И за мен в момента ООП е объркващо;) Дано скоро ми се избистри ;)))




3
Защото ООП ти дава възможност едновременно няколко човека да работят по един проект без да става боза с кафе и мармалад в едно. :)
Освен това тази концепция ти позволява по-лесно да пускаш ъпдейти, а те са съществена част от поддръжката на един софтуер. Представи си да си купиш лека кола и да се окаже, че няма кой след 10 години да и направи основен ремонт и поради това да се наложи да я изхвърлиш на боклука. Кофти тръпка, нали така?
При софтуера много по-бързо се амортизират нещата и спестяването на ценно време за поддръжка е съществен момент за всеки себеуважаващ се програмист.

от Dobromir (777 точки)


0
Подкрепям думите на Наков, че не е трудно стига да му свикнеш.А как се свиква с нещо в порграмирането ? Писане, писане и пак писане на код.Последните седмици толкова пропъртита и конструктури направих (надявам се да несе повтарят :D), че вече даже мога да кажа, че свикнах и дори ми е забавно и си правя мои си работи.
thx for темата, информативна е.

от RamiAmaire (1868 точки)


1
Еми то без ООП накъде сме тръгнали. Те процедурните езици умряха отдавна. :)

от nikola76 (1250 точки)


4
Според мен проблема е друг. Много хора, изучавали ООП се изхвърлят за щяло и нещало да използват ООП в различните езици, включително в случаите, когато това не се налага. Пример мога да дам за малки проекти, писани на езици, поддържащи както процедурно, така и ОО програмиране. При много от тези проекти практически не се изпозлват похватите на ООП, а само се дефинират класове и методи, използвани впоследствие като чисти процедури. Това не само не намалява изписания код, а го увеличава. Отделно прави елементарния проект по-труден за разчитане. И още нещо ако не сте го разбрали: ООП е БАВЕН. Много по-бавен от процедурното програмиране.
А чаткайте сега минусчетата :)

от lamerko (1141 точки)


0
Да, има случаи, в които е по-подходящо процедурното програмиране. Но неговият дял все повече намалява.

от ellapt (6303 точки)


3
ООП и Web дизайнът са причините да кандидатствам за академията. Що се отнася до младите студенти, немислимо е да развиват кариерата си без ООП и Интернет технологии.
В едно мое проучване преди години, свързано с нови памети, ми "просветна", че софтуерът (и съвременният включително) за компютри е основан на линейни структури, което съществено се различава от паметта на живите същества.
Обектното програмиране за мен е начин за пространствено, многомерно описание на проблема и един вид средство за използване на многомерна памет. Освен това, то е много силно интуитивно. Ако не разбере и вникне в същността му още от самото начало, един кандидат-софтуерен инженер едва ли ще постигне целта си.

от ellapt (6303 точки)


0

С две ръце и десет пръста подкрепям горното мнение на Ella и към пространствено и многомерно бих добавил "разпределено", което е още един съществен аспект на не-линейността.

Надявам се и с този пост темата да изскочи нагоре за колегите от пролетния прием 2013, с които тъкмо започваме ООП-то.

:о)


от elfoles (434 точки)


8

Аз пък съм напълно съгласен с lamerko. И мога да дам примери от "реалния живот". Вднъж докато си лепих разни платки в офиса мултицета ми даде фира. А ми трябва да си измеря напрежението на едно захранване. Веднага, на момента. Ами ... ползвах ... осцилоскопа. Не беше толкова точно, но ми свърши работа. Но с мултицете щеше да ми е много по-удобно. Но не ми е идвала през акъла идеята всеки ден да меря с осцилоскоп за 1000 лева напрежения... :)

С ООП-то е малко подбна работата. Можеш да направиш всичко с него, но понякога е по-лесно, по-удобно, по-бързо и по-каквото се сетите да ползвате добрата стара техника, когато програмата почваше с BEGIN и завършваше с END.

Да, можеш и да изореш нивата с Ленд Ровъра, но ... не си е работа.


Някъде споменах, че се занимавах с микропроцесори на Microchip. Там имаш 1000 байта за програма и 100 байта "оперативна памет". Всеки байт и всеки такт на процесора са ти "под бройка". За мен е кощунствено да изкарвам 5 реда код в метод. И е така, защото знам че процесора трябва вътрешно да изпълни командата CALL. Преди това трябва да "скатае" някъде състоянието на регистрите. Самия оператор CALL отнема няколко такта на процесора. Извикването на метода нарушава линейността на програмата и ако имплементирания в него алгоритъм за предсказване не се усети, ще се окаже че кода който трябва да се изпълни не е подготвен в кеша, а трябва да се извика от оперативната памет. Това забавя десетки пъти скоростта на изпълнение на програмата. Да не говорим ако ОС е решила да суапне тая част от паметта в кеша на диска. Тогава нещата съвсем умират.

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

Но ... в края на краищата C# и изобщо голяма част от ООП-ready езиците не са създадени с идеята за бързодействие, а за удобство. Ако ви трябва скорост - връщате се на C++, асемблер и други такива "архаични" езици и похвати.

Има и някои дребни хватки, които могат да ви спестят време. Ето ви един най-елементарен пример:

Вариант 1:

            int[] x = new int[100000000];
            TimeSpan a = DateTime.Now.TimeOfDay;
            int b = 0;
            for (int i = 0; i < x.Length; i++)
                b = x.Length;
            Console.WriteLine(DateTime.Now.TimeOfDay - a);
Изпълянва се за 0.53 секунди.
 
Вариант 2:
 
            int[] x = new int[100000000];
            TimeSpan a = DateTime.Now.TimeOfDay;
            int b = 0;
            int len = x.Length;
            for (int i = 0; i < len; i++)
                b = len;
            Console.WriteLine(DateTime.Now.TimeOfDay - a);
Изпълнява се за ... 0.43 секунди.
Жертвам 4 байта памет и получавам 20% по-голямо бързодействие. Защото не питам всеки път "Ае, колко беше размера на тоя масив?" а си го запомням в променлива и работя с нея.
А искате ли да ви кажа за колко време се изпълнява това:
        public static int ArrLen(int[] arr)
        {
            return arr.Length;
        }
        static void Main(string[] args)
        {
            int[] x = new int[100000000];
            TimeSpan a = DateTime.Now.TimeOfDay;
            int b = 0;
            for (int i = 0; i < ArrLen(x); i++)
                b = ArrLen(x);
            Console.WriteLine(DateTime.Now.TimeOfDay - a);
        }
Ади, ще ви го оставя за домашно, че дори и аз се изплаших от резултата :)

 


от JulianG (5316 точки)


0
Евала за поста. Всъщност колкото и да редят старите езици, специално в C/C++ в доста случаи вместо функции могат да се ползват макроси, които хем не изглеждат грозно и претрупано, хем не са функции, няма операция CALL, копиране на памет и т.н., т.е. едновременно кодът е качествен и бърз. И затова много харесвам първите C-та, на C# няма такива работи, както казваш изобщо не са мислили за бързодействие.

от ncuxap (338 точки)


2
Според мен едни други думи на Наков са много по-важни. А именно, че добър developer означава човек, който познава много техники и има богат опит и мисли правилно, т.е ползва правилата технология в конкретното задание. ООП е един от многото инструменти, които могат да се ползват и е задължително да се разбират. Вярно фундаментален е, но нищо не пречи на някой от нас някой ден да му се наложи да ползва и C++ и асемблер за да си свърши качествено работата. Панацеи в компютрите няма.

от themagicis (262 точки)