Сучасна диджитал-освіта для дітей — безоплатне заняття в GoITeens ×
Mazda CX 30
×

Абстрактный класс и интерфейс :D

Кажется, когда-то давно читал похожее, когда опытные программисты возмущались вопросом на собеседовании: «в чем разница между абстрактным классом и интерфейсом». Тогда был джуном и возмущений не понял — ну знаешь же, ответь. :)

Сейчас сам столкнулся с похожим. Вопрос ставит в ступор. На работе занимаешься чем угодно, кроме сравнивания абстрактных классов с интерфейсами :(

Формулировка — сравнить эти две вещи, и что от тебя ждут ответ на это, кажется абсурдом и отключает. Может нужно ходить регулярно на собеседования для поддержания формы?

👍ПодобаєтьсяСподобалось1
До обраногоВ обраному1
LinkedIn

Найкращі коментарі пропустити

Работать и проходить собеседования — два разных занятия, требующих 2х разных, обычно не пересекающихся, наборов скилов.

Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Мои рассуждения и вопрос знающим и понимающим, надеюсь на советы, поправки и подсказки для правильного понимания.

Можно сказать что интерфейс — набор требований, которым должны соответствовать абсолютно
разные объекты, т.к объекты разные, то и реализация требований для каждого объекта может сильно разнится. Плюс, если нет необходимости соответствовать этим требованиям, нету необходимости реализовывать этот интерфейс.
Пример как вижу я: объект Перевозчик может перевезти любой объект, который реализовывает интерфейс IVolumable: кукуруза сама знает как посчитать свой объем, утюг — сам, человек — сам. Объекты абсолютно разные, реализация разная, но для Перевозчика разницы нету — каждый IVolumable сообщил свой объем, и Перевозчик понимает как их перевезти, сколько их влезет, сколько это стоит. Кукуруза захочет что бы ее перевезли, она должна реализовать IVolumable, человек захочет что бы его перевезли, он должен реализовать IVolumable, утюгу никуда не надо, соответственно и имплементить этот интерфейс мы не будем...

Абстрактный класс — описывает (и просит следовать) общее поведение и свойства для группы схожих объектов-наследников. Ключевая фраза — схожих объектов. Между утюгом, человеком и кукурузой ничего схожего нету, также как и маловероятно что и них будет общий абстрактный класс.
Пример как вижу я: общий абстрактный класс AbstractIron, с единственным методом toIron(). Утюги есть разные, по-этому гладить будут по-разному: низкая температура, высокая, отпаривание и тп, но гладить они должны уметь все, соответственно все должны (пускай по-своему) реализовать toIron().
Общий абстрактный класс AbstractCorn, с единственным методом toRipe(). Разные сорта кукурузы будут созревать по-разному, но созревать они будут все.

Т.е. как это понимаю я — с архитектурной точки зрения (не вдаваясь в подробности копмиляции), интерфейс и абстрактный класс сравнивать некорректно, эти два понятия несут разное назначение. Они чем-то похожи: есть абстрактные методы; у них есть различия: наличие методов с имплементацией, возможность инстанциировать (и пр. особенности зависящие от ЯП).
Исходя из моего скудного опыта: интерфейс — более чаще используется в повседневной разработке, абстрактный класс — более чаще используется при написании фреймверков и каких-то библиотечных решений.
Интерфейс позволяет наделить разные объекты схожим/требуемым поведением, абстрактный класс задает «костяк» для группы схожих объектов.

Прошу поправить мои размышления. Ваш фидбек для меня важен. Возможно кому-то из начинающих также чем-то поможет.
Спасибо

Мій декан казав: «Нема дурних питань. Є дурні відповіді».

От ніколи такого питання сам не задавав, але вже кілька разів відповідав. І кожного разу відповіді були різними.
Зараз розумію шо питання прекрасне. Воно позволяє зрозуміти який тон співбесіді варто задавати далі і де будуть сильні і слабкі сторони.

Тільки уявіть скільки відповідей можна придумати. Наприклад:

1. В абстрактному класі можна мати реалізацію в методах, а в інтерфейсі — ні.

Шо ми з того можемо отрмати? Якшо ми Java джуна співбесідуємо то стає ясно шо про Java 8 він ше не прочитав.

2. В абстрактному класі можна мати поля і конструктор, а в інтерфейсі ні.

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

3. Можна імплементити багато інтерфейсів, але розширяти лише один абстрактний клас.

З моєї точки зору то вже перший крок до ДЗЕНу (якшо не заблукає в тенетах технологій і зможе з часом думку цю розвинути). Можливо, при хорошому наставнику, можна виростити діамант.

4. Відповідь з розряду як від Oleksii Pavlov «хто я» і «шо я роблю» явно вказує — про нюанси мови багато говорити не треба. Маємо справу з художником, а не письменником. В таких випадках я розвішую вуха і стараюся сам чогось нового на співбесіді навчитися.

Правильних відповідей може бути багато. І кожна несе важливу інформацію про кандидата.

Якось дивно, що ви в п.3 бачите дзен, замість ще одного «загострення уваги на нюансах мови», як в п.2 ) То ж ті самі яйця, тільки в профіль. Нє?

якшо не заблукає в тенетах технологій

Угу, он в ПХПшечці

3. Можна імплементити багато інтерфейсів, але розширяти лише один абстрактний клас.

але потім трейтами такого насувать, що Страуструп би охрінів ))
Про який-небудь тайпскрипт взагалі промовчу.

Ну і де тут дзен, медскіллз, рокетсайенс, оце от ось все?

Ну і де тут дзен, медскіллз, рокетсайенс, оце от ось все?

Я ж писав шо то тільки

перший крок до ДЗЕНу

То ж спершу треба хаос пізнати, а вже тільки тоді дзен приде :). Або не прийде.

чета вспомнилось как я работал на большую компанию у которой была везде гигабитная сеть и на тренинге по айпи телефонии я с удивлением узнал что у большинства присутсвующих просто немерянно вопросов по кодекам из за того что у них у них проблемы с устойчивой связью между оффисами, у них там то выделенка на 128мб, а то и вообще на 64мб. И вот вместо того что бы разбираться как делать конференции на 20-30 участников мы разбириались какой разговорный кодек лучше работает на 128мб выделенке. Так и тут, чуваки с джавой задрачивают абстрактные классы и интерфейсы, в то время как чуваки с го, питоном и руби просто пишут код.

По поводу пункта 3. А как быть с множественным наследованием на сях? :-) Или такой дзен вы еще не познали?

Да ответить-то на этот вопрос не сложно — интерфейс это паттерн, а абстрактный класс это один из вариантов его имплементации. Только тут вот какой момент — если на собеседовании спрашивают такую философию может ну его идти в эту банду философов?

интерфейс это паттерн

В каком смысле?

если на собеседовании спрашивают такую философию может ну его идти в эту банду философов

Философию спрашивают везде. Главное, чтобы не держались требования дословных ответов.

Я так предполагаю что автор в данном контексте имел виду именно interface не как патерн.

