Не знаю, я вот недавно решил обсудить на форуме шаблоны проектирования (http://programmersforum.ru/showthread.php?t=54347). Хотя здесь цели более приземлённые, прямая связь UML диаграммы и кода. От вижуал студии решил отказаться, хотя уже десять лет с ней знаком, ещё с 6.0 версии.
Ну, а в целом, можно понять зачем вас там всякому учат, но лично я пытаюсь освоить проектирование для того чтобы самому писать программы как «стапицот» человек, пока не для взаимодействия с какими-то там людьми или командами, и полностью на самообучении.
Разработчик может быть проектировщиком, а может кодировщиком. Кодировщику быстрее написать так, как придётся. Проектировщик это смежная область умений. Вполне возможно, что над вами издевались и действительно требовали муть.
Неправильно построенный процесс проектирования может быть даже хуже, чем его отсутствие. А чтобы проектировать правильно, то есть повышать производительность и эффективность разработчиков, а так же надёжность самой программы, надо практиковаться не меньше, чем в умении кодировать.
Денег стало больше, а производительность в стране такая же, деньги обесцениваются по отношению к другим валютам. Студентов стало больше, корок стало больше, но производить больше не стали, дипломы обесцениваются.
Они пытаются вдолбить то, что придёт само, но лишь через много лет работы. Правильно придумывать архитектуру надо используя тот же UML и шаблоны проектирования, для которых есть стереотипы. Преобразование это в реальный код вопрос практики и требует участие программиста :)
>Повезло нам что аспирант, который преподавал нам практику программирования смог убедить лектора уйти от того же паскаля в строну C#.
Вам бы повезло если бы он убедил лектора уйти в сторону C++, того самого ISO/IEC 14882. Причём когда я говорю повезло, имею ввиду обретаемые программистами возможности. C# как язык хорош, хотя больно он быстро меняется в худшую сторону, но вот реализация у него плохая.
Эти примеры не о том. Они созданы для использования операторов вне классов. К тому же представим, что типов преобразования не два A и B, а больше. С каждым вот таким использованием количество методов будет расти в геометрической прогрессии. Между прочим твои примеры как раз и показывают как делать не надо, тема называется «конструкторы и преобразования». Вот условно назову некий оператор #
1.operator#(x); // ошибка
И моё высказывание относилось вовсе не к тому, как её преодолеть. А именно к тому, что не нужно писать уродский код полагаясь на особенности некой реализации. Реализация в конце концов может оказаться совсем другой.
Нет, не хорошо. Есть ведь ещё перегрузка операторов и неявное преобразование из типа. Писать надо так как наиболее понятно. Думать о том, что может быть ошибка и из-за этого делать уродский код не стоит. В противном случае весь код окажется уродским и непонятным.
>Я не пойму, что вы предлагаете.
>Собраться вместе и что-то наконец сделать?
Всё очень просто, были челы, они бухали. В момент протрезвления был написан этот топик. Сейчас наверное они там опять бухают придаваясь мечтам о том как круто всё замутят. Мечта как известно желаннее, чем сам результат.
Это только кажется, что стала неактуальной или что там ничего нет. Восприятие зависит от предыдущего опыта. Вот мой опыт при чтении этого документа прямо говорил о том как надо строить алгоритмы сервисов, разрабатывать протоколы обмена, системы рейтингов и поощрений, а так же много другое. Очень многое нужного ещё не реализовано.
Да, карты разума индивидуальны, и очень хороши для тех кто их составил. Существуют разные принципы их построения. Некоторые не требуют сильного логического мышления. Наоборот, если у человека оно слабое, карты разума при правильном использовании способны помочь продвинутся в чём-либо.
Так делать больше людям нечего. Сейчас все глухонемые соберутся и начнут подтверждать. Наверняка на этом форуме есть больные сифилисом, пусть они подтвердят или опровергнут мою теорию.
Ну, а в целом, можно понять зачем вас там всякому учат, но лично я пытаюсь освоить проектирование для того чтобы самому писать программы как «стапицот» человек, пока не для взаимодействия с какими-то там людьми или командами, и полностью на самообучении.
Нет желания, значит забей.
Неправильно построенный процесс проектирования может быть даже хуже, чем его отсутствие. А чтобы проектировать правильно, то есть повышать производительность и эффективность разработчиков, а так же надёжность самой программы, надо практиковаться не меньше, чем в умении кодировать.
Вам бы повезло если бы он убедил лектора уйти в сторону C++, того самого ISO/IEC 14882. Причём когда я говорю повезло, имею ввиду обретаемые программистами возможности. C# как язык хорош, хотя больно он быстро меняется в худшую сторону, но вот реализация у него плохая.
1.operator#(x); // ошибка
И моё высказывание относилось вовсе не к тому, как её преодолеть. А именно к тому, что не нужно писать уродский код полагаясь на особенности некой реализации. Реализация в конце концов может оказаться совсем другой.
>>if (x == 1)
>>а
>>// ХОРОШО?
>>if (1 == x)
Нет, не хорошо. Есть ведь ещё перегрузка операторов и неявное преобразование из типа. Писать надо так как наиболее понятно. Думать о том, что может быть ошибка и из-за этого делать уродский код не стоит. В противном случае весь код окажется уродским и непонятным.
>Собраться вместе и что-то наконец сделать?
Всё очень просто, были челы, они бухали. В момент протрезвления был написан этот топик. Сейчас наверное они там опять бухают придаваясь мечтам о том как круто всё замутят. Мечта как известно желаннее, чем сам результат.
А как вы соединитесь с соседом если у него серобуромалиновый ip.