Здравствуйте, -n1l-, Вы писали:
N>Вот давайте не будем да? Мы с вами оба хорошо знаем, что хорошим спецам, действительно хорошим, язык безразличен.
Это верно. Но для хороших спецов нужны хорошие задачи. На Java их много, на C# же таки задач мало. Поэтому хорошие спецы оседают в Java, и вымываются из C#. Как следствие — спецы C# слабее в среднем спецов Java.
Ок, но тогда вы просто обязаны ответить на следующие вопросы.
Какие задачи для java вы считаете хорошими?
Какие по вашему мнению задачи решаются на c# кроме сайтов и десктоп приложений, хотя десктоп это все таки не лафа.
Считаете ли вы, что задачи которые решаются на java на c# сделать невозможно?
Решали ли вы какие-то сложные задачи на c#.
Встречали ли вы тех, кто такие задачи решал?
Здравствуйте, Ромашка, Вы писали:
Р>Здравствуйте, -n1l-, Вы писали: Р>>>Меня всегда этот вопрос в тупик ставил — у абстрактного класса очень мало общего с интерфейсом. N>>Фактически да, но если абстрагироваться до их использования, они очень похожи.
Р>
Р>abstract class A
Р>{
Р> enum B { }
Р>}
Р>
Р>Заметь, сплошная декларация, ни слова о реализации.
В смысле ни слова? А какая разница между:
enum B { } и
enum B {A,B,C}
Здравствуйте, -n1l-, Вы писали:
N>Здравствуйте, namespace, Вы писали:
N>>Если меня спросят, чем отличается абстрактный класс от интерфейса, я тоже пожму плечами и поинтересуюсь у вопрошающего, чем же они отличаются. N>Вы серьезно? Я скажу. В абстрактном классе можно указывать конкретную реализацию. Все.
Не все. Это не полный ответ.
Здравствуйте, samius, Вы писали: S>Не все. Это не полный ответ.
Самое главное отличие, остальное лишь дотошные мелочи и многие из них — следствия главного отличия.
Т.е. то, что абстрактный класс в самом деле — статический класс можно узнать и помнить, но все эти фишки умещаются в первое отличие.
То, что интерфейс — набор сигнатур говорится везде и сразу и это опять же часть первого отличия.
То, что для абстрактного класса можно пользоваться всякими фишками наследования, это тоже относится к первому отличию.
Дополните меня?
Здравствуйте, -n1l-, Вы писали:
N>Здравствуйте, devcoach, Вы писали:
D>>Наконец, в C# действительно средний уровень программистов достаточно низкий. Справедливости ради скажу, что он везде низкий. Но в C# оно особенно низок по сравнению с Java/C/C++. Причина — слишком простые задачи. Очень мало в C# задач, когда нужны реально глубокие знания. Поэтому в этой профессии очень много людей из п.1 — низкоквалифицированных, которые ошибочно считают себя крутыми.
N>Вот давайте не будем да? Мы с вами оба хорошо знаем, что хорошим спецам, действительно хорошим, язык безразличен.
Язык действительно безразличен, но он образует вокруг себя некое сообщество.
Почему-то как только мы перешли от С++ на C# стало намного сложнее найти хороших спецов.
Вроде кандидатов больше, а вот выбирать почти не из чего...
Здравствуйте, -n1l-, Вы писали:
N>Т.е. то, что абстрактный класс в самом деле — статический класс можно узнать и помнить, но все эти фишки умещаются в первое отличие.
Ни разу не статический, а такой, который нельзя инстанцировать.
N>То, что интерфейс — набор сигнатур говорится везде и сразу и это опять же часть первого отличия. N>То, что для абстрактного класса можно пользоваться всякими фишками наследования, это тоже относится к первому отличию. N>Дополните меня?
Самое главное отличие, пожалуй, то, что абстрактный класс жестко задает ветвь наследования, в то время как интерфейс может быть реализован в любых иерархиях. Ну и применительно к C#, интерфейс может поддерживаться и структурами, тогда как абстрактный класс и его производные — однозначно ссылочные типы.
Здравствуйте, cocacola, Вы писали:
C>Есть у нас такие серьозные товарищи, расскажут что под капотом у async\await, генерация классов по XML, Test first, code last approach, и все это они юзают в реальных проектах, ну то есть гики, причем четко отслеживается тенденция что все они на .NET
Вообще все эти фигнюшки не говорят о крутости специалиста. Да, знание всяких нюансов использования языка и библиотек отличает новичка он среднечка, но не более того.
Очень крутой программист от прошаренного мида отличается эффективностью работы, стабильностью кода, а главное — выбором наиболее подходящей для конкретной задачи архитектуры.
Здравствуйте, MxMsk, Вы писали:
N>>То, что интерфейс — набор сигнатур говорится везде и сразу и это опять же часть первого отличия. N>>То, что для абстрактного класса можно пользоваться всякими фишками наследования, это тоже относится к первому отличию. N>>Дополните меня? MM>Самое главное отличие, пожалуй, то, что абстрактный класс жестко задает ветвь наследования, в то время как интерфейс может быть реализован в любых иерархиях. Ну и применительно к C#, интерфейс может поддерживаться и структурами, тогда как абстрактный класс и его производные — однозначно ссылочные типы.
Всегда считал что главное — это наличие состояния. В интерфейсе нет работы с состоянием. Ну и возможность частичной реализации тоже. Хотя для последнего, например, в Java 8 будет новое ключевое слово default, которое позволит частично реализовывать интерфейс.
Здравствуйте, sharpcoder, Вы писали:
S>Очень крутой программист от прошаренного мида отличается эффективностью работы, стабильностью кода, а главное — выбором наиболее подходящей для конкретной задачи архитектуры.
Хахаха, то есть что вы сейчас сказали? Примерно следующее: "Крутой специалист круто потому, что он принимает правильные решения". А вы не хотите задуматься, за счет чего он принимает правильные решения? Совершенно верно — благодаря знанию базовых вещей. Например, как можно принять правильное решение какой XML парсер использовать, если человек не понимает в чем разница между DOM и стриминговыми парсерами? Да никак, он не сможет принять такое решение. Или что выбрать — блокирующее или неблокирующее IO? Или что выбрать под конкретную задачу — ArrayList или LinkeList, если он не знает алгоритмической сложности операции поиска по индексу и вставок/удалений?
На базовых знаниях все и строиться. Это как фундамент дома — низкоквалифицированные специалисты его не видят, и думают, что это что-то эфемерное и ненужное. А грамотные специалисты понимают, что это основа основ.
Здравствуйте, -n1l-, Вы писали:
N>Здравствуйте, samius, Вы писали: S>>Не все. Это не полный ответ.
N>Самое главное отличие, остальное лишь дотошные мелочи и многие из них — следствия главного отличия.
Не согласен. Даже если взять чисто абстрактный класс, он уже будет отличаться от интерфейса даже при отсутствии реализации каких либо методов.
N>Т.е. то, что абстрактный класс в самом деле — статический класс можно узнать и помнить, но все эти фишки умещаются в первое отличие.
Зачастую (в том же дотнете) это непересекающиеся вещи.
N>То, что интерфейс — набор сигнатур говорится везде и сразу и это опять же часть первого отличия.
Наборы сигнатур — это как раз общее, а не отличающее.
N>То, что для абстрактного класса можно пользоваться всякими фишками наследования, это тоже относится к первому отличию.
Для интерфейса тоже можно пользоваться всякими фишками наследования. Это относится к общему.
N>Дополните меня?
Хотя бы то что класс можно унаследовать лишь от одного класса, но реализовать множество интерфейсов.
Интерфейс не может содержать объявления кроме методов, свойств и событий экземпляра, а абстрактный класс может содержать все остальное.
Я докапался до того что слово "все" обычно подразумевает завершение перечисление отличий. А их вон еще сколько. И я ведь не все еще назвал.
Здравствуйте, techgl, Вы писали:
T>Здравствуйте, MxMsk, Вы писали:
MM>>Самое главное отличие, пожалуй, то, что абстрактный класс жестко задает ветвь наследования, в то время как интерфейс может быть реализован в любых иерархиях. Ну и применительно к C#, интерфейс может поддерживаться и структурами, тогда как абстрактный класс и его производные — однозначно ссылочные типы. T>Всегда считал что главное — это наличие состояния. В интерфейсе нет работы с состоянием.
Важно не то что в интерфейсе нельзя объявить поле. Важно то, что подразумевается интерфейсом в смысле интерфейсом взаимодействия, т.е. API класса/интерфейса.
Если взять, например, какой-нибудь IList, то очевидно что он либо работает наполовину, либо оперирует внутренним состоянием. Потому в этом аспекте нам не важно, был ли IList интерфейсом, или абстрактным классом. И то и другое подразумевает наличие состояния под капотом.
Здравствуйте, techgl, Вы писали:
T>Всегда считал что главное — это наличие состояния. В интерфейсе нет работы с состоянием. Ну и возможность частичной реализации тоже. Хотя для последнего, например, в Java 8 будет новое ключевое слово default, которое позволит частично реализовывать интерфейс.
Совсем необязательно, чтобы абстрактный класс имел состояние. Например, он может выполнять некоторую функцию, которая кастомизируется виртуальными методами. Плюс, добавляется еще специфика языка/платформы. В MSDN есть такой раздел для .Net.
Здравствуйте, cocacola, Вы писали:
C>У нас 100% такого нет, реально много гиков. Причем зп средняя довольно по городу. C>Как у вас с этим на работе? Какой уровень ваших коллег?
Вспомнился случай по этому поводу.
Работал у нас один чел, проект был связан с аддоном для Outlook, соответственно COM, ATL и все такое. Чел реально шарил в этом деле, использовал кучу недокументированных функций, все работало зашибись. Потом он перешел на другое место, а через полгода — с выходом нового SDK все работать перестало, т.к. какие-то недокументированные функции перестали существовать, что-то еще поменялось и пр. Реально сидеть с этим остальным было влом, в итоге проще оказалось все переписать, чем разбираться.
А так да, бывают гики готовые сидеть над проектом сутками (находка для начальства, особенно если они не требуют оплаты переработок ), есть обычные парни, в свободное время занимающиеся чем-то другим.
По большому счету, среднего уровня хватает для 95% задач, хотя в конторе нужны и 1-2 профи для особо сложных случаев
Здравствуйте, MxMsk, Вы писали:
MM>В MSDN есть такой раздел для .Net.
Сомнительный аргумент в пользу "Do favor defining classes over interfaces"
In later versions of your library, you can safely add new members to classes; you cannot add members to interfaces without breaking existing code.
Если учесть что интерфейс разрешает лишь методы/свойства/события и их аналогами в абстрактном классе будут абстрактные методы/свойства/события, то не сломав существующий код мы не можем добавить в абстрактный класс ничего абстрактного.
А раз нам надо добавлять неабстрактные методы/свойства/события и мы об этом заранее знаем, то зачем выбирать интерфейс?
Здравствуйте, bkat, Вы писали:
B>Почему-то как только мы перешли от С++ на C# стало намного сложнее найти хороших спецов. B>Вроде кандидатов больше, а вот выбирать почти не из чего...
а мы вот перешли на scala, так это вообще караул — спецов просто нет, ни хороших, ни плохих, хоть обратно на яву возвращайся
Здравствуйте, -n1l-, Вы писали:
N>Фактически да, но если абстрагироваться до их использования, они очень похожи.
чем ? ну да, и тому и другому требуется реализация, все, больше ничего общего
Здравствуйте, devcoach, Вы писали:
D>Хахаха, то есть что вы сейчас сказали? Примерно следующее: "Крутой специалист круто потому, что он принимает правильные решения". А вы не хотите задуматься, за счет чего он принимает правильные решения? Совершенно верно — благодаря знанию базовых вещей
нет, благодаря опыту
D>Например, как можно принять правильное решение какой XML парсер использовать, если человек не понимает в чем разница между DOM и стриминговыми парсерами? Да никак, он не сможет принять такое решение. Или что выбрать — блокирующее или неблокирующее IO? Или что выбрать под конкретную задачу — ArrayList или LinkeList, если он не знает алгоритмической сложности операции поиска по индексу и вставок/удалений?
это вообще что-то типа азбуки, ты еще укажи, что клавиатурой надо уметь пользоваться
D>На базовых знаниях все и строиться. Это как фундамент дома — низкоквалифицированные специалисты его не видят, и думают, что это что-то эфемерное и ненужное. А грамотные специалисты понимают, что это основа основ.
я не понимаю, что такое "базовые знания", то что ты выше указал это ну максимум юниор какой-нить зеленый имеет право не знать
Здравствуйте, samius, Вы писали:
S>Сомнительный аргумент в пользу "Do favor defining classes over interfaces"
Да я не настаиваю. Разместил больше для информации
), есть обычные парни, в свободное время занимающиеся чем-то другим.