Самое прикольное, что те кто не могут ответить на этот вопрос, или отвечает на него чисто с технической точки зрения, потом радостно создадут абстрактный класс размеры и унаследуют от него слона и дом. Дом is Размеры и Слон is Размеры, логически маразм, но технически то все работает.

Последние 2 года, я вообще считаю что ООП есть самым большим злом для IT индустрии. К сожалению 25 лет назад был выбран неправильный путь развития.

Проблема не в ООП а в том что забили на ФП и ЛП

ваше мнение нам очень важно. пешите ищо

btw, это довольно популярное мнение, по поводу того, что сечас понимают под ООП
его, например разделяет Алан Кей

ООП не зло. Зло — неправильно його використовувати. Ліпити крізь де тільки можна, не зважаючи на той факт, що для більшості задач воно просто не підходить як клас інструментів.

ООП не зло. Зло — неправильно його використовувати.

Дуже з тим згіднийю І, як на мене, ситуація сильно усугубляється тим, що об’єктів напхали у фреймворки. ООП добре використовувати для моделювання бізнес домену. Але казати шо Сервлет/котроллер/http-handler є об’єктами то трохи мені дивно. Вони може і є обєктами, але зовсім на іншому леєрі абстракції.
Особливо мене вбивають сінглетони-сервіси (як от в Спрінгу). Ну які з них обєкти? Коробочки з функціями і купкою залежностей.

Я схильний думати що для правильного використання ООП треба мати нехілий скіл аналітика. Бо шо таке правильне використання ООП — то не є написання приватних полів чи наслідування, то в першу чергу ОО Дизайн. Себто це є вміння зробити адекватну модель реального світу. Не повну (шо є неможливим), а таку яка відображає ті аспекти реального світу, які важливі для нашого бізнесу і щоб ця модель не мала внутрішніх конфліктів. Ну і само собою шоб побудувати модель «чогось» треба те «щось» розуміти.

Разом з тим мене дивує відмова від простих функцій і Стуктур даних типу record у багатьох мовах. Пошо було казати шо все є об’єктом і далі вперто зберігати інформацію в базі даних?
ООП доволі складно впихнути в просту трьохлеєрну архітектуру бо його там зазвичай просто непотрібно. Натомість воно може себе непогано зарекомендувати в складній бізнес логіці (і то не завжди).

Я вже колись висловлював думку, що для моделювання подій реального світу ООП не підходить взагалі. Точніше не так, реалізувати можна, але це буде франкенштейн ще той. Тому що реальні події це не набір імперативних команд, а обмін сигналами між різними автономними системами. ООП це може описати, але більше характеристики систем, ніж їх взаємодію

ООП описує стан систем (створює caching proxy). Завдяки цьому реально асинхронна взаємодія реального світу зводиться до синхронної й відтворюваної логіки викликів методів у програмі. Профіт — те, що таку програму взагалі можна написати й протестувати, на згорівши в callback hell.

Стан та структуру, я б сказав.

В цілому я згоден.
І з паном Denys Poltorak

Профіт — те, що таку програму взагалі можна написати й протестувати, на згорівши в callback hell.

згоден ще більше.

ООП то є один з компромісів між зрозумілістю, трейсабіліті і точністю/акуратністю моделі реального світу. Власне для того вона і «модель» шоб бути спрощеною і тим самим менш точною.
Тож ООП підходить там де поведінка обєктів є сталою і методи взаємодії теж:
— є сталими (коли залежності створюються на початку життєвого циклу)
— або хоч якось детермінованими (коли залежності передаються через параметри виклику методів).

Ну і ясно шо то далеко не всі випадки які бувають в жізні.
Для тих випадків, коли взаємодія є малодетермінованою, придумали івент-бас чи пабліш-сабскрайб. Власне ви про то самі вже сказали (про події).
А коли в нас взаємодії мало, але є спільні ресурси то придумали семафори і прочу синхронізацію.
А коли поведінка обєктів часто міняється то придумали динамічні біхейвори (в Unity 3D таке можна класно реалізувати). А ше в JavaScript то гарно виходить бо можете вставити любу функцію в любий обєкт. Тільки так рідко роблять бо воно не підходить для великих розробок. Когнітивна складність завелика. Її можна зменшувати, якшо рухати галузь і придумувати нові інструменти/фреймворки. Власне воно так потрохи і рухається.

Тож моє ІМХО шо задач для яких ООП є гарним інструментом є немало. Хоча набагато менше, чим місць в яких його недолуго застосовують. І знову ж таки — інженерів багато, не кожен встиг осягнути багато концепцій (власне мене бісить коли замість підходів люби вчать фреймворки, але шо ж тут попробиш). От і доводиться навіть самому пхати ООП туда де воно не дуже то і пасує, тільки тому шо команда то зафоловить швидко, а для проповідування івент-бейз чи конкарент підходу зі спільним стореджом потрібно буде витратити місяці.

Але не можна відступати. Треба вчитися в інших і вчити інших. Бути відкритим до нових парадигм і експериментувати по можливості (звісно якшо не атомну станцію прогамуємо і не Фалькон)

А хіба

івент-бас чи пабліш-сабскрайб

не працюють разом з ООП? То ж ортогональні парадигми.

Та так. Я ж не кажу шо воно взаємовиключається. Воно взагалі все зі всім зазвичай прекрасно пляше. І навіть доволі гарно разом програмується. Суть в тому яку з концепцій ми беремо за основну, а які беремо як додаткові.

От візьмемо Чейн обробки http запиту наприклад з Томкету. З точки зору роботи ВебСервера там жеж все event-based. А як на то люди часто дивляться? Є обєкт «сервлет», є обєкт «фільтр», є обєкти «ріквест» і «респонз». Тільки ж в тому випадку обєктна модель є непринциповою взагалі. Вона тоді стає не моделлю нашої апки а нижньорівневим інструментом про який можна і не думати. Я таке взагалі не називаю як ООП. Я говорю про ООП/ООД як про реалізацію вашої основної бізнес задачі.

Вертаючись до теми нашого топіка. Інтерфейс то не є то шо в програмі створене за допомогою кліючового слова interface.
На прикладі Java:
а) InputStream з точки зору реалізації є абстрактним класом, а по факту є інтерфейсом з кількома дефолтними методами
б) Cloneable, Serializable з точки зору реалізації є інтерфейсами, а по факту є атрибутами класу.

І тут якраз і халепа шо люди вчаться програмувати по книжках де описані нюанси неідеальних мов проограмування. Моя улюблена Java насправді настільки гівняна в тому плані шо деколи верне.
Натомість варто б трохи більше просвітитися в філософії. Хоча тут багато людей вважають шо то лажа непотрібна. Але кожному своє і я не хочу дуже спорити. Ринок великий і на ніші дизайну місця побільше, ніж на ніші кодінгу. Тому я і дивлюся в сторону філософії, а не інструментів програмування.

dou.ua/forums/topic/28077
А де на ринку місце в ніші дизайну? Якось не дуже видно, щоб багато лежало позицій архітекторів, та й серед них купа формальних — на мітинги ходити.

