то очень трудно дается, то есть я понимаю механизм что есть что И так далее, но когда начинаю писать код, стараясь использовать ооп то все - плыву. Это нормально? Или я один такой дебил?
над прост понять что такое классы, зачем нужны классы и.т.д + базу вот эту всю, вроде все остальное чисто фичи шарпа, которые достаточно простые (ну типа ООП в плюсах куда сложнее, там 100500 нюансов, а в шарпе все предельно прост)
Некоторые всю жизнь плавают и не признаются, заучат минимум и считают себя профи. Главное это осознавать и всегда учиться
Да я как бы в целом понимаю для чего нужны классы, то что они могут наслодоватся ято есть интерфейсы и обструкции И так далее, По отдельности все понятно, но когда ты остаешься 1 на 1 сам с собой то из всего этого в голове каша, и просто не понятно , даже не понятно что именно не понято)
пойми, ООП это способ решения какой-то проблемы скажем у тебя есть два класса, у которых есть какое-то общее поведение И если например общего очень много, и шанс того, что какое-то изменение в одном месте неизбежно повлечёт за собой мысль "блин а в другом классе я также делаю надо подправить" , ну например ты работал с файлом, а теперь твой начальник сказал перейти на MYSQL, ты сразу поймёшь например что такое Базовый класс и зачем он нужен , в таком кейсе. Чтобы вынести общую логику "выше", конкретно в этом примере -> перейти от хранения в файле к хранению в БД
Все нормально, у меня также было, главное продолжай черпать информацию, а понимание вскоре придет
Вот в профиле у тебя заявление что сеньёр программер через полгода - это хорошая шутка) я в с# абсолютный новичек, не знаю как у вас, а с sql, системным мэнеджментом, управлением и т.п. я так сказать до синьера шел лет 8)
Для начала я-бы рекомендовал посмотреть что такое настоящее ООП. В C# его огрызок. Правда его пытаются допилить до полного, но то как они это делают вызывает только фейспалм.
Ну в плюсах, допустим.
И чем же там ооп лучше и почему оно настоящее
Ну для начала там есть множественное наследование.
так а что там ? это вообще языки разных областей, круды на плюсах не пишут, онли хай перфоманс
Это антипаттерн)0)
Интерфейсы в шарпе грустят. Во вторых множественное наследование говно
Вы заблуждаетесь. CRUD'ы там пишут.
Где посмотреть что такое настоящее ООП?
Интерфейсы - это костыли от отсутствия множественного ООП. И то что теперь там можно писать методы - только подтверждает это
стоит хоть 1 раз покодить хоть что-то уровня лабок / курсовых, шоб понять шо там такой порог вхождения, шо тупо не выгодно этот язык тащить туда, где подойдет шарп / го / нода и вот эт все )
Методы в интерфейсах это плохо, да
Вы удивитесь, но если использовать поднабор, то внезапно С++ становится понятным.
если не обкуриваться вариадиками и прочим, то по сути да, но все равно хватает в языке граблей...
Ну в плюсах интерфейсов нету за ненадобностью. Так как интерфейсы реализуются абстрактными классами. Ну просто by design
Я хз зачем добавили имплементацию методов в интерфейсах. Это совсем лишнее. Давай смотреть на интерфейс так как положено
Ну тогда это просто костыль от отсутствия множественного наследования
Зачастую от множественного наследования строго такие ощущения
Вы просто не умеете его готовить. Например косытли DI в множественном наследовании решаются очень просто...
Понятно, интерфейсы это про множественное наследование, однако!
Это ответ языков без множественного наследования на вопрос "А что делать-то"
Ага, вот бы разрабы дотнета удивились, наверное.
Ток чота я не помню DI в плюсах
А что делать когда? Какую проблему вы решаете множественным наследованием?
http://net-informations.com/faq/general/inheritance.htm
Что делать, когда вам надо отнаследоваться от более чем одной сущности
Если надо отнаследоваться от более, чем одной сущности, то есть агрегация, а вообще имеет место проблема проектирования зачастую
Не используйте интерфейсы
И терять удобство и гибкость языка?
Не делать этого ок? Зачем тебе сущность которая наследует сразу 2 функционала? Зачем сразу 2 ответственности? Используй агрегацию и делегируй ответственности другим сущностям
С чего бы?
Не используйте интерфейсы.
Так а в чем проблема? Если тебе не нужна логика в классе, то пиши интерфейс и всё
Я уже сказал... Хорошо... Вам нужен пример... В качестве примера возьмем интерфейс IDisposable. Это класс, который реализует корректную работу с Unmanaged объектами. Нет, я понимаю что это интерфейс, но если-бы это был нормальный язык, то защиту от повторного вызова и от попытки удалить уже удаленные ресурсы вы написали-бы в IDisposable
В каждом объекте своя реализация
Но везде и всегда есть защита от 2го вызова
Реализации IDisposable могут быть разными. Сам интерфейс удобен тем, что мне не надо требовать наследования от хер пойми какого класса, который ни разу не знает, как ему диспозить мой объект.
И вот вы нарушили инкапсуляцию.
С чего бы?
Каким образом
С хуя ли? Я вовне даю метод Dispose. А реализацию как раз инкапсулирую.
Да это прикол)
Обсуждают сегодня