- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
public void AllSolutionButtons(bool TrueOrFalse)
{
SetButtons("TopCorners", TrueOrFalse);
SetButtons("TopWings", TrueOrFalse);
SetButtons("BottomCorners", TrueOrFalse);
SetButtons("BottomWings", TrueOrFalse);
SetButtons("middleSlice", TrueOrFalse);
SetButtons("Solve", TrueOrFalse);
}
Кроме, конечно, переменной с глупым именем TrueOrFalse...
{
}
else
{
}
можно слить в одну ветку
Допустим мы опечатались в имени кнопки, программа компилируется, ошибки не выдает и даже работает,но как толко мы начинаем работать с этой кнопкой начинаются чудеса. Логика вынесена вообще в левый класс никак не связанный ни со вьюхой ни с бизнес логикой. Можно ли будет такую ошибку быстро отловить? А если там еще трай-кетчи в "нужные" места поставлены?
С другой стороны если мы удалим кнопку с формочки, что произойдет? Или если мы захотим добавить еще одну кнопку? мы должны будет это прописывать в 4х местах? .... это неудобно и долго.
Люди стремятся сделать системы из компонент(кусков, модулей - как угодно) как можно менее связанных между собой, с четко обозначенной функциональностью (выраженной например юнит и интегр. тестами). Это позволяет снизить ошибки хитрого и неочивидного взаимодействия, здесь же мы наблюдаем наооброт - еще более тесное привязывание View к логике приложения. ..... как то так
Ну и плюс по наименованиям не сильно приятный код. Но меня выбесила именно архитектурная кривизна этого всего (я согласен, что общая картина не видна по этому отрывку кода)
Самодокументируемый код такой самодокументируемый...