А де ви бачили шоб на вулиці вішали обяву «Шукаємо рідкісний вид інженера. Готові платити купу бабла». Таке оголошення на стовбі не спрацьовує. Дарма папір з чорнилами потратимо. Таких людей шукають по референсах, в курілках і часто вислідковують в засідці, вплоть до того шо по інсайдах чекають поки такого екземпляра шось за..бе на поточному місці і аж тоді перевербовують. Зазвичай зусилля того варті. ХедХантеру дадуть неймовірний бонус і рефералу теж.

Але шо я Вам то пишу. Ви і без мене в курсі. Але най тут пост висить чисто для реклами :)

ЗІ. На українському ринку з тим таки проблема. Багато з тих хто вмів малювати природним чином перекочували на захід чи за океан і тепер звідти малюють діаграми для місцевих бодішопів. Але не все так погано.

Ну я ще не в курсі — десь під кінець року треба буде шукать роботу, бо проект закінчується. Тому й питаю, як це здійснити правильно.

Про столицю не скажу нічого. Скажу про свій досвід у Львові.
Зі свого досвіду на шо я звертаю увагу:
1. Невеликий клієнт (або хоча б невеликий проект). Тоді той проект плекають і бережуть, а не просто косять з нього бабло поки він ше не зігнив. Під клієнтом я маю на увазі компанію, яка вам буде гроші платити (ті шо тут в рейтингах світяться і не тільки). Класно коли то продуктова компанія чи стартап, але і в аутсорсі і аутстафі є прекрасні екземпляри.
2. Як менеджер і лід проекту до свого проекту відносяться? Якшо халатно — то можна буде філонити і самому, але буде скучно і вам будуть платити за то скільки ви просиділи на кріслі, а не за рух електронів у мозку.
3. Бажано без розподілених команд. Якшо пів команди тут, а пів в Бангалорі то то вже неефективно і вони будуть вас тормозити. (Можливо вони вас і навчать чомусь, але я такого ше не зустрічав на практиці)
4. Якшо вже і є команди в різних кінцях світу то варто шоб вони працювали над незалежними модулями і ваша робота не була ними заблокана.
5. Поговоріть з майбутніми співробітниками на проекті за чашкою кави ше до того як підписали Офер. То самий гарний показник. Вони вам з ймовірністю 99% розкажуть все як є і ви зразу зрозумієте середній рівень людей на проекті і навіть зможете прикинути яку роль займете там з часом.

Ну і само собою для того шоб мати хороший результат потрібно мати хоч якусь вибірку. Мені зручно піти на 5-7 співбесід до того як вибрати собі нового клієнта.

І саме головне з моєї точки зору — шукайте місце де у вас буде з ким подискутувати. Ті хто зацікавляться вишими аналітичними і дизайнерськими скілами будуть вас хантити активніше. Якшо шукають просто кодера то і в них вибір більший і ви тоді не настільки цінні. Не ведіться на великий бонус. То все від лукавого. Просто клієнту треба срочно команду сформувати бо він свого клієнта просере інакше. Я волію вибити більший рейт, а бонус мені не потрібен.
Одним словом ідіть туди де хочуть ваш талант, а не закрити вами вакансію.

Дякую!
Думаю шукати власне позицію архітектора (вищий рейт, можуть бути цікаві задачі), та їх небагато пробігає. І серед них «справжніх», де потрібно реально щось робить, а не бути представником контори на мітингах — ще менше.

Я ше ніразу не заходив в команду зразу як архітектор чи лід. Таке можливо, але я такого не робив просто (не шукав таких позицій, а якшо і траплялися то просив шоб зразу таких пагонів не давали). Частіше виходить зайти просто сіньйорним інженером і почати помагати місцнвому інженеру який є архітектом, або виконує таку роль. Той чувак всерівно знає більше за вас в проекті. Команда не буде вас сприймати як назначеного начальніка, а сама вас вибере і піде за вами якшо ви себе добре проявите.

Навіть якшо там є вже хороший архітект то він вас навчить. І якшо він хорооший то він скоро піде на повишення чи на інший проект, а той вам залишить. А як і не піде то і то не страшно. Буде людина з якою приємно працювати і давати йому поради. І вчитися-вчитися-вчитися в нього.

Правда буває стрьомно коли ви його перескакуєте по скілу, а він і далі лишається на проекті. Власне якшо в нього пагонів не було офіційно то то ше пів біди. А коли в нього пагони забирають, вам дають, а він залишається — чекай біди в колективі. Але адекватний менеджер такого не допустить, або захендлить.

Вже набридло вчитись. Та й накодився за останні 5 років. Час використовувати й передавати досвід.

Я вчився на заочному і працював. Було капєц як гєморно. Коли я здав диплом, то сказав шо ніколи більше не буду одночасно вчитися і працювати. Зараз я ржу з тої свої фрази. Я розумію шо то тільки разом і можна робити. Вчитися виходить тільки під час роботи, вирішуючи реальні завдання. Найпростіше вчитися в когось досвідченого. Коли такого нема рядом, то треба себе оточити скіловими людьми. Нехай ви і будете самий скіловий, але кожен з них в чомусь та й буде кращий. І ви всерівно будете постійно помилятися (ну я так постійно косячу), а вони будуть ваші помилки лапати і вам показувати. І то теж дуже ефективне навчання.

Я в людей майже не вчився. В перший тиждень роботи побачив такий неефективний код на проекті, що собі не повірив, і передивлявся. Потім сам фіксив баги, потім — лишився один на проекті з нашого боку, й сам імплементив дуже великі шматки. Потім — ходив в сусідню команду малювати й кодить нову архітектуру. Далі — перестрибнув з міда на ліда, тоді — поцибав між конторами, коли кілька разів підряд то вилітав з бенчу, то звільняли. Зараз — зробили маленькою командою проект з нуля.

Друга штука. Архітектор який сам не кодить то є катастрофа. Він перестає відчувати біль простого інженера і веде проект в непонятну сторону. Задача архітектора зробити розробку дешевою. А отже рядові інженери повинні відчувати легкість і радість при роботі з кодом. Як ви будете знати шо саме в коді і дизайні погано, якшо самі тої болі не відчуваєте. Звісно багато кодити не вийде. Але покоджувати періодично в різних командах то є дуже зручно. Знову ж інші сприймаютьвас тоді як людину, а не як того хто в барабан бє, а сам не гребе. Та воно так насправді і є.

От є ще така думка ithare.com/...​ive-to-coding-architects але до того стану рости й рости. Суть, що кодить як основна робота — набридло. Та й віддача маленька — раз на кілька місяців вкладаєшся в архітектурні рішення, далі — чекаєш, що з того буде.

Суть, що кодить як основна робота — набридло. Та й віддача маленька — раз на кілька місяців вкладаєшся в архітектурні рішення, далі — чекаєш, що з того буде.

Крєпітєсь сударь :). В мене все життя таке :). Може просто ви того.... троха замучилися і вигоріли? Може треба трошки віддихнути? А може довго працювали з говнокодом і того від коду верне? То все проходяще. Чекайте моменту коли знову захочеться покодати самому ібо то є процес созіданія і від нього можна дуже кайфувати. Я недавно тетріс накодив бо кодити хотів. Мамі подарив на день матері. (Звісно чисто некомерційно. Тетріс не можна продавати чи виставляти в безкоштовний юзедж ібо копірайт і ТМ)

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

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

