- 01
- 02
- 03
- 04
- 05
- 06
- 07
- 08
- 09
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
- 26
- 27
- 28
- 29
- 30
- 31
- 32
- 33
- 34
- 35
- 36
- 37
- 38
- 39
- 40
- 41
- 42
- 43
- 44
- 45
- 46
- 47
- 48
- 49
- 50
- 51
- 52
- 53
- 54
- 55
- 56
- 57
- 58
- 59
- 60
- 61
- 62
- 63
- 64
- 65
- 66
- 67
- 68
- 69
- 70
- 71
- 72
- 73
- 74
- 75
- 76
- 77
- 78
- 79
- 80
- 81
- 82
- 83
- 84
- 85
- 86
- 87
- 88
- 89
- 90
- 91
- 92
- 93
q = Convert.ToString(a.ToString() + b.ToString() + c.ToString() + d.ToString() + f.ToString() + g.ToString() + h.ToString() + j.ToString() + k.ToString() + l.ToString());
int a = int.Parse(textBox2.Text[0].ToString());
int b = int.Parse(textBox2.Text[1].ToString());
int c = int.Parse(textBox2.Text[2].ToString());
int d = int.Parse(textBox2.Text[3].ToString());
int f = int.Parse(textBox2.Text[4].ToString());
int g = int.Parse(textBox2.Text[5].ToString());
int h = int.Parse(textBox2.Text[6].ToString());
int j = int.Parse(textBox2.Text[7].ToString());
int k = int.Parse(textBox2.Text[8].ToString());
int l = int.Parse(textBox2.Text[9].ToString());
Random rnd = new Random();
int a = rnd.Next(0, 2);
int b = rnd.Next(0, 2);
int c = rnd.Next(0, 2);
int d = rnd.Next(0, 2);
int f = rnd.Next(0, 2);
int g = rnd.Next(0, 2);
int h = rnd.Next(0, 2);
int j = rnd.Next(0, 2);
int k = rnd.Next(0, 2);
int l = rnd.Next(0, 2);
private void DoWork(int a, int b, int c, int d, int f, int g, int h, int j, int k, int l)
private void ResetState()
{
pictureBox5.Visible = false;
pictureBox6.Visible = false;
pictureBox7.Visible = false;
pictureBox8.Visible = false;
pictureBox9.Visible = false;
pictureBox2.Visible = false;
pictureBox3.Visible = false;
pictureBox4.Visible = false;
pictureBox10.Visible = false;
pictureBox11.Visible = false;
pictureBox12.Visible = false;
pictureBox13.Visible = false;
pictureBox14.Visible = false;
pictureBox15.Visible = false;
pictureBox16.Visible = false;
pictureBox17.Visible = false;
pictureBox18.Visible = false;
pictureBox19.Visible = false;
pictureBox20.Visible = false;
pictureBox27.Visible = false;
pictureBox28.Visible = false;
pictureBox29.Visible = false;
pictureBox31.Visible = false;
pictureBox32.Visible = false;
pictureBox33.Visible = false;
pictureBox34.Visible = false;
pictureBox35.Visible = false;
pictureBox36.Visible = false;
pictureBox30.Visible = false;
label2.Visible = false;
label4.Visible = false;
textBox2.Clear();
textBox1.Clear();
}
if (((b == 0 && (a == 1)) || ((b == 0) && (a == 0)) || ((b == 1) && (a == 0)) || ((b == 1) && (a == 1))))
{
if ((b == 0) && (pictureBox3.Visible)) { pictureBox6.Visible = Enabled; }
if ((b == 0) && (pictureBox2.Visible)) { pictureBox5.Visible = Enabled; }
if ((b == 1) && (pictureBox2.Visible)) { pictureBox6.Visible = Enabled; pictureBox4.Visible = Enabled; }
if ((b == 1) && (pictureBox3.Visible)) { pictureBox5.Visible = Enabled; pictureBox4.Visible = Enabled; }
}
//желательно чтоб здесь была пауза
if (((c == 0 && (pictureBox5.Visible)) || ((c == 0) && (pictureBox6.Visible)) || ((c == 1) && (pictureBox5.Visible)) || ((c == 1) && (pictureBox6.Visible))))
{
if ((c == 0) && (pictureBox5.Visible)) { pictureBox7.Visible = Enabled; }
if ((c == 0) && (pictureBox6.Visible)) { pictureBox8.Visible = Enabled; }
if ((c == 1) && (pictureBox5.Visible)) { pictureBox8.Visible = Enabled; pictureBox29.Visible = Enabled; }
if ((c == 1) && (pictureBox6.Visible)) { pictureBox7.Visible = Enabled; pictureBox29.Visible = Enabled; }
}
//желательно чтоб здесь была пауза
if (((d == 0 && (c == 1)) || ((d == 0) && (c == 0)) || ((d == 1) && (c == 0)) || ((d == 1) && (c == 1))))
{
if ((d == 0) && (pictureBox7.Visible)) { pictureBox9.Visible = Enabled; }
if ((d == 0) && (pictureBox8.Visible)) { pictureBox10.Visible = Enabled; }
if ((d == 1) && (pictureBox7.Visible)) { pictureBox10.Visible = Enabled; pictureBox30.Visible = Enabled; }
if ((d == 1) && (pictureBox8.Visible)) { pictureBox9.Visible = Enabled; pictureBox30.Visible = Enabled; }
}
Follow us!
a b c d f g h ...
Может с клавиатурой проблемы? Или со знанием алфавита?
А, кажется догадался... (object sender, EventArgs e). Шарпоблядство же...
Что за наезды на процедурный стиль? :)
Это стиль "я у мамы дурочка" или "обожаю копипасту". Настоящий процедурный стиль, в отличие от таких портянок, легко читается и рефакторится.
Но вы правы, тут даже не процедурный стиль, тут действительно портянка.
Да ну, бросьте, и под 50+ файлов сишки без крестов в процедурном стиле можно читать и поддерживать (проверено на собственном опыте).
Если код хороший, то инкапсуляция в нем и без ООП имеется, а это половина успеха. Если же код плохой, то с ООП он в 99% случаев будет читаться хуже чем в процедурном стиле (больше возможностей, которые можно поюзать не по назначению).
Куча небольших модулей с простым, понятным API. В каждом 5-15 публичных функций. Ни одна переменная наружу модуля не торчала. Часть модулей юзалась как на сервере, так и на железке, и на ее эмуляторе.
В паре-тройке подсистем был тупой полиморфизм. Для чего - отвязка от особенностей обвеса, такого как весы, сканеры штрихкодов и т.п., диалоговые мордочки, которые показывал терминал.
Я бы не сказал, конечно, что задача сильно сложная, но и не такая уж тривиальная.
P.S. Из опенсурсного кода, с которым сталкивался, могу предложить почитать сырцы asterisk'а или freeradius'а.
Если у вас например куча модулей написанных на си, и каждый модуль выполняет свою отдельную задачу просто используя общую систему, то это не то, что я имел ввиду.
Я имел ввиду, что когда вы пишите программу в процедурном стиле где более сложные логические связки, то в этом коде не так то просто разобраться.
Ну как отдельную. Если бы они были совсем-совсем отдельными, это была бы библиотека, а не система ;) Все-таки они взаимодействуют друг с другом через вызовы публичных апишек да колбеки. Ну местами через интерфейсы (на си это структура-с-указателями).
> более сложные логические связки
> в этом коде не так то просто разобраться
Причем не потому, что он написан в процедурном стиле, а именно из-за его сильной связности ;) Ну или из-за того, что задача действительно сложна, и очень плохо разбивается на подзадачи.
Нет, я не говорю, что процедурный стиль это панацея, и надо бросить ООП. Просто хоть теоретическая граница сложности у ООП больше, но там, при неопытности, полно возможностей быстро добежать до границы практической, и довести проект до нечитаемого состояния.
ООП это не божественное откровение, позволяющее сделать код понятным. Это всего лишь инструмент, удобный во многих случаях.
>читать и поддерживать (проверено на собственном опыте).
>Причем не потому, что он написан в процедурном стиле, а именно из-за его
> сильной связности ;)
Так вот я об этом и говорю. И на ООП и в процедурном стиле можно писать лапшу, а конкретно эта лапша, хоть и использует ООП ЯП но написана в процедурном стиле. Почему процедурном? Потому, что это, по моему, самый первый стиль программирования.
Можно делать бесполезные классы, с торчащими наружу членами, которые юзают изо всех соседних классов.
Можно делать классы с невменяемой семантикой, которые будут работать только в сценариях, в которых их юзал автор, и падать при любой правке кода.
В некоторых языках можно перегрузить операторы и конструкторы копий на что-то совершенно идиотское, и понятное только автору.
В общем случае сишный говнокод читается проще оопшного говнокода, т.к. там хотя бы фантазия автора ограничена функциями, структурами и модулями, а байтоёбство и макросы нубы обычно не юзают.
Код полный дублирования и связанный настолько насколько это вообще можно себе представить.
Но си не застал. Молод.
После таких слов я чувствую себя стариком, заставшим си...
у вас не было детства
А абстракция, полиморфизм, инкапсуляция и даже наследование к парадигме ООП никак не привязаны, это слишком общие идеи.
> в процедурном стиле где более сложные логические связки
Качество и читаемость кода слабо зависит от парадигмы. Всё практически полностью зависит от программиста.
В рамочку ;)
Только ради вас
"заменяют 10 строк одинакого кода, на 40 разного".
Его надо заносить. В учебники.
Оно во многом уместо и в рамках данного спора о пользе/вреде ООП.
Я тоже за процедурный стиль, но сишка - устарела.
Неплохим языком трудно назвать, многие вещи следовало бы поменять, сделав язык проще и логичнее.
Особенно тотальную зависимость языка от препроцессора.
Абсолютно согласен. Однако ничего столь же одновременно низкоуровневого, простого и вменяемого давно не появлялось. Паскаледиалекты умерли. Всё сплошь одни управляемые среды. Видимо, считают, что с++ - это предел. Да и конкуренции, в принципе, не выдержать.
Rust вон недавно вышел. Интересный проект, но уж слишком много туда насовали. Да и уж больно он какой-то исследовательский.
Go мне понравился своей практичностью, лаконичностью, внутренней простотой и вниманием к проблеме зависимостей. Видна рука мастера (Роб Пайк). Но, опять же, управляемая среда.
И это печально...
>Go
В целом смотрится неплохо, взяты лучшие находки js и сишки. Не понравилось:
а) нет исключений
б) нет женериков
И фатальный недостаток (делает неконкурентным сишке) - упраляемая среда.
Скорее, питона и сишки. Питонье влияние ощущается довольно явно.
> нет исключений
есть (пара встроенных функций panic и recover), они просто не в почёте. Их надо использовать в действительно исключительных ситуациях.
Женериков действительно нет, и, видимо, никогда не будет.
ты ошибаешься
разве?
sql не в счет.
sql это вообще голимая декларативщина, не имеющая отношения ни к императивным языкам, ни к функциональным, ни к ооп.
А вот языки для хранимок типа t-sql или pl/sql это да, процедурная императивщина.
Побойтесь пролОГА!
Проблем было много, но они были не в "структурном" подходе. Если бы люди там изначально заботились об инкапсуляции и управлении сложностью, кода было бы существенно меньше, и он был бы вполне приятным и модульным.
Система независящих друг от друга модулей гораздо легче в понимании, чем система со сложными логическими связями.
А вы в ООП разве не стараетесь сделать картину максимально близкой к этой самой "куче слабосвязанных модулей"? Если нет, то мне искренне жаль тех, кому приходится читать и поддерживать ваш код.
Модулями я называю такой объект, который независим от конкретной системы и не привязан к ней, т.е. может использоваться везде ну или практически везде.
Это проблемы вашей терминологии.
А я называю это библиотекой...
В сишке я напишу несколько модулей и сложу их в директорию, посвященную более крупной подсистеме. В с++/c# вы напишете несколько классов, и поместите их в один неймспейс. В яве я напишу несколько классов, и помещу их в один пакет.
Синтаксис разный, выглядит по-разному, но концепция едина и не зависит от языка.
А если они составляют целостную систему, то компонентами или модулями системы, иногда приходится уточнять, но если люди опытные понимают сразу.
Вот вы же например поняли.
Причем тут вообще стиль?
Именно поэтому при любой парадигме, будь то ООП или ФП или ПП, адекватные программисты пытаются разбить систему на, по возможности, независимые части, и сделать связи между подсистемами как можно проще и наглядней...
Если писать кучу отдельных модулей, который впринципе не зависят ни от кого, то это легче, чем проектировать в процедурном стиле кучу компонентов которые являются частью одной системы.
Хоть горшком назови, только в печь не клади... Подсистемы, классы, модули, неймспейсы, библиотеки, компоненты, жабьи пакеты... как бы все это не называлось, как бы все это не отличалось синтаксисом, все это служит всего лишь одной общей цели - декомпозиции системы на подсистемы...
Когда я говорил про сишные модули, я имел в виду именно декомпозицию на более-менее независимые части.
Если бы я говорил о наборе самостоятельных, реюзабельных компонент, которые можно применить в разных проектах - я бы назвал это библиотекой.
Пожалуй закончим на этом наш терминологический спор ;)
:)
Причем тут процедурный стиль вообще?
особенно когда на то есть светские причины, отличные от религиозных
например - меньший объем исполняемого файла, аби, отсутствие искушений и потому ручные оптимальности и контроль
> Всё практически полностью зависит от программиста
абсолютно согласен
и более того, написать серьезную, большую и поддерживаемую программу на С сложнее, прилично сложнее, чем на С++
хотя бы потому, что на С велосипедить приходится гораздо больше, внимание программиста распыляется на мелкие детали
Да, поспорить с этим я не смогу. Причем совсем не из-за процедурного стиля, как указывали выше, а из-за невменяемой, неюзабельной на 99%, местами наивной до идиотизма стандартной либой.
Что уж спорить о велосипедах, если стандартной функцией без костылей даже строку в буфер адекватно не скопируешь...
Да. Значительно. И ещё не хватает деструкторов и шаблонов. И, как сказал bormand, нормальной стандартной библиотеки.
Вот к стати регулярно жалею, что ни одна IDE не позволяет (при программировании "мышкой") засунуть элементы на форме в массив (или контейнер).
Это и ненужно. Любую сложную логику можно запихать в свои виджеты и их юзать в дизайнере. Цель дизайнера - обеспечить наглядное представление формочек.