(10) alex_sh2008, если честно, то больше для себя, для души да и для саморазвития. По книгам занимаюсь в свободное от работы время дома, мне нравится, но если уж и менять сферу и уходить в Java то придется первое время за копейки работать. Вообще тема Java VS 1C весьма интересна.
(15) Ibrogim, По мне дак, разницы нет никакой, что 1С, что С++, что Java, задачи везде одинаковые, да и платят сейчас примерно одинаково, если вы конечно не ведущий программист в компании.
(1) Ibrogim,
Жаба? где-то я тебя видел уже...
Зачем тебе жаба? Больше толку от шарпа и плюсов. Но т.к. you 1сник, то тебе на шарп. Комы всякие уже заценил через 1С. Надо не потерять это знание, развивать нужно.
плюсы будут чужды, а вот шарп в самый раз - это такой язык, вроде бейсика, все просто, понятно и не уступает плюсам, там где его мастдай продвигает.
где ж я тебя видел....
Выбирай книгу и дуй на кибер.
может на гугле в вопросах и ответах или уже на кибере?
Но т.к. you 1сник, то тебе на шарп. Комы всякие уже заценил через 1С
До 1С ещё шарп юзал (непрофессионально, т.е. не за деньги) 100 лет назад на спецкурсе по opengl.
Воспоминания крайне отрывочны, помню какой то гибрид delphi и c++ (его тоже юзал в учебных целях).
По Java есть сертификат от cisco тех же времён. Благодаря этому сертификату я не стал получать аналогичные от 1С (т.к. понял истинную цену этих бумажек) .
на Delphi писал ВК для клюшек (тогда без ВК было не обойтись). Кодил на actionScript (Flash) и преподавал курс по созданию миниигр. Немного знаю css php html (Верстал с нуля сайты по техзаданию и писал модули на php для joomla) Практикую vba (для excel).
Думаю, что это тоже можно всё развивать.
Надо не потерять это знание, развивать нужно.
Выбор уже сделан. Германские коллеги тоже советовали не зарывать талант и попробовать ABAP
(83) alex_sh2008, ))) ну это ещё месяц назад выводилось. удобный всё таки нотпад этот ntelliJ пишешь sout, а он тебе System.out.println();
Задачи простенькие, но достаточно их много... (я не перехожу к новым лекциям, пока задачи все не решу, за задачу же дают антиматерию...)
Вот такого уровня пока задачи
/* Множество всех животных
1. Внутри класса Solution создать public static классы Cat, Dog.
2. Реализовать метод createCats, который должен возвращать множество с 4 котами.
3. Реализовать метод createDogs, который должен возвращать множество с 3 собаками.
4. Реализовать метод join, который должен возвращать объединенное множество всех животных - всех котов и собак.
5. Реализовать метод removeCats, который должен удалять из множества pets всех котов, которые есть в множестве cats.
6. Реализовать метод printPets, который должен выводить на экран всех животных, которые в нем есть. Каждое животное с новой строки
(84) Ibrogim, Я когда изучал С, потом С++, и далее, везде приходилось решать задачи с кошами и собаками, но в каждом случае необходимо было делать свою реализацию задачи, складывается впечатления что кроме кошек и собак тем кто писал книги ничего в голову не приходило ))),
(84) Ibrogim, а как Вы решили задачу про вывод 31 века? Ну не догоняю я, набираю System.out.println("3115"); так не приминают такое решение. Что не так? Спасибо!
(93) spacecraft, это был вопрос с подвохом):
Cat Cat3 = new Cat("белый", 2) + new Cat("черный", 3);//?
или так
Cat Cat1 = Cat("белый", 2);
Cat Cat2 = Cat("черный", 3);
Cat Cat3 = Cat1 + Cat2;//?
(92) alex_sh2008, Не, там упор сейчас на все объекты языка. Задача которую я привёл из цикла вдолбить себе в голову работу с HasMap HashSet, подобные задачи были для LinkedList и ArrayList
ООП ещё впереди, однако уже пройдены создание классов, методов, геттеры сеттеры и т.п.
Задача которую я привёл из цикла вдолбить себе в голову работу с HasMap HashSet
Для меня самое сложное было понять как применять, множественной наследование с полиморфными функциями и операторами. Месяца 2 или 3 ни как не мог въехать в этот принцип)
(102) spacecraft, По большому счет разработчики Java сами говорили что идея этого языка зародилась с целью создания языка подобного С++, но с менее жесткими требованиями, при разработке java, из языка исключили, указатели, множественное наследование, добавили автоматические сборщики мусора, в C++ разработчику приходилось самому заботится об этом.
Там имитация вроде? И именно "множественное наследование интерфейсов".
Я понимаю, что у вас каша в голове...
Но не надо путать наследование от реализации. Интерфейсы не наследуют, а реализуют. Там даже специально указывают "implements", что в переводе "реализует"
у ж не знаю вашей каши, но в Java именно так и называется.
Интерфейсы не наследуют, а реализуют.
Так в чем проблема "множественного наследования" или "множественного наследования интерфейсов"? Вас смущает, что термин-существительное первого - превратился в описание-существительное второго?
Мно́жественное насле́дование — свойство, поддерживаемое частью объектно-ориентированных языков программирования, когда класс может иметь более одного суперкласса (непосредственного класса-родителя). Эта концепция является расширением «простого (или одиночного) наследования» (англ. single inheritance), при котором класс может наследоваться только от одного суперкласса.
Smalltalk, C#, Objective-C, Java, Nemerle и PHP не допускают множественного наследования, что позволяет избежать многих неопределенностей. Однако, они, кроме Smalltalk, позволяют классам реализовать множественные интерфейсы.
Большинство современных объектно-ориентированных языков программирования (C#, Java, Delphi и др.) поддерживают возможность одновременно наследоваться от класса-предка и реализовать методы нескольких интерфейсов одним и тем же классом. Этот механизм позволяет во многом заменить множественное наследование — методы интерфейсов необходимо переопределять явно, что исключает ошибки при наследовании функциональности одинаковых методов различных классов-предков.
(187) spacecraft,
да как бы так то оно так...
просто есть небольшой нюанс, что да интерфейсы в принципе похожи на множественное наследование, но
все же тут есть несколько другой акцент. Т.е. наследование - это скажем так участие в иерархии классов.
А интерфейсы все же это обязательство по реализации и только. Т.е. как бы классы могут быть между собой никак не связаны, просто обязуются одинакого реализовать одну и туже функцию и все. Это нельзя назвать наследованием.
Например есть класс automobile
и есть класс horse
они по природе и иерархии, никак не связаны,
но обязуются реализовать интерфейс run();
ну сложно тут сказать что automobile унаследован от horse :)
и что это имеет какое-то отношение к наследованию.
Ну т.е. я вам предлагаю оставить этот спор, можно под разными углами смотреть на этот аспект.
Но вы можете и дальше не понимать того, с чем взялись работать.
Какое отношение определение для "Множественное наследование" имеет к понятию "Множественное наследование интерфейсов"?
(190) spacecraft,
Вы меня пытаетесь убедить в том, о чем я и так говорил?
конечно, конечно. Именно так и говорите.
О чем и выше.
(204) AlexO, вам бесполезно что-либо доказывать, вы уже не помните о чем высказывались несколькими постами выше.
можете продолжать упорствовать и дальше.
можете не отвечать, мне все равно, что и где вы будете говорить.
(206) spacecraft, Разберись с понятиями тип, класс. Что есть тип, а что есть класс. Что есть что в Jave. Рекомендую книги по Ruby почитать (для полноты картины)...
(208) awk, ок. Я знаю что такое класс, интерфейс, тип, структура, перечисления. Полиморфизм, инкапсуляция, наследование и композиция. Несколько шаблонов проектирования немного.
Может я и правда не прав в своих утверждениях, что в Java нет множественного наследия? А некоторый товарищ мне правильно доказывает, что есть и теперь это называется множественное наследие интерфейсов?
Что же касается понятия "множественное наследие интерфейсов", то это применительно только к самим интерфейсам (хотя и там это надумано), а не к классам с реализацией множества интерфейсов.
Смело... Я бы не стал так говорить, без указания языка.
Может я и правда не прав в своих утверждениях, что в Java нет множественного наследия? А некоторый товарищ мне правильно доказывает, что есть и теперь это называется множественное наследие интерфейсов?
Сам подумай:
public interface Drawable extends Colorable, Resizable {
}
И что почитать?
Завтра скажу точно книгу и автора... Там интересно с точки зрения кто есть кто...
public interface Drawable extends Colorable, Resizable {
}
А ничего, что я это указал:
Что же касается понятия "множественное наследие интерфейсов", то это применительно только к самим интерфейсам (хотя и там это надумано), а не к классам с реализацией множества интерфейсов.
(211) spacecraft, (210) awk, По большому счету основное отличие интерфейса от класса, это наличие у класса свойств, класс характеризуется как сущность (объект) со своими свойствами, интерфейс же определяет шаблонную функциональность сущностей. Преимущество и не достаток множественного наследования классов это так же наследование свойств базовых классов, что не всегда нужно при реализации наследования. И если мне память не изменяет, интерфейс может иметь только публичные перегружаемые функции
Интерфейс это и есть класс (в java, как и перечисление), на который наложены ограничения. Кстати в 9 версии интерфейс может иметь реализацию метода(ов) по умолчанию.
Что есть наследование? Основным и достаточным признаком наследования является использование экземпляров дочернего класса как экземпляров родительского без явного приведения типа.
Допустимый код:
Класс Родитель
Класс Потомок от Родитель
Родитель экземпляр = создать Потомок()
Не допустимый код:
Класс Родитель
Класс Потомок
Родитель экземпляр = создать Потомок()
java;
Interface I1;
Interface I2;
Class C implements I1, I2;
I1 i1 = new C();
I2 i2 = new C();
Вполне правильный код. Так что говорить об не том наследовании - некорректно. Так говорят сишники мало работающие с java.
С чего бы это стало вдруг недопустимым кодом?
Создается объект Потомок и присваивается ссылке с типом Родитель. Никаких противоречий нет. Только по этой ссылке нельзя напрямую вызвать методы Потомка. Нужно явно приводить тип. Это пример полиморфизма.
Не сразу понял, что в вашем вольном изложение кода Потомок не наследуется от Родитель.
А такой вполне:
А это принцип полиморфизма, который и интерфейс тоже реализует, но это не отменяем, что в Java нет множественного наследования. Ссылки на wiki я уже приводил.
Smalltalk, C#, Objective-C, Java, Nemerle и PHP не допускают множественного наследования, что позволяет избежать многих неопределенностей. Однако, они, кроме Smalltalk, позволяют классам реализовать множественные интерфейсы.
Большинство современных объектно-ориентированных языков программирования (C#, Java, Delphi и др.) поддерживают возможность одновременно наследоваться от класса-предка и реализовать методы нескольких интерфейсов одним и тем же классом. Этот механизм позволяет во многом заменить множественное наследование — методы интерфейсов необходимо переопределять явно, что исключает ошибки при наследовании функциональности одинаковых методов различных классов-предков.
Класс не наследует интерфейсы, а реализует их. Можно трактовать и вольно, в том числе, как будто они наследуются, но все же классы реализуют интерфейсы.
(243) spacecraft, Я в Java и C# перешел с C++, поэтому для меня более привычнее слоган наследование интерфейса, по принципу абстрактных классов, и где я понимаю что должен реализовать функционал интерфейса.
(243) spacecraft, где же Вы не правы?
Ладно, есть одно местечко... мы тут болтаем о том о сем, общей базы нет, друг друга даже понять не можем.
Нет резона доказывать что-то, при таком раскладе.
Я сначала думал - заблуждаются, но вот такие изречения:
(243) spacecraft: Класс не наследует интерфейсы
говорят вообще о непонимании ООП. Просто без понимания используются термины для составления внешне связного предложения: глагол-прилагательное-существительное.
Пусть остаются в 1С - там можно трактовать все, что угодно и как угодно.
(265) AlexO, Я понимаю. Он, вероятно, читал "Andrew Troelsen. Pro C# 5.0 and the .NET 4.5 Framework" и, возможно, в оригинале. Там интерфейсы автор реализует.
Кстати говоря, принципы ООП лучше понимают прогеры с++.
К этому так трудно прийти, что каждый бывший (или нет) 1сник начинает со спагетти-кода и ужасных форм архитектуры.
По сути говоря, если нет классов, то люди выдумывают чудо-алгоритмы и насильно загоняют туда обрабатываемые данные со всей их логикой (такая помойка может начаться из протаскивания параметров и проверок).
Если классы есть, то люди думают прежде чем писать (это даже важнее, чем знание языка) над тем, что из себя представляют данные (какими свойствами обладают и как соотносятся друг с другом). Выделив отдельные сущности их собирают в коробки со свойствами и методами так, чтобы они были самодостаточны (это как разделить людей по зонам ответственности). Потом в коробки играют, делая требуемое по ТЗ решение.
Это все стало доступно сразу как придумали переменные с типами. Это пожалуй самое крупное нововведение.
Как декларация/реализация относиться к наследованию?
Так можно все перевернуть с ног на голову, что ребята и делают "успешно". В 1С так и реализовано - "интерфейс"-скрипт является образующим для "класса"-объекта. Но смысл?
Если задуматься над "целью" создания такого "монстра" - получить мешанину из груды "объектов", дикие тормоза в выполнении такого кода, отсутствие связей между "объектами"? Ну, получили. 1С - "прекрасный" пример подобной реализации.
(267) awk, я Вас не понимаю с полуслова.
Вместо "наследования" можно использовать слово "расширение".
"Декларация" и потом "реализация" интерфейсов дают нам тип и класс, который можно хранить в этом типе. Тип определяет поведение.
Если Вы искушены в с++, то набор слов и их значение меняется.
"Декларация" и потом "реализация" интерфейсов дают нам тип и класс
Декларация и реализация интерфейсов нам дают инструмент работы с любыми типами которые поддерживают данный интерфейс, но они нам не дают ни тип ни класс.
(282) ture, переменную интерфейса нельзя создать, можно создать переменную класса наследовавшего функции интерфейса, и уже потом можно вызвать функции родителей используя приведение типов
Так на любом ООП-языке можно написать другой ООП-язык, включив в него отдельно - классы, отдельно - нечто, и назвать "интерфейсы", и даже подчинить классы - "интерфейсам" ))
Тут нет предела фантазии, но цель?
Именно по такому пути (только без классов, но со своими "интерфейсами") и пошли в 1С.
Вот все из одного ряда.
Это все стало доступно сразу как придумали переменные с типами.
Типизация переменных - это одна из основ ООП. Жаль, что сейчас преобладает "тренд" движения к хаосу (ребята из данного топика - пример), и создание сред подобных 1С.
Ты давно работал над крупным проектом в комманде на языке высокого уровня? Тренд о унификаии типов запустили как-раз кодеры ООП. Безграничной любовью к аля Variant. Ведь и сам не скажу, что это неудобно.
Разумеется, когда будем писать на низком уровне, там протокол примема передачи по среде или с устройством, то типизация будет жесткая. При работе с пользовательским интерфейсом - проще унифицировать.
Работу с БД признаю "низким" уровнем, где мне бы типизации хотелось. В запросах да.
Ты давно работал над крупным проектом в комманде на языке высокого уровня?
Все "крупные проекты" в России - давно уже просто распил бабла. И уж точно не критерий образцовости программирования. Поэтому для меня это не аргумент.
(272) fzt,
Разумеется, когда будем писать на низком уровне
Язык программирования "низкого" уровня - это Ассемблер. Протоколы обмена не пишутся на Асме.
И драйвера не на чистом Асме, точнее, есть спецсреды для разработки драйверов под каждую ОС (для Windows - Это DDK (сейчас WDK), т.к.драйвера пишутся под конкретные устройства и конкретные среды/ОС, а эти среды имеют вполне конкретные порты работы с устройствами, которые, в свою очередь, являются вполне конкретными ячейками памяти, соответственно, средам разработки драйверов крайне необходима возможность работы с указателями. И, например, это Си (не "плюс-плюс", хотя и он возможен, но без вызова системных библиотек ОС, т.к. их нет на уровне, на котором работают драйвера).
Т.е. вы не знаете разницу между "низким" и "высоким" языком.
там протокол примема передачи по среде или с устройством
Протоколы - это набор правил обмена_передачи информации в той или иной среде, от среды программирования не зависящий.
Ерунда, типизация переменных ни какого отношения к ООП не имеет, вы хотя бы изначально для себя определите как вы для себя понимаете ООП, а не цитируйте понимание ООП других.
(276) ture, классы это наследники структур в C и были придуманы что бы оптимизировать структурировать огромные наборы функций работающие со структурами.
(276) ture. Я все-таки считаю что типы - дело десятое. Действительно возможно ПО где все типы Variant. Это никак не мешает создавать объекты и их фабрики etc.
типизация переменных ни какого отношения к ООП не имеет
Это база ООП, без типизации переменных (и, соответственно, обрабатываемых данных) не будет универсальной передачи между объектами, универсальных интерфейсов, полиморфизма, наследования - т.е. не будет ООП вообще. Как, например, в 1С, где типизации нет.
(232) spacecraft, Такое описание наследования не корректное, нет четкого определения уровня наследования, поэтому в некоторых компиляторах на такой код выдается ошибка если зарание у них не задан уровень наследования по умолчанию.
Что же касается понятия "множественное наследие интерфейсов", то это применительно только к самим интерфейсам (хотя и там это надумано), а не к классам с реализацией множества интерфейсов.
Вы уже настолько запутались, что дальше некуда.
Какие "реализации классов со множеством интерфейсов"?
Вам начинать надо с понятий "класс" и "интерфейс", раз для вас это едино все.
А потом плавно, осторожно переходить к понятию "в Ява нет "множественное наследия классов", но "множественное наследие" есть между интерфейсами, которые, являясь описаниями методов классов, реализация которых остается в "родительском" классе, в итоге в большинстве случаев как-бы реализуют именно "функционал" наследия нескольких классов - в дочернем классе.
(104) Lokiy, Например ArrayList и LinkedList
В первом быстро работает получение и установка по индексу но долго вставляется элемент в конкретную позицию, а во втором наоборот.
(106) Ibrogim, и всем на это наплевать :) все тупо используют ArrayList :)
Добавление в середину списка это такая редкая задача :) Я только один раз видел в исходниках чтоб кто-то в исходниках LinkedList использовал.
Да и вот если подумать вот в 1С 10 лет программировал, ни разу в середину ТЗ или СпискаЗначений значения не добавлял :)
(107) Lokiy, (106) Ibrogim, основное различие - сохранение порядка вставляемых записей(от туда и скорость вставки к конкретную позицию)...это редко где нужно поэтому чаще всего используется ArrayList
(107) Lokiy, Используют когда не требуется каких операций проводить с содержимым списка, в случае сортировки, поиска, уже применяют тот который наиболее подходит, и речь идет не о простых типах, а о классах.
(113) alex_sh2008, да я согласен, щас можно напридумывать задач, где очень нужен LinkedList И без него никак :) Но это такой примитивный разгон :) Давайте щас еще обсуждать чем абстрактный класс от интерфейса отличается :)))
(115) alex_sh2008, да я не спорю что потребность бывает... я просто говорю что начинающему разработчику можно не парится :) Один раз столкнется с потребностью оптимизации долгой сортировки ArrayList, поищет на stackoverflow - да и вставит LinkedList :)
(120) alex_sh2008, знаешь если ты студент и у тебя впереди целая жизнь и ты учишься до 15.00 а после 15.00 свободен - то можно изучать все, это даже интересно и приятно.
А если тебе за 30, и ты решил быстро освоить чтобы уйти из 1С, то тут надо искать более быстрые и оптимальный пути развития, нужно себя мотивировать правильно, чтоб не махнуть на все рукой, подсовывать самому себе проекты и задачки поинтереснее и посложнее. А сидеть годами зубрить учебники - это же ад, да и не ведет ни к чему.
(122) Lokiy, При каркасном изучение таких сложных языков, максимум на что будет способен программист это написание программки из 500 строк, что то более серъезное уже будет не под силам.