Что значит «Знание основ ООП»?

Question

[k_brainstorm]

Почти в каждой вакансии в духе "Программист C# (стажер)" требуется знание основ ООП.
Объясните пожалуйста кто - нибудь, что подразумевается под словом "основы".

Comments

[Алексей Немиро]

Опыт общего пользования :-)
Если серьезно, умение ориентироваться в объектах, разговаривать с ними и понимать их :-)
Если еще серьезней - это объектно-ориентированное программирование: https://ru.wikipedia.org/wiki/Объектно-ориентирова...

Answer 1

[Андрей Васильев]

Рекомендуемо к прочтению
www.ozon.ru/context/detail/id/4574420

Comments

[Евгений]

надо давать правильные ссылки rutracker.org/forum/viewtopic.php?t=4212311

[Андрей Васильев]

Nc_Soft: +5

[Дима Соколов]

Там PHP а не C#

Answer 2

[Армянское Радио]

Умение отвечать на два баянных вопроса:
-Чем отличается абстрактный класс от интерфейса
-Почему в С++ нельзя бросать исключение в деструкторе (да, именно в такой формулировке, выдающей, что вопрошающий сам ни в зуб ногой).

А если серьезно, это умение хорошо проектировать объектную структуру приложения, которое выражается в знании того, что вообще с классами можно делать, как организовывать их отношения между собой, и как это делать не надо. Достигается многочасовым практическим опытом.

Интересная статья: Как два программиста хлеб пекли.

Comments

[Евгений]

о, спасибо, давно искал эту статью, но находилась почему-то всегда эта habrahabr.ru/post/141477

[raiboon]

Армянское Радио а почему "да, именно в такой формулировке, выдающей, что вопрошающий сам ни в зуб ногой"?

[Армянское Радио]

raiboon: потому, что если выбросить и поймать исключение в деструкторе, ничего страшного не случится.

А вот если оставить исключение не пойманным, то вовремя чистки мусора от другого исключения мы схлопочем std::terimnate.

[raiboon]

Армянское Радио: Всё-равно не понял, почему неграмотная формулировка.

[raiboon]

Армянское Радио: Стоп, понял, о чем вы. А что если деструктор был вызван, когда уже было исключение? -> std::terimnate
Да и стоит помнить, что в деструкторе мы освобождаем память - исключение - не все конструкции выполняться - утечка памяти.
(я просто сейчас учу с++. так что интересуюсь, а не спорю)

[Армянское Радио]

raiboon: Правильная формулировка: "Почему нужно ловить в деструкторе все исключения?"

То есть:
1. Бросать исключение в деструкторе можно.
2. Но нужно обязательно его ловить до выхода из деструктора. А также нужно ловить все исключения, которые могли быть выброшены не вами, а тем кодом, который вызван в деструкторе.

[Армянское Радио]

raiboon: да, все правильно. То есть самый мимими-деструктор:
-объявлен виртуальным (это кстати третий баянный вопрос, "почему деструктор всегда должен быть виртуальным (ну еще есть ответвление на слово final, но это уже глубоко)").
-желательно, чтобы выглядел так
alpha::~alpha()
{
try
{
//деструктор
}
catch(...)
{
cerr << "Что-то откуда-то прилетело, босс. Го отлаживать\n"<<__FILE__<<" ["<<__LINE__<<"] "<<__FUNCTION__<<'\n';
std::terminate();
}
}

[raiboon]

Армянское Радио: Благодарю

[k_brainstorm]

Как мне оценить, насколько хорошо спроектирована объектная структура моего приложения? Мб есть какие-то критерии?

[Армянское Радио]

k_brainstorm: Такого универсального "хорошо" не придумаешь. Вам какое "хорошо":
-удобство модификации кода, добавления новых компонентов?
-быстродействие?
-легкость расщепления программы для юнит-тестов?
-скорость разработки?

[k_brainstorm]

Армянское Радио: ну, например, первое

[Армянское Радио]

k_brainstorm: тогда проверка такая - предполагаете, что вам нужно добавить в приложение компонент. И смотрите, сколько кода вам нужно перелопатить, чтобы это получилось. Понадобится ли после этого рефакторинг? Возникнет ли пенальти по производительности? Сколько документации придется переписать?

[Don Kaban]

За ответ "деструктор ВСЕГДА должен быть виртуальным" надо саркастически улыбаться и предлагать зайти через год.

[Армянское Радио]

Don Kaban: ну как сказать. Лепить virtual перед каждым деструктором - значит следовать совету Голуба #139. Голуб свой совет не зря написал, и это действительно в общем случае потенциально повышает надежность кода (путем раздувания, отказа от некоторых оптимизаций и так далее) . Особенно, если кто-то потом унаследуется от нашего класса и будет использовать указатель на него. То есть вроде как ответ ВСЕГДА должен быть виртуальным - это 4. А 5, это "всегда виртуальный, но если никто от класса наследоваться и обращаться по указателю не будет, можно и virtual убрать".

Про "саркастически улыбаться". Ну это как минимум не тактично. Можно и рассказать, или хотя бы ссылку дать. Иначе это похоже на поведение плохо написанной программы "Ой все, я упала! Логи? Фиг тебе! И стэктрейс не дам!"

[Don Kaban]

Ок. Следующие два вопроса в этом предпологаемом собеседовании, если уж улыбаться нельзя :
1. Как запретить наследование от данного класса?
2. Что (идеологически) может быть базовым классом, а что - нет? (за Лисков - бонус :)

Ну и общечеловеческое - если "кто-то" может непонятно с какого перепуга отнаследоваться от конкретного класса - это, собственно проблемы этого "кого-то". Но это так, лирика.

[Армянское Радио]

Don Kaban: Там еще на предыдущем интервьюер может интересно так сесть в лужу, если его коварно подловят на том, что хороший оптимизирующий компилятор умеет делать девиртуализацию.

[Армянское Радио]

Вот как раз статья: "Городские легенды о медленных вызовах виртуальных...

Answer 3

[asd111]

Если знаешь C# то считай что основы ООП ты уже знаешь.Основы ООП это инкапсуляция(сокрытие реализации за интерфейсом), полиморфизм( возможность использования нескольких реализаций функционала - например overload методов), наследование(думаю тут итак понятно). Это и есть основы ООП. Обычно в книгах по C# и по Java всюду пишут про эти понятия и показывается что и как выглядит в коде.
И ещё нужно уметь писать generic классы и методы - очень важно для C# и Java.

Answer 4

[Евгений]

Одержимость Офигенными Паттернами

Answer 5

[Пума Тайланд]

На самом деле ничего не значит так как си шарп полностью ооп язык и там само собой разумеющееся что вы знаете все про ооп.

Answer 6

[Илья Т.]

тем кто говорит, что все кто пишет на шарп - знают ооп: не соглашусь, я несколько проектов на шарпе написал используя только структурный подход (я этим не горжусь).