Нікак ніт. Якшо гадюшник (а таке дійсно інколи трапляється) то краще ні з ким не сваритися, а піти і не тратити часу.

PS. Дуже-дуже добре коли першочерговий клієнт (замовник) довіряє команді в якій вам доведеться працювати. Якшо в нього є свої команди то дуже важно шоб вони були кваліфікованими і не сприймали команду в Україні як конкурента. Якшо в нього є архітектор який координує команду в Україні то критично важливо шоб з ним можна було спілкуватися на пряму і шоб він був адекватний технічно і не впертий як баран.

dou.ua/forums/topic/28077

За лінку окреме спасибі. Я такого не читав. Я только учусь :). Зацікавило.

Я теж випадково знайшов і дуже здивувався. Зрозумів, звідки беруться оті усі патерни на розумних сайтах.

Для меня Java с одной стороны и есть самым большим злом. С 40% распространения и как самый майнстримный язык, Java как раз и диктует єту утопическую догму — что все есть обьет и точка. За ними подтягиваются дот нетчики и всякая прочая ООПишная мишура. С другой стороны с выходом Java-8 редакции когда наконец вдохнули в язык ФП парадигму — делает єтот язык вполне годным. Проблема осталась в миллионах девов, вернее в их мышлении, для них до сих пор присвоение функции переменной является взрывом мозга єтакий ментальный предел. Конечно они стали немного продвинутей и вместо for-loop теперь используют stream.forEach, но при єтом мутируют какую нибудь коллекцию за пределами єтой итерации.

Вы может подумаете что я просто очередной нувориша на модной волне покритиковать невинную овечку и заработать себе в карму, но нет моя критика не на пустом месте. Для начала я в взял и переписал на Java догму «четырех пердунов» под названием ООП паттерны, єто было довольно приятным занятием под пиво, я переписал все кроме тех патернов где нужен стєйт, там надо немного еще нужно подумать. Работу я запулил в местную сеть где 10к других девов (включая создателя самой Java) имели возможность ознакомиться, пока я не получил ни одной контр критики моей работы. Дальше, весь девелопмент на Java я стараюсь вести в ФП ну или по крайней мере в гибридной форме с большим уклоном на ФП. Результат очень проминентный, так же стараюсь пушить всех девов вокруг меня на смену их мышления но тут трудновато, народ не хочет покидать свой sweet spot: сеттеры, мутация, обьеты бины везде даже для 2-3 string переменных, миксование данных и логики, иерархия на пустом месте шоб було во общем весь коктейль самого плохого что в ООП только может быть.

Поєтому сморю я на єтот топик и просто улыбаюсь — если бы єто была единственная проблема отличить абстрактный класс от интерфейса :)

Конечно они стали немного продвинутей и вместо for-loop теперь используют stream.forEach,

И тем добавили тормозов. Лучше бы for оставили.

ФП хорошо там, где его хорошо оптимизирует, или где скорость некритична.

Да, на собеседованиях зачастую гоняют по теории, а программа с опытом чистый практик.

Собеседовния бывают очень разные.
И сами задаваемые вопросы, не так важны, как цель, с который их задают.
Нарпимер, если собеседование в стиле «угадай, какой ответ считает правильным собеседующий», то вопросы вообще не важны :)

В своё время проводил множество интервью. Вопрос, может и поднадоевший, но здорово выручает, если интервью начать прямо с него. Если человек не может на него внятно ответить — это отличный детектор, интервью можно сразу плавно и деликатно завершать.

в ц++ нет интерфейсов ))

смотря как начал.

с джавой както все подзабыли, что интерфейс это вообще оригинальный паттерн...

даже если у функции есть дефолтная имплементация

я ж не спорю. просто еще один аргумент к гибкости плюсов

Інтерфейс — декларація функціональних можливостей об’єкта.
Абстрактний клас — декларація базової структури об’єкта.
Між ними різниці майже немає. Все залежить від конкретної реалізації в мовах програмування.

Між ними різниці майже немає.

:D

Повністю погоджуюся з запропонованими визначеннями, але не з твердженням що різниці майже нема. Якщо ООП використовувати тільки для поліморфізму то тоді і справді різниці мало, а ООП тоді стає злом. Але якщо ми робимо адекватний ОО дизайн, то різниця між поведінкою і структурою є конче важливою.

Останніх декілька років програмую на TypeScript, то у ньому чітко розрізняється призначення між інтерфейсом й абстрактним класом (це якщо порівнювати, наприклад, з PHP). Інтерфейс незрівнянно частіше застосовується на практиці, ніж абстрактний клас.

Зверніть увагу на:
1. смисл ключових слів для інтерфейсу й абстрактного класу (implements, extends);
2. особливість використання модифікаторів доступу (private, protected, public).

Інтерфейси — імплементуються, абстрактні класи — розширюються, причому інтерфейси не мають сенсу з модифікаторами доступу private й protected (лише public).

Тобто, інтерфейси призначаються для «публічного» узгодження по типам даним й сигнатурі методів, тоді як абстрактні класи являють собою найбільш базову форму класу, призначену для розширення, де, окрім типів даних, може закладатись й поведінка методів.

В абстрактному класі модифікатори доступу private й protected можуть використовуватись саме через те, що в ньому вже закладено базову частину функціональності, яку можна повторно використовувати в дочірніх класах.

Якщо у вашому абстрактному класі усі члени публічні й не закладено жодної поведінки у методах — вам потрібен інтерфейс.

TypeScript, то у ньому чітко розрізняється призначення між інтерфейсом й абстрактним класом (це якщо порівнювати, наприклад, з PHP)
любопытства ради, можете аргументировано объяснить, почему, с Вашей точки зрения, в PHP это разделение не такое ясное как TypeScript? вот лично с моей колокольни они идентичны. ну разве что за исключением возможности в TypeScript объявлять поля на уровне интерфейса, что как по мне, наоборот еще больше создает путаницу

Усе просто: PHP — динамічно типізована мова програмування, тоді як TypeScript має статичну типізацію.

У TypeScript дуже часто використовуються інтерфейси, бо вони описують саме типи даних. А коли ближче працюєш з типами даних, то й чіткіше стає зрозуміло для чого це взагалі потрібно.

динамічно типізована мова програмування, тоді як TypeScript має статичну типізацію.
объясните как это влияет на понимание сущностей «абстрактный класс» и «интерфейс». как по мне статическая типизация в реальности ничем не помогает в понимании.
У TypeScript дуже часто використовуються інтерфейси, бо вони описують саме типи даних. А коли ближче працюєш з типами даних, то й чіткіше стає зрозуміло для чого це взагалі потрібно
а вот это однозначный минус для понимания. в TypeScript интерфейс часто служит тем что в других языках называют структурами. соотвественно ввиду того что одна сущность может исполнять две роли то однозначно потребуется больше когнитивных усилий. и еще больше схожести с абстрактным классом чем в PHP
объясните как это влияет на понимание сущностей «абстрактный класс» и «интерфейс». как по мне статическая типизация в реальности ничем не помогает в понимании.

