Здравствуйте, nightcode, Вы писали:

N>ага, такая непринципиальная мелочь и то что класс может реализовывать несколько интерфейсов, но наследовать может только один класс это тоже непринципиальная фигня
Это дополнение c#(конкретная реализация), но не абстрактного класса или интерфейсов.

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

    interface IC
    {
        void GetVal();
    }

.class interface private abstract auto ansi SomeNewApp.IC
{
} // end of class SomeNewApp.IC

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


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

Здравствуйте, cocacola, Вы писали:

C>Часто читал что мол позор на фирмах, никто не знает чем абстрактный класс от интерфейса отличается.
C>У нас 100% такого нет, реально много гиков. Причем зп средняя довольно по городу.

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

Здравствуйте, 0x8000FFFF, Вы писали:

FFF>По заслугам... Выставление уровня по времени считаю бредятиной...

По каким еще заслугам? Вот пришел новый человек в команду и нету у него еще никаких заслуг, а иботеки и кредиты есть. Или ему каждый раз начинать с джунской зарплаты чтобы доказать что он не лось?

Здравствуйте, Grizzli, Вы писали:

G>Здравствуйте, cocacola, Вы писали:

C>>Часто читал что мол позор на фирмах, никто не знает чем абстрактный класс от интерфейса отличается.
C>>У нас 100% такого нет, реально много гиков. Причем зп средняя довольно по городу.

G>Значит повезло с текущим местом работы вам. набирайтесь опыта, а потом идите в фирму, где гиков нет — будете там сеньером, или тимом.

И как он будет решать проблемы? Если заказчики озвучивают свои проблемы не в виде списка классов на C#, а на уровне запретите посетителям делать скриншоты нашего сайта.

Здравствуйте, cocacola, Вы писали:

> Как у вас с этим на работе? Какой уровень ваших коллег?

А у нас в квартире газ коллеги такие:

* человек заметил, что какой-то тест валится в его конфигурации билда. Он сразу баг мне пишет, мол ты этим кодом занимаешься, ты и разбирайся. Никакой дополнительной информации, как воспроизвести, лог, там можно было бы и покопаться немного если уж наткнулся на баг. Нифига. И вроде в одной команде работаем, над одним кодом.
* есть допустим какая-то нетривиальная проблема, которую нашли люди из другой группы, использующие наш код. Баг создан, repro есть, всё такое. Несколько человек из нашей группы сразу начинают предлагать решения — "а может это то, или может это?". Ни один из них даже не попробовал воспроизвести баг, под отладчиком прогнать. Лишь бы что-нибудь пёрнуть в баге, чтобы все видели, какие они умные. Когда начнёшь изучать проблему, причина оказывается, конечно, совершенно в другом.
* если пытаешься помочь человеку с его проблемой, то он вместо того, чтобы сделать то, что ты ему предлагаешь, сразу хочет повесить её на тебя. Инициатива наказуема!
* фичи предлагаются офигенные иногда. И чем дибильнее фича, тем больше человек её стараются поддержать. Причём я почти уверен, что большинство даже не понимает о чём идёт речь. А когда доходит дело до реализации, все почему-то сразу теряют интерес. Но если им сказать, что эта *?:#(%* не будет работать, и вообще такой проблемы нет, которую они хотят решить, то ты сразу главный враг, и ничего совсем не понимаешь в этом деле.
* когда сделаешь большой кусок работы, нужно в порядке вещей, чтобы кто-то сделал code review. Но вместо замечаний по существу получаешь что-то вроде: "вот здесь из одного класса надо сделать два, а здесь из двух — один", запятые и скобочки не на тех строчках поставил и не выравнил параметры функций, подлец! В итоге получается по результатам code review куча работы по переливанию из пустого в порожнее.
* если же наоборот, что стараешься дать коллеге feedback по существу по его коду, то тут начинается цирк с увиливаниями и поиском отговорок, почему так сделать нет никакой возможности.

Вот такие пироги. Всё относительно.

Здравствуйте, uncommon, Вы писали:

U>Вот такие пироги. Всё относительно.

С кем поведёшься — так тебе и надо Может, вам пора менять работу

Здравствуйте, Antidote, Вы писали:

A>Здравствуйте, uncommon, Вы писали:

U>>Вот такие пироги. Всё относительно.

A>С кем поведёшься — так тебе и надо Может, вам пора менять работу

Очень даже может

Здравствуйте, -n1l-, Вы писали:

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