Задачи для начинающих
Этим нужно заниматься с самого начала.
Я вообще то не сторонник бросания людей сразу в море что бы научить их плавать. Кто выплывет - молодец, а кто не выплывет тот нам и даром не нужен.
Похоже у моего знакомого сторонники данной теории.
После первой задачи, сразу контрольная на дизайн паттерны, а потом что то с SOLID будет
Этим нужно заниматься с самого начала.
-----
Эээ... это в тебе говорит засилье буржуазной методологии.
Я, кстати, встречал подготовленных по этой методике - без всяких проблем выстраивают охрененные иерархии интерфейсов и абстрактных классов. А дальше начинается проблема - уложить алгоритм в операторы никак не получается...
Правда в том, что надо поймать момент когда операторы уже освоены и алгоритм реализуется без особых проблем и тогда вводить классы, затем - виртуальные функции, следом - абстрактные классы и наконец - интерфейсы. Причем именно в таком порядке.
привыкнув думать отдельными методами
-----
Это как раз работа преподавателя - оценивать достигнутое и не позволять застаиваться в нем.
человек просто не станет переучиваться
-----
Опять 25...
ВУЗ на то и ВУЗ чтобы научить эффективно (само)обучаться.
Если этого нет - называй его ПТУ или ТЕХНИКУМ.
а свете топика вроде однозначно - задачи для начинающих которые с программированием раньше не сталкивались
-----
Для них не существует возможности получить хоть какое-нибудь решение - требуется базис - переменные, выражения, операторы-выражения, оператор-иф. Без этого - никак.
Найди какую-нибудь советскую книжку в названии которой есть словосочетание "дидактические материалы" и ознакомься в плане - исходные требования к обучаемому, тема и методика обучения, ожидаемый результат. Оно там дается на КАЖДОЕ занятие/тему. Это- минимум. Если поковыряешь кого-нибудь из закончивших пед-ВУЗ - они тебе еще накидают методик оценки/мотивации/стимулирования и прочей их премудрости...
задачи для начинающих которые с программированием раньше не сталкивались.
Есть несколько способов учить разговаривать на иностранном языке.
Один - заучить слова, потом заставить говорить как нибудь, потом пытаться корректировать построение предложений. Это классика, так учат взрослых эммигрантов и в итоге получается "моя твоя не понимай". Но работает, эти люди могут как то комунницировать.
И есть способ заучивания готовых конструкций. Разговорных паттернов. Так учат детей.
Поэтому ИМХО при обучении програмированию на обьектно-ориентированных языках сразу необходимо использовать и застaвлять использовать все ООП-конструкции. Многие будут потом использоваться интуитивно.
Промежуточный код тоже можно представить в удобоваримом виде. Ну чутка подучить теорию и сделать в соответствии с нею. Там не сложно, но получится много более понятно... для понимающих тер.базис.как именно удобоварительнее? где глянуть?
............
хотя возможно это и не понадобится. Приведенная генерация в СиШарп сделана только для симуляции, чтоб можно было отладить алогоритм без контоллера прямо на десктопе. А в контроллере зачастую и дотнэта нету.
как именно удобоварительнее?
-----
Так же как со светофором - контроллер - отдельно, функционалистика - отдельно.
Функционалистика, кстати, сильно упростится.
На одной из предыдущих работ шеф требовал... сначала от китаянки - сделай... и она лепила как могла - вместо автомата - код с флажками... потом - от меня - поправь/переделай... но пока не переписал как надо - починить было невозможно... а когда переписал - все пошло легко и быстро... но само переписывание заняло кучу времени...
Так что делать надо правильно - не "помня, что есть теория", а в соответствии с теорией - получится и просто, и красиво...
И есть способ заучивания готовых конструкций
Ну попугая тоже можно научить разговорной речи данным способом.
И пока, как я вижу на примере студента, получается именно так. Никакого понимания нет и в помине, да и не может быть.
Я не представляю, как можно начинающему понять где есть что и зачем.
тебе еще накидают методик оценки/мотивации/стимулирования
Зачем? Этот аспект мне интересен меньше всего. А уж на форуме почти бессмыслен.
Меня больше интересует, как можно получить решение понятное начинающим, которое не будет "страшным".
Для светофора с кнопочкой такого пока не нахожу Без кнопочки еще как то можно.
Но опять таки, размещать всё в одном классе совершенно не хочется, так что хотя бы один простой класс добавить нужно.
В этом случае всё управление лампочками будет там. Это позволит убрать хотя бы ошибки переключения, когда горят красный и зелёный одновременно. И уж точно гарантировать что при включенном зеленом для авто не будет зеленого для пешеходов.
В этом случае приходим к довольно простой главной функции
private static void Main(string[] args) { CombinedTrafficLight trafficLight = new CombinedTrafficLight(); InitTraceState(); while (true) { trafficLight.DisableAutoTraffic(); trafficLight.EnablePedestrianTraffic(); Delay(RedLightTimeMs); TraceState(trafficLight); trafficLight.EnableLightSwitch(); trafficLight.DisablePedestrianTraffic(); Delay(YellowLightTimeMs); TraceState(trafficLight); trafficLight.EnableAutoTraffic(); Delay(GreenLightTimeMs); TraceState(trafficLight); trafficLight.EnableLightSwitch(); Delay(YellowLightTimeMs); TraceState(trafficLight); } }
результат получается таким
+------+-----+-----+ |Pdestr|Auto |Delay| | R G |R Y G| [s] | |------+-----+-----| | * |* |3.094| | * | * |1.015| | * | *|4.000| | * | * |1.016| | * |* |3.000| | * | * |1.016| | * | *|4.015| | * | * |1.016| | * |* |3.000|
Так же как со светофором - контроллер - отдельно, функционалистика - отдельно.
ну вот ниже я переделал на автомат. Все лампочки светофора записываются каждый раз на основании текущего шага ветки В1.
Но мне лично больше нравится предыдущая версия (где машина состояний, но не автомат).
Зачем? Этот аспект мне интересен меньше всего.
-----
Затем, чтобы понимать что надо дать, как надо дать и что надо требовать чтобы удостоверится что до обучаемого "дошло" (цель обучения достигнута)...
А пока не "дошло" - следующий шаг бессмыслен - максимум - заучит наизусть что есть что и что забудет на следующий день, а навыка "сложить из того что есть" - не появится.
В случае задачи со светофором, по не озвученным тобою требованиям, требовалось сформулировать ДВА "если" или обеспечить ТРИ ветви выполнения кода.
Данное решение удовлетворит тебя (хотя мне лично непонятно почему), но не будет решением задачи по светофору.
как можно получить решение понятное начинающим
-----
Мне вообще не понятно как можно говорить об каком-то "понятном решении" не зная базиса который есть у того кто должен понять.
По условию у тебя начинающий, без предварительных знаний в программировании.
В моем понимании - есть три группы таковых:
- детсадовцы (без возможности понимать какие-то формализмы)
- школьники (с возможностью понимать формализмы)
- возрастные взрослые (закончившие школу до ИТ эры)
Группу - старшешкольники и молодые взрослые - опустил - т.к. у них есть предварительные знания в объеме школьного курса.
Для каждой группы все будет по-разному.
Для самой младшей группы тебе придется сделать физические предметы представляющие собой части решения и обучать и складывать в решение под мантру поясняющую что именно делается. Дней за 10-15 сложишь и будет моргать светофор. На самостоятельное повторение или модификацию - не рассчитывай - они на это еще не способны.
приходим к довольно простой главной функции
-----
Да? А они в школе функции проходили? Хотя бы на уровне определения функции как отображение из многих в одно соответствие?
И уж точно гарантировать
-----
Задекларируй как задачу что тебе надо написать условия проверки горения лампочек используя оператор-иф - если знают необходимый минимум - могут написать.
Модифицируй задачу - в полученном светофоре зажигать нужный набор лампочек по внешней команде.
Модифицируй задачу еще раз - написать контроллер светофора - что-то что будет сообщать что должно гореть...
А цикл, тем более - бесконечный цикл в который запихано ВСЕ - им еще долго изучать...
читать жабий байт-код.
Не в этом дело. Все в одну простыню. В проге есть модули. Например состояния. Их надо изолировать. Тогда тот же кейс будет оперировать не кусками километрового кода, а объектами или на худой конец вызовами методов. То же с именами переменных.
Я не представляю, как можно начинающему понять где есть что и зачем.
А может не надо так? Может можно на конкретных примерах? Вот взять код Программиста и показать инкапсуляцию. Взять два класса зверь и собака и показать абстракцию и наследование? Агрегирование на примере колес автомобиля?
Не в этом дело. Все в одну простыню.Тут такой случай, что пока сам не испробуешь - не поймешь.
Уверяю всех неверующих: тупейшая простыня switch-casе - это самая понятная и удобная реализация машины состояний.
Ибо даже при отсутствии графического редактора, глядя на эту простыню case за case-ом, и имея в руках карандаш над бумагой, диаграмма безошибочно оказывается на ней.
Что и наоборот верно: нарисованная диаграмма однозначно ложится в swith case-ы.
А до того пока я это понял, я изобретал исполнялки машины состояний, входом которым служил массив описывающий состояния, и переходы в другие с Func<> в качестве условий, с Action<> в качестве действий.
Но когда приходит время применить это на реальной задаче, то обязательно найдется неудобный моментик, в котором вся эта жесткость определений связывает тебе руки, а при switch-case-ах они свободны.
Тогда тот же кейс будет оперировать не кусками километрового кода, а объектами или на худой конец вызовами методов.не знаю где там можно увидеть кусок километрового кода, ибо там именно кода нигде и 5 строк не превышает.
Но конечно можно все действия оформить в методы, а все условия - в функции. Но это как раз - маразм.
Это стоит делать только если код действительно большой - для наглядности.
Но надо еще учитывать что любые вызовы методов/функций - это накладные раходы, которые вполне могут оказывать существенное влияние, если программа работает на дохлом контроллере с еле живым процессором.
Мне приходилось перерабатывать функциональные блоки для их ускорения из за жалоб заказчиков, путём примитивного убирания вложенных вызовов функций, т.е. делая из "правильного" кода - простыни.
Суха мой друг
теория одна...как Пушкин сказал.