Статична типізація в TypeScript передбачає явне вказування типу даних, на відміну від динамічної типізації в PHP. Що це за собою тягне? — Частіше фокусування уваги на типах даних і на їх відмінностях.

Грубо кажучи, через місяць-другий роботи на TypeScript, коли тобі приходиться писати інтерфейси значно частіше, ніж класи, в тебе вже вимальовується чітке розуміння «що таке інтерфейс», чому в інтерфейсі не можна писати тіла методів, і чому в інтерфейсі використовуються виключно публічні модифікатори доступу.

Ще одне доповнення до вищезазначеного мого опису відмінностей: інтерфейс — це «обрізана версія» абстрактного класу. Не пам’ятаю як в PHP, але в TypeScript ви можете позначати тип даних конкретної змінної через абстрактний клас, точно так само як це ви робите за допомогою інтерфейса.

Грубо кажучи, через місяць-другий роботи на TypeScript, коли тобі приходиться писати інтерфейси значно частіше, ніж класи, в тебе вже вимальовується чітке розуміння «що таке інтерфейс», чому в інтерфейсі не можна писати тіла методів, і чому в інтерфейсі використовуються виключно публічні модифікатори доступу.

я вот смотрю на ребят которые у меня в проекте уже около года педалят на тайпскрипте — и им это никак не помогло.

Ще одне доповнення до вищезазначеного мого опису відмінностей: інтерфейс — це «обрізана версія» абстрактного класу.

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

В абстрактному класі модифікатори доступу private й protected можуть використовуватись саме через те, що в ньому вже закладено базову частину функціональності, яку можна повторно використовувати в дочірніх класах.

Мда... не пам’ятаю що наштовхнуло мене на таку думку, але це твердження невірне. Обмеження по використанню модифікаторів доступу в інтерфейсі продиктоване архітектурним призначенням цього самого інтерфейсу.

Інтерфейс зобов’язаний гарантувати публічність доступу до будь-якого члену класу, що його імплементує. Це один з його головних «обов’язків». Абстрактний клас не завжди дає таку гарантію, хоча його теж можна використовувати в якості інтерфейса.

Ну прямо таки бином Ньютона. Интерфейс — определяет интерфейс, а абстрактный класс, соответственно, абстрактный класс.

Интерфейс можно рассматривать как абстрактный класс, все методы которого также абстрактны

как абстрактный класс, все методы которого
А конструктор/деструктор/прочие? #trollface

Не только лишь абстрактны, но еще и публичны.

Опытного человека вопросом в тупик не поставишь

Начиная с Java 8 этот вопрос действительно может напрячь

Не может, интерфейсов все также может быть несколько, а абстрактный класс один, в определении extends.

я бы сказал, что интерфейс — это, то что обект показывет наружу (публичные методы и свойства). А абстрактный класс — это сущность предназначенная для наследования. В принципе это две разные концепции. Абстрактный класс будучи сущностью для наследования принуждает наследников наследовать его интефейс. Как-то так.

Я бы ответил следующее:
Абстрактный класс и интерфейс, являются способами/механизмами реализации в языке программирования такой концепции ООП как Абстракция. И ключевая разница между ними в том, что интерфейс дает — 100% абстракцию, в то время как абстрактный класс позволяет контролировать ее степень 0-100%
Ну а дальше, при желании, можно углубиться в конкретные отличия между данными сущностями (в зависимости от языка программирования).

Если правильно помню, то в контексте например, PHP в интерфейсе нет свойств и не определены методы. Всё перекладывается на наследников. А абстрактные классы уже могут реализовывать методы. От интерфейсов так же можно организовать множественное наследование.

На C++ интерфейсов вообще нет, там при множественном наследовании можно влипнуть в проблему ромба.

А на JS вообще остается только втыкать на prototype.

Может что-то напутал, потому что именно:

На работе занимаешься чем угодно, кроме сравнивания абстрактных классов с интерфейсами

Да и вообще стоит 2 раза подумать, стоит ли пытаться устраиваться на работу туда, где до сих пор на собеседованиях грузят подобными вопросами

На «плюсах» интерфейсы есть. Декларируются абстрактными классами, с лишь чиста-виртуальными функциями. :)

«Ромбы» разрешаются «виртуальными базовыми классами» — но до «ромбов» её нужно додизайнить.

Промахнулся веткой. Но тут ценный коммент ниже, не стоит удалять :D

Композишн везде модно, уже лет 10 как (если не больше). А наследование классов — для лузеров. :)

А на JS вообще остается только втыкать на prototype.
:D
Не зря я свчинулся с шарпа, хоть не буду такие вопросы на собеседованиях слышать)))

Но вообще в js новомодно сейчас не париться с наследованием, а делать composition через Object.assign()

Приветствую.

Если мы говорим о .NET / Java, то:

  1. Концептуально:
    • Интерфейс — описание котнракта взаимодействия c объектом, реализующим данный интерфейс
    • Абстрактный класс — непосредственно описание типа, которое влючает в себя не только контракт взаимодействия, а ещё и имплементацию некоторых методов. Но тем неменее не может быть инстаниирован. Так как описывает некий базовый контракт, для всех потомков данного абстрактного типа
    Я для себя принял такой подход: предметы реальности — это классы. Наборы их свойств и методов, которые можно логически объеденить в группы — интерфейсы.Опять же стоит создавать интерфейсы, только если тебе действительно надо обращаться к набору объектов разрозненных типов, по некому единому контракту. Т.е. создавать сущности по потребности, а не плодить тонны интерфесов, которые никогда не будут использованы и только усложнят процесс разработки
  2. Физически: ты не можешь унаследовать (покрайней мере в языках где нет множественного наследования) некий производный класс от нескольких других. Только один предок ! Однако, он может реализовывать несколько интерфейсов.
Пример:
Есть абстракнтный класс предметов физической реальности: часы, описывающий всевозможные предметы, которые показывают время (песочные, механические, электронные, атомные и т.д.) Значит делаем интерфейс IClock, описывающий как мы с этими часами можем взаимодействовать.
interface IClock
{
   DateTime CurrentTime {get; set;}
}
Интерфейс, можно и не делать, если мы не собираемся делать несколько сборок, которые будут делать свою ветку имплементации часов. Например у нас может быть под каждую платформу своя имплементация и в данном случае удобно выделить интерфейсы и выделить их в отдельную сборку, которую потом референсить в сборке с конкртеной имплементацией.

Далее,

abstract class Clock : IClock
{
  // Implement base clock logic. Base for all inheritors
}

Затем у нас есть конкретные часы, без будильника — механические.
Делаем:

class MechanicalClock : Clock
{
  // Extend / replace base clock logic with mechanical specific
}

Но у некоторых часов помимо самих часов, есть так же будильник, там смена мелодии и прочие штуки, соответственно делаем соответствующие интерфейсы: IAlarm, ...

Так же есть класс часов с будильником:

abstract class AlarmClock: Clock, IAlarm 
{
 // Alarm related logic
}

И электронных часоів с будильником:

class ElectronicClock : AlarmClock
{
  // 
}

Иногда, данный подход начинает порождать монстуозные иерархии, поэтому я придерживаюсь подхода, делать основую иерархию через наследование, а feature related через паттерн Strategy, т.е. сделать:

class AlarmStrategy: IAlarm
{
  // Implement all base alarm related logic
}
и
class ElectronicalClock : Clock, IAlarm
{
  private IAlarm alarmStrategy;
  public ElectronicalClock(IAlarm alarmStrategy)
  {
    this.alarmStrategy = alarmStrategy;
  }
  // Electronical clock related logic
}

Как то так

Да не согласен я! — Что, с Энгельсом или с Каутским? — С обоими! ©

А с чем согласен ? Интересно послушать...

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

Ок. А как бы ты сам изложил ?
P.S. Ну и как бы я не на интервью, попытался развёрнуто объяснить человеку что к чему, если что...

Да там человек как бы и так понимает , по крайней мере так он говорит в теме:)
А я тоже уже озвучивал.
По разному я описывал , когда меня этот вопрос спрашивали.
На последнем интервью , где меня его спросили я ответил так:
Абстрактный класс, отвечает на вопрос «кто я?»
Интерфейс на вопрос «что я делаю?»
Парнишка закивал и дополнительно по этому вопросу больше не спрашивал.
Оффер они мне так и не дали :)))

Да там человек как бы и так понимает , по крайней мере так он говорит в теме:)
Насколько я понял — он таки не знает, чем они отличаются, поэтому собственно и создал этот топик :) Или он чисто из любопытства ? :)
Абстрактный класс, отвечает на вопрос «кто я?»
Интерфейс на вопрос «что я делаю?»
Да, мне нравится, ёмкий ответ, при своей краткости. Спасибо.

Есть вопросы поинтересней. Типа в чем отличие статического класса от синглтона? :)

Это смотря для какого языка. В джаве например static class — немного о друшом, и много народу не знает.

Статический класс это класс иннициализирующийся сразу при запуске, а синглтон это паттерн позволяющий иметь не более одного обьекта?

Difference between Static class and Singleton Pattern:

— In c# a static class cannot implement an interface. When a single instance class needs to implement an interface for some business reason or IoC purposes, you can use the Singleton pattern without a static class.
— You can clone the object of Singleton but, you can not clone the static class object
— Singleton object stores in Heap but, static object stores in stack
— A singleton can be initialized lazily or asynchronously while a static class is generally initialized when it is first loaded

>в чем отличие статического класса от синглтона? :)

И то, и другое — плохо. Но синглтон хуже.

Спорно. Все зависит от задачи, к-я решается.

Нет таких задач/решений, где бы синглтон имел преимущество перед инстансом обычного (не синглтона) класса.

Если на данный момент у синглтона преимущество — это значит лишь то, что придётся намного больше времени и тpуда потратитъ на выковыривание синглтона из кода, позднее.

Если лепить синглтоны, не думая, то конечно потом будет потрачено время на выковыривание. Просто пример, IOC container, scope, unit tests. Или Вы предпочитаете руками писать синглтоны/не синглтоны, реализуя тем самым то, что уже придумано давно, т.е. велосипед(в народе)?

Никто не вынуждает делать IOC container синглтоном. И ни к чему хорошему, такое делание не приведёт.

Хорошо, тогда приведите аргументы против стнглтона. «Выковыривать из кода» не в счет.

Одна лишь его «глобальность» означает, что он собой загадит весь код.

Причём, в отличии от абстрактного класса — у него (как правило), ещё и есть состояние.

Хранить состояние можно, но осторожно, иначе возникает задача синхронизации.
Вы путаете муху и слона, сравнивая класс и инстанс класса. Граната в руках у обезьяны — очень серьёзное оружие.
Тема ушла в другое русло. Основное отличие — это возможность подменять реализацию, что в случае со статическим классом невозможно.

Вы путаете муху и слона, сравнивая класс и инстанс класса.

Это не путание. Как вы верно заметили, наличие состояния — добавляет ещё кучу головной боли (не только синхронизацию).

У абстрактного класса этой головной боли нет. Но у синглтона (вдобавок, к его глобальности) есть.

Потому и пишу:

И то, и другое — плохо. Но синглтон хуже.

Смешались в кучу кони, люди... При чем здесь абстрактный класс, если речь идёт о статическом классе?

о статическом классе

да, пардон... это я зарапортовался :)

А по поводу состояния, так есть куча статей, в том числе на SO, в к-х описывается, что статические классы с их методами не гарантиют безопасности при работе в мультипоточной системе и требуют также наличие механизмов синхронизации.

Почти любой класс при работе в мультипоточной системе ничего не гарантирует.

Процитирую классиков

Don’t confuse the SINGLETON lifestyle (DI) with the Singleton design
pattern.

Use the SINGLETON lifestyle whenever it’s possible.

Красиво классик написал. А нет там нигде рядом описания как IOC container менеджит инстансы классов, к-е регистрируются с указанием scop-a жизни как singleton? Не задумывались?

Нет таких задач/решений, где бы синглтон имел преимущество перед инстансом обычного (не синглтона) класса.

Из последнего примера, для блжад скалы где фп и прочее: из спарк воркера надо дернуть БД.
Контекст выполнения на воркере тупая засеарилизированая лямбда, в которую ничего никак впринципе не заинджектить. Другое дело что в скалу синглтон в сам язык встроен.

Я всегда на этот вопрос отвечал, что абстрактный класс — это класс, в котором есть хотя-бы 1 абстрактный метод. А интерфейс, в отличии от класса, не предполагает реализации, а определяет поведение. Может это неправильное определение, но пока никто не поправил)

Забавно было когда меня на позицию C# trainee чувак с GL спросил: «а какой текст warning-a будет, если мы унаследуемся от абстрактного класса с виртуальным методом из dll-ки, не переопределив этот метод?». А перед этим он мне сказал: «если ты чето неправильно ответишь, то я тебя поправлять не буду, т.к. у меня нет на это времени. И вообще если в какой-то момент мне чето не понравится, собеседование закончится». Забавный чувак, я его запомнил =)

Может это неправильное определение, но пока никто не поправил)
Интерфейс это контракт

Абстрактный класс это контракт и/или реализация

Тут тоненько) Смотря как трактовать слово «предполагает». Если ближе к «(не)требует» — то да, можно придираться. Если ближе к «(не)возможно наличие» — то никакого несоответствия.

Я всегда на этот вопрос отвечал, что абстрактный класс — это класс, в котором есть хотя-бы 1 абстрактный метод. А интерфейс, в отличии от класса, не предполагает реализации, а определяет поведение. Может это неправильное определение, но пока никто не поправил)
не каждый абстрактный класс содержит абстрактные методы => твой ответ неверный

Я в курсе, хоть и давно не .Net-чик. Может быть и абстрактное свойство, или вообще их не быть. Но факт остается фактом, никто меня не исправлял и не просил уточнить как автора темы. Тем более если захотеть, можно прикопаться к любому определению.

Можно не относиться к собеседованию, как к экзамену в школе. И при встрече с любым сложным вопросом помнить, что главное в ответе — показать умение спокойно встречать сложные вопросы.
Всего не знает никто. На любой вопрос есть несколько разных ответов.
А если собеседующему важно не увидеть способность собеседуемого встречать трудности, а подчеркнуть чужое незнание, чтобы потешить себя или уменьшить оффер, то можно порадоваться, что такая особенность собеседующего выяснилась заблаговременно, а не после трудоустройства.
Интерфейс — не более чем обязательство. Абстрактный класс — обязательство, возможно несколько, возможно с частичной реализацией, заготовка.

Работать и проходить собеседования — два разных занятия, требующих 2х разных, обычно не пересекающихся, наборов скилов.

Внимание вопрос: «Зачем же ..ахать человеку мозг на собеседовании вопросами из множества, к-е не является подмножеством искомого множества»? ;)

1) Срезать зарплату
2) Пристыдить и косвенно заставить человека в своё свободное время повышать квалификацию в ускоренном темпе
3) Снизить требования к рабочему месту со стороны работника и число вопросов
4) Посмотреть на стрессоустойчивость, эго, агрессивность/защита/согласие, как вольётся в коллектив

Ну и т.д. Т.е. можно сознательно спрашивать разный бред, делая вид что ты на полном серъёзе. Важен результат, а не процесс. Если для результата нужно сказать две противоречащие друг-другу фразы, то так оно и будет сделано.

Частая проблема технаря в том, что он/мы/вы оперирует непосредственно информацией, слишком быстро «ныряет» и начинает разбор за содержание, логику, и упускает тот факт, что иногда значение слов могут быть не важны, что в данную минуту смотрят на его эмоциональный отклик или просто манипулируют удобными темами, подводя к чему-то. Особенно это заметно при общении с девушками т.к. они по природе более социализированы и свободно владеют скиллами общения.

1) Срезать зарплату
3) Снизить требования к рабочему месту со стороны работника
Так тупые вопросы обычно задают разработчики. Им же без разницы по сути какая у вас будет зарплата.

Это из-за узкой специализации/мышления. Потому они и разработчики, а не начальники. Начальнику или даже рядовому менеджеру важен продукт, практическое применение, а вот разработчик получает информацию ради самой информации, и не понимает что потом дальше с его кодом будет. Он думает что код это и есть продукт и его нужно улучшать. И ценность информации он определяет по сложности её изучения, а не по практической пользе для продукта. Лягушка в колодце.

Чето у вас все слишком сложно)

Тут ниже уже кто-то мыслю задвинул, что народ просто не знает че спрашивать и потому спрашивает фигню всякую, которую у них кто-то раньше спрашивал или что первое в голову взбрело. При том, что прохождение собеседований это реально meta-skill, но и проводить собеседования это такой-же meta-skill, который нужно тренировать. А народ иногда так боится, что даже сами не могут собеседовать, а берут коллегу в напарники, даже если этот коллега за 40 минут собеседования не проронит ни слова))

Вполне возможно. Мы объединили всех собеседователей в одно «нечто» — это какой-то самообман в попытке упростить для себя представление мира, снизив нагрузку для мышления. Это так же, как и делить людей на типы. В реальности же, два человека могут задать один и тот же вопрос, но из разных мотивов. Так что ответа на вопрос не существует т.к. сам вопрос не имеет никакого смысла.

Мы объединили всех собеседователей в одно «нечто»
Не совсем. Мы же тут про касту любителей тупых вопросов. По моему впечатлению, их не так много. В большем количестве мне попадались приятные люди. Редко они были просто запаренные и им было не до меня(особенно среди всяких CTO), а иногда бывали даже веселые. Неадекватов мне попадалось не так много, но они были яркие)
Им же без разницы по сути какая у вас будет зарплата.
Но их могут вы№%ть, если новый член комманды не будет соотвествовать ожиданиям. Потому для разработчиков, которые проводят собеседование, лучше отказать 100 подходящим кандидатам, чем взять одного неподходящего.

так вони є. просто не працюють. :)

В частности для С++ он бессмыслен.

Ага. І саме тому Греді Буч написав «Объектно-ориентированный анализ и проектирование
с примерами приложений на С++» www.helloworld.ru/...​/comp/other/oop/index.htm і там розпинається і про інтерфейси і про абстрактні класи :) www.helloworld.ru/...​s/comp/other/oop/ch03.htm

Як на мене то в С++ сильно понівечили інтерфейси. Якшо мені не зраджує память, то в старому С(без плюсів) в хедерному файлі якраз і був чистий інтерфейс, а в плюсах туди внутрішню структуру класу приплели (хоч і з приватними модифікаторами). Тим не менше, якшо в мові нема спеціального зарезервованого слова для інтерфейсів, то це ще не значить що нема інтерфейсів. Враховуючи множинне наслідування в С++ з рівними руками можна робити чуда-дива: і інтерфейси, і класи, і готові біхейвори статично навішувати (щось схоже на трейти в Скалі, чи інтерфейси з дефолтними методами в Джаві)

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

Я ответил, что абстрактные классы использовал в основном в Java, а в Scala в основном Traits. Это не ответ, но возможное начало. Сейчас посмотрел — в двух проектах вообще нету абстрактных классов, в другом их в 10 раз меньше чем Traits. Я бы дальше мог подумать и назвать отличия, множественность и параметры точно. Но интервьюер сразу заявил, что они отличаются тем что в одних есть параметры, в других нету. Это ответ неполный и неточный — jiaminglin.gitbooks.io/…​t_and_abstract_class.html

Мне не понравилось, что он этим мог подразумевать, что я не могу ответить. Еще он сначала сказал, что не читал резюме, не взял список вопросов, но что-то поспрашивает, и что у него мало времени, потому что будет следующее собеседование по скайпу, постоянно доставал и смотрел время на телефоне и зачем-то принес вместе с моим резюме еще огромную пачку (других резюме?)

Я сказал, что параметры собираются добавить в виде docs.scala-lang.org/…​ing/trait-parameters.html, на замену текущих early definition (аналогичная фича, которая считается advanced ) чтобы намекнуть, что я вообще знаю и не только базовые вещи. На что он сказал, что мы говорим про то, что сейчас, а не то что будет и перешел к следующему вопросу. Дело не в том, что я не мог бы ответить вообще, а в том что интервьюер ждал сразу готового ответа, спешил и не слушал.

Но интервьюер сразу заявил, что они отличаются тем что в одних есть параметры, в других нету.
Я бы сам не ответил на этот вопрос, но про параметры — это ересь. Имхо (мой опыт из PHP), основная разница в назначении. Интерфейс это просто описание правил. Если класс имплементит интерфейс, то он точно будет иметь методы, описанные в интерфейсе. А абстрактный класс это заготовка, «полуфабрикат», где часть функций реализована, а часть должна быть реализована тем кто от него наследуется. И на практике можно не использовать ни то, ни другое. Зависит от проекта, фреймворка и программиста.

Когда вас спрашивают то сам ответ показывает уровень осознанности в использовании технологии.

Відповідь в SOLID, і не залежить від мови. Візьмемо для прикладу смартфон. Клас «Смартфон» імплементує інтерфейси (властивості смартфона) «дзвонити» і «фотографувати». Таким чином встановлюється протокол спілкування з іншими класами (фотограф або людина якій треба подзвонити). Фотографу потрібен фотоапарат, і йому не важливі інші функції, фотограф користується лише інтерфейсом «фотографувати». В той же час абстрактний клас це модель конкретного телефона — тобто сукупність всіх інтерфейсів, які імплементує клас, а також можливо реалізація якихось спільних функцій.

В go нет абстрактных классов, поэтому вопрос лишен смысла.

поэтому вопрос лишен смысла.
і як go
поэтому вопрос лишен смысла.
як і go
поэтому вопрос лишен смысла.
go і як

Ну хоть не люки в городе считать..

Это в каком яп? Если джава то ответ кагбы очевиден.

На работе занимаешься чем угодно, кроме сравнивания абстрактных классов с интерфейсами :(
Вы там что иксемели редактируете ? В джаве и интерфейс и абстрактный класс встречаються повсеместно как и различные паттерны с их применением.

вообще про Scala и Traits, но ее мало кто знает, а вопрос явно передерт с джавовского, хотя ответ отличается.
у вас нету никаких навыков, которые вы автоматически делаете, но не можете сходу объяснить?

вообще про Scala и Traits, но ее мало кто знает
Та тут как раз народ в курсе)
Ток не очень понятно причем тут анонимные классы к скала.

Со скалой действительно менее очевидно, поскольку в треитах можно реализацию пихать, и на уровне либ различия очень редко используется.

В восьмой жабе тоже

Вот неплохой обзор stackoverflow.com/…​classes-instead-of-traits

Как видно, ничего неожиданного в ответах нет: параметры, наследование 1 класса против множества трейтов, интероперабельность с джавой.

В свежей скале 2.12.2 интероперабельность пошла дальше и трейт с реализацией компилится как Java интерфейс с реализацией

Самый топ когда тебя спрашивают: «Как вы себе представляете следующие 5 лет» на английском, а я даже на русском не знаю ответ на этот вопрос.

Дык, «i don’t know» — никто не отменял. :)

— fifty-fifty
— what do you mean?
— or sixty-thirty then

Самый топ когда на короткий вопрос ожидают длинный развёрнутый ответ.

Эти длинные монологи уместны где-нибудь на последнем звонке в школе, которую закончил много лет назад.

Может нужно ходить регулярно на собеседования для поддержания формы?

Конечно нужно. Для поддержания себя в форме, выработки скила проходить собеседования и понимания того, что вообще на рынке происходит.

Плюс как перестраховка, если резко уволят)

На последнем интервью, где меня спросили этот вопрос, ответил, что АК отвечаете вопрос «Кто я?», а И на вопрос «что я делаю?».
До сих пор думаю , почему меня не взяли , может им этот ответ не понравился.

скорее общее формулирование мыслей :D

я три раза перечитал этот твой коммент, прежде чем понял чуть сказанного.

я обычно смотрю , если лицо не обезображено интеллектом, я говорю короткими предложениями, дабы однозначно быть истолкованным.
А уж на английском, я только короткими и говорю:) но тут уже по другой причине.

Попробуйте применить абстрактный класс как маркер. Надеюсь вас это подтолкнет к ответу на вопрос ;)

Ну да, нет множественных супертипов в ряде языков :) И для маркера не нужен функционал классов. То есть, чтобы ответить на вопрос нужно попробовать сделать еще одно абсурдное действие :)

Скорее несколько. Меня на собесах спрошали: чем руководствовались создатели языка, когда это писали. Хороший вопрос если есть возможность пораскинуть мозгами ;) теория теории теории — наше все.:)

чем руководствовались создатели языка, когда это писали

О! Это хорошие вопросы.

Всё просто. Интерфейс это хорошо, а абстрактный класс — плохо.

Хотя, если это абстрактный класс в C++ и только в дебаг версии — тоже может быть хорошо.
Или если это в Java/C# и класс (со всеми потомками) вписываются в «SRP» — тоже может быть неплохо.

Мне кажется, вы пропустили, чем вы замените использование абстрактного класса. Делегирование например. Вопрос, что лучше, в каких случаях, что применять и почему, как-то практичнее выглядит, чем «в чем разница».

А разве вопрос был , чем заменить?
Вопрос же был , в чем различие ?

тогда И — хорошо и АК — плохо, точно не ответ на этот вопрос. Или ответ, который еще расшифровать нужно.

Так то и с ответом что один хорошо , а второй плохо я тоже не согласный :) точнее попросил бы пояснения почему.

Самая простая замена — композиция. Можно также, попользовать статический полиморфизм.

Впрочем, как написал выше, если класс (с потомками) удовлетворяют «Single responsibility principle» — может прокатить и абстрактный класс (хоть это будет и хуже композиции, во многих смыслах).

Тогда был джуном
Сейчас
Вопрос ставит в ступор
Видимо джуном и остались ))

а по-моему дно пробито, если такие вопросы поднимаются на доу...

А меня ответы некоторых людей поражают :)
Сразу видно глубокое понимание основных концепций ООП.
Как по мне то «джуном» сразу можно ли аметист , по тому, что на такой вопрос они достают свой мешок с терминами котрый где то слышали и весь его высыпают в уши слушателей и там и интерфейсы маркеры и дженерики и полиморфизм, сука, не к ночи будет упомянут.

Можно пойти по нестандартному пути.
Например, вопрос «можно ли наследовать абстрактный класс от неабстрактного» многих вводит в ступор ))

Отличный вопрос, дабы послушать рассуждения будущего коллеги :)

Джуны как правило отвечают на этот вопрос без проблем
Если подобный вопрос задается на senior позицию, то это маркер, что в эту контору идти не нужно

Структура и класс. Есть типаж интервьюеров, который прется от подобных вопросов.

Если человек правильно применял и то и другое на практике, то ответит он походя, не задумываясь.

То есть вы допускаете, что я их неправильно применял? Подскажите как именно их можно неправильно использовать, может нужно исправляться? :)

Не использовать общие интерфейсы (кстати встречался с таким) вообще, не знать про всякие Sortable, Serizalizable etc? Писать abstract class вместо interface (не использовать абстрактных классов с параметрами конструктора, полями, реализованными и абстрактными методами) и не использовать более одного родительского типа? Пока все мимо.

Даже Вики вам скажет «Абстрактные классы представляют собой наиболее общие абстракции, то есть имеющие наибольший объём и наименьшее содержание.».
На практике часто туда попадает дублирующая функциональность, характерная для всех ваших реализаций интерфейса, тогда как сам такой класс не несёт в себе никакого практического смысла (может, кроме юнит-тестов в каких-то случаях).

Но не в Скала обычно. Абстрактные классы использовал в основном в Java, а в Scala в основном Traits. В двух проектах вообще нету абстрактных классов, в другом их в 10 раз меньше чем Traits. Traits как раз реализуют делегирование и сборку из кирпичиков.

Если честно, то наверное ни разу за всю мою практику не было потребности реально использовать абстрактный класс, точнее сказать обоснованного использования, но я и не работал над библиотеками или фреймворками

Підписатись на коментарі