Xipho

Сходу мышление всё равно перестроить сложно. Теперь тебе стоит просто писать код, практиковаться, и оно по тихой само пойдёт. Это немного странно, потому как четко прослеживается иерархия классов окна и контрола (опять же, по примеру винапи). А у тебя есть понимание, почему стоит программировать именно так?

Эта серия вся дружелюбная. Годноты там немало ) Всё так, ага ))) Но лучше, когда ты понимаешь, куда вляпываешься, чтобы это не было случайным Очень правильно. Я бы порекомендовал по каждому паттерну в ходе изучения прикидывать свои кейсы и набрасывать их в коде.

хипхо не одобрит код, обмазанный паттернами ради паттернов...

Да, она непростая, с нее сложно начинать. Но чем она хороша - там прям жизненный пример написания редактора текстового. Она намного проще, и хорошее понимание даст. Но после нее я всё же настоятельно рекомендую читать "банду четырех".

Примерный алгоритм в картинке под спойлером. Укладываемся в один проход. Этот алгоритм довольно медленный, есть варианты его распараллелить Ну Ну и да, байты надо проверять не вложенными условиями, это бред вообще, а в одном. Типа if (t[i] == 0x89 && t[i+1] == 0x50 && t[i+2] == 0x4E && t[i+3] == 0x47) { //тут включаем режим записи и все такое } Это базовые вещи на подумать. И еще на подумать - есть варианты реализации побыстрее и получше. %3CmxGraphModel%3E%3Croot%3E%3CmxCell%20id%3D%220%22%2F%3E%3CmxCell%20id%3D%221%22%20parent%3D%220%22%2F%3E%3CmxCell%20id%3D%222%22%20style%3D%22edgeStyle%3DorthogonalEdgeStyle%3Brounded%3D0%3BorthogonalLoop%3D1%3BjettySize%3Dauto%3Bhtml%3D1%3BexitX%3D0.5%3BexitY%3D1%3BexitDx%3D0%3BexitDy%3D0%3B%22%20edge%3D%221%22%20source%3D%223%22%20target%3D%2212%22%20parent%3D%221%22%3E%3CmxGeometry%20relative%3D%221%22%20as%3D%22geometry%22%2F%3E%3C%2FmxCell%3E%3CmxCell%20id%3D%223%22%20value%3D%22%D0%9F%D0%B5%D1%80%D0%B5%D0%B1%D0%B8%D1%80%D0%B0%D0%B5%D0%BC%20%D1%81%D0%BE%D0%B4%D0%B5%D1%80%D0%B6%D0%B8%D0%BC%D0%BE%D0%B5%20%D0%B8%D1%81%D1%85%D0%BE%D0%B4%D0%BD%D0%BE%D0%B3%D0%BE%20%D1%84%D0%B0%D0%B9%D0%BB%D0%B0%20%D0%BF%D0%BE%D0%B1%D0%B0%D0%B9%D1%82%D0%BE%D0%B2%D0%BE%22%20style%3D%22rounded%3D0%3BwhiteSpace%3Dwrap%3Bhtml%3D1%3B%22%20vertex%3D%221%22%20parent%3D%221%22%3E%3CmxGeometry%20x%3D%22160%22%20y%3D%2280%22%20width%3D%22200%22%20height%3D%22100%22%20as%3D%22geometry%22%2F%3E%3C%2FmxCell%3E%3CmxCell%20id%3D%224%22%20style%3D%22edgeStyle%3DorthogonalEdgeStyle%3Brounded%3D0%3BorthogonalLoop%3D1%3BjettySize%3Dauto%3Bhtml%3D1%3BexitX%3D1%3BexitY%3D0.5%3BexitDx%3D0%3BexitDy%3D0%3BentryX%3D0.5%3BentryY%3D0%3BentryDx%3D0%3BentryDy%3D0%3B%22%20edge%3D%221%22%20source%3D%226%22%20target%3D%223%22%20parent%3D%221%22%3E%3CmxGeometry%20relative%3D%221%22%20as%3D%22geometry%22%3E%3CArray%20as%3D%22points%22%3E%3CmxPoint%20x%3D%22600%22%20y%3D%22265%22%2F%3E%3CmxPoint%20x%3D%22600%22%20y%3D%2260%22%2F%3E%3CmxPoint%20x%3D%22260%22%20y%3D%2260%22%2F%3E%3C%2FArray%3E%3C%2FmxGeometry%3E%3C%2FmxCell%3E%3CmxCell%20id%3D%225%22%20style%3D%22edgeStyle%3DorthogonalEdgeStyle%3Brounded%3D0%3BorthogonalLoop%3D1%3BjettySize%3Dauto%3Bhtml%3D1%3BentryX%3D0.5%3BentryY%3D0%3BentryDx%3D0%3BentryDy%3D0%3B%22%20edge%3D%221%22%20source%3D%226%22%20target%3D%2222%22%20parent%3D%221%22%3E%3CmxGeometry%20relative%3D%221%22%20as%3D%22geometry%22%2F%3E%3C%2FmxCell%3E%3CmxCell%20id%3D%226%22%20value%3D%22%26lt%3Bspan%26gt%3B%D0%A2%D0%B5%D0%BA%D1%83%D1%89%D0%B8%D0%B9%20%D0%B1%D0%B0%D0%B9%D1%82%20%26lt%3Bbr%26gt%3B%2B3%20%D1%81%D0%BB%D0%B5%D0%B4%D1%83%D1%8E%D1%89%D0%B8%D1%85%20%26lt%3Bbr%26gt%3B%D1%80%D0%B0%D0%B2%D0%BD%D1%8B%26amp%3Bnbsp%3B%26lt%3Bbr%26gt%3B%26lt%3B%2Fspan%26gt%3B0x89%2C%2050%2C%204E%2C%2047%26lt%3Bspan%26gt%3B%3F%26lt%3B%2Fspan%26gt%3B%22%20style%3D%22rhombus%3BwhiteSpace%3Dwrap%3Bhtml%3D1%3B%22%20vertex%3D%221%22%20parent%3D%221%22%3E%3CmxGeometry%20x%3D%22400%22%20y%3D%22187.5%22%20width%3D%22159.31%22%20height%3D%22155%22%20as%3D%22geometry%22%2F%3E%3C%2FmxCell%3E%3CmxCell%20id%3D%227%22%20style%3D%22edgeStyle%3DorthogonalEdgeStyle%3Brounded%3D0%3BorthogonalLoop%3D1%3BjettySize%3Dauto%3Bhtml%3D1%3BexitX%3D0.5%3BexitY%3D1%3BexitDx%3D0%3BexitDy%3D0%3BentryX%3D0.5%3BentryY%3D0%3BentryDx%3D0%3BentryDy%3D0%3B%22%20edge%3D%221%22%20source%3D%229%22%20target%3D%2216%22%20parent%3D%221%22%3E%3CmxGeometry%20relative%3D%221%22%20as%3D%22geometry%22%2F%3E%3C%2FmxCell%3E%3CmxCell%20id%3D%228%22%20style%3D%22edgeStyle%3DorthogonalEdgeStyle%3Brounded%3D0%3BorthogonalLoop%3D1%3BjettySize%3Dauto%3Bhtml%3D1%3B%22%20edge%3D%221%22%20source%3D%229%22%20parent%3D%221%22%3E%3CmxGeometry%20relative%3D%221%22%20as%3D%22geometry%22%3E%3CmxPoint%20x%3D%22260%22%20y%3D%2280%22%20as%3D%22targetPoint%22%2F%3E%3CArray%20as%3D%22points%22%3E%3CmxPoint%20x%3D%2280%22%20y%3D%22520%22%2F%3E%3CmxPoint%20x%3D%2280%22%20y%3D%2260%22%2F%3E%3CmxPoint%20x%3D%22260%22%20y%3D%2260%22%2F%3E%3C%2FArray%3E%3C%2FmxGeometry%3E%3C%2FmxCell%3E%3CmxCell%20id%3D%229%22%20value%3D%22%D0%A2%D0%B5%D0%BA%D1%83%D1%89%D0%B8%D0%B9%20%D0%B1%D0%B0%D0%B9%D1%82%20%26lt%3Bbr%26gt%3B%2B2%20%D1%81%D0%BB%D0%B5%D0%B4%D1%83%D1%8E%D1%89%D0%B8%D1%85%26lt%3Bbr%26gt%3B%D1%80%D0%B0%D0%B2%D0%BD%D1%8B%26amp%3Bnbsp%3B%26lt%3Bbr%26gt%3B42%2C%2060%2C%2082%3F%22%20style%3D%22rhombus%3BwhiteSpace%3Dwrap%3Bhtml%3D1%3B%22%20vertex%3D%221%22%20parent%3D%221%22%3E%3CmxGeometry%20x%3D%22178.8%22%20y%3D%22450%22%20width%3D%22162.4%22%20height%3D%22140%22%20as%3D%22geometry%22%2F%3E%3C%2FmxCell%3E%3CmxCell%20id%3D%2210%22%20style%3D%22edgeStyle%3DorthogonalEdgeStyle%3Brounded%3D0%3BorthogonalLoop%3D1%3BjettySize%3Dauto%3Bhtml%3D1%3BexitX%3D0.5%3BexitY%3D1%3BexitDx%3D0%3BexitDy%3D0%3BentryX%3D0.5%3BentryY%3D0%3BentryDx%3D0%3BentryDy%3D0%3B%22%20edge%3D%221%22%20source%3D%2212%22%20target%3D%2214%22%20parent%3D%221%22%3E%3CmxGeometry%20relative%3D%221%22%20as%3D%22geometry%22%2F%3E%3C%2FmxCell%3E%3CmxCell%20id%3D%2211%22%20style%3D%22edgeStyle%3DorthogonalEdgeStyle%3Brounded%3D0%3BorthogonalLoop%3D1%3BjettySize%3Dauto%3Bhtml%3D1%3BentryX%3D0%3BentryY%3D0.5%3BentryDx%3D0%3BentryDy%3D0%3B%22%20edge%3D%221%22%20source%3D%2212%22%20target%3D%226%22%20parent%3D%221%22%3E%3CmxGeometry%20relative%3D%221%22%20as%3D%22geometry%22%2F%3E%3C%2FmxCell%3E%3CmxCell%20id%3D%2212%22%20value%3D%22%D0%A0%D0%B5%D0%B6%D0%B8%D0%BC%20%D0%B7%D0%B0%D0%BF%D0%B8%D1%81%D0%B8%20%D0%B2%D0%BA%D0%BB%D1%8E%D1%87%D0%B5%D0%BD%3F%22%20style%3D%22rhombus%3BwhiteSpace%3Dwrap%3Bhtml%3D1%3B%22%20vertex%3D%221%22%20parent%3D%221%22%3E%3CmxGeometry%20x%3D%22200%22%20y%3D%22210%22%20width%3D%22120%22%20height%3D%22110%22%20as%3D%22geometry%22%2F%3E%3C%2FmxCell%3E%3CmxCell%20id%3D%2213%22%20style%3D%22edgeStyle%3DorthogonalEdgeStyle%3Brounded%3D0%3BorthogonalLoop%3D1%3BjettySize%3Dauto%3Bhtml%3D1%3BexitX%3D0.5%3BexitY%3D1%3BexitDx%3D0%3BexitDy%3D0%3BentryX%3D0.5%3BentryY%3D0%3BentryDx%3D0%3BentryDy%3D0%3B%22%20edge%3D%221%22%20source%3D%2214%22%20target%3D%229%22%20parent%3D%221%22%3E%3CmxGeometry%20relative%3D%221%22%20as%3D%22geometry%22%2F%3E%3C%2FmxCell%3E%3CmxCell%20id%3D%2214%22%20value%3D%22%D0%9F%D0%B8%D1%88%D0%B5%D0%BC%20%D1%82%D0%B5%D0%BA%D1%83%D1%89%D0%B8%D0%B9%20%D0%B1%D0%B0%D0%B9%D1%82%20%D0%B2%20%D0%B2%D1%8B%D1%85%D0%BE%D0%B4%D0%BD%D0%BE%D0%B9%20%D1%84%D0%B0%D0%B9%D0%BB%22%20style%3D%22whiteSpace%3Dwrap%3Bhtml%3D1%3B%22%20vertex%3D%221%22%20parent%3D%221%22%3E%3CmxGeometry%20x%3D%22200%22%20y%3D%22360%22%20width%3D%22120%22%20height%3D%2260%22%20as%3D%22geometry%22%2F%3E%3C%2FmxCell%3E%3CmxCell%20id%3D%2215%22%20style%3D%22edgeStyle%3DorthogonalEdgeStyle%3Brounded%3D0%3BorthogonalLoop%3D1%3BjettySize%3Dauto%3Bhtml%3D1%3BentryX%3D0.5%3BentryY%3D0%3BentryDx%3D0%3BentryDy%3D0%3B%22%20edge%3D%221%22%20source%3D%2216%22%20target%3D%223%22%20parent%3D%221%22%3E%3CmxGeometry%20relative%3D%221%22%20as%3D%22geometry%22%3E%3CArray%20as%3D%22points%22%3E%3CmxPoint%20x%3D%22260%22%20y%3D%22700%22%2F%3E%3CmxPoint%20x%3D%2280%22%20y%3D%22700%22%2F%3E%3CmxPoint%20x%3D%2280%22%20y%3D%2260%22%2F%3E%3CmxPoint%20x%3D%22260%22%20y%3D%2260%22%2F%3E%3C%2FArray%3E%3C%2FmxGeometry%3E%3C%2FmxCell%3E%3CmxCell%20id%3D%2216%22%20value%3D%22%D0%92%D1%8B%D0%BA%D0%BB%D1%8E%D1%87%D0%B0%D0%B5%D0%BC%20%D1%80%D0%B5%D0%B6%D0%B8%D0%BC%20%D0%B7%D0%B0%D0%BF%D0%B8%D1%81%D0%B8%2C%20%D0%B7%D0%B0%D0%BA%D1%80%D1%8B%D0%B2%D0%B0%D0%B5%D0%BC%20%D1%82%D0%B5%D0%BA%D1%83%D1%89%D0%B8%D0%B9%20%D0%B2%D1%8B%D1%85%D0%BE%D0%B4%D0%BD%D0%BE%D0%B9%20%D1%84%D0%B0%D0%B9%D0%BB%22%20style%3D%22whiteSpace%3Dwrap%3Bhtml%3D1%3B%22%20vertex%3D%221%22%20parent%3D%221%22%3E%3CmxGeometry%20x%3D%22200%22%20y%3D%22620%22%20width%3D%22120%22%20height%3D%2260%22%20as%3D%22geometry%22%2F%3E%3C%2FmxCell%3E%3CmxCell%20id%3D%2217%22%20value%3D%22%D0%94%D0%B0%22%20style%3D%22text%3Bhtml%3D1%3Balign%3Dcenter%3BverticalAlign%3Dmiddle%3Bresizable%3D0%3Bpoints%3D%5B%5D%3Bautosize%3D1%3BstrokeColor%3Dnone%3BfillColor%3Dnone%3B%22%20vertex%3D%221%22%20parent%3D%221%22%3E%3CmxGeometry%20x%3D%22260%22%20y%3D%22320%22%20width%3D%2230%22%20height%3D%2220%22%20as%3D%22geometry%22%2F%3E%3C%2FmxCell%3E%3CmxCell%20id%3D%2218%22%20value%3D%22%D0%94%D0%B0%22%20style%3D%22text%3Bhtml%3D1%3Balign%3Dcenter%3BverticalAlign%3Dmiddle%3Bresizable%3D0%3Bpoints%3D%5B%5D%3Bautosize%3D1%3BstrokeColor%3Dnone%3BfillColor%3Dnone%3B%22%20vertex%3D%221%22%20parent%3D%221%22%3E%3CmxGeometry%20x%3D%22260%22%20y%3D%22590%22%20width%3D%2230%22%20height%3D%2220%22%20as%3D%22geometry%22%2F%3E%3C%2FmxCell%3E%3CmxCell%20id%3D%2219%22%20value%3D%22%D0%9D%D0%B5%D1%82%22%20style%3D%22text%3Bhtml%3D1%3Balign%3Dcenter%3BverticalAlign%3Dmiddle%3Bresizable%3D0%3Bpoints%3D%5B%5D%3Bautosize%3D1%3BstrokeColor%3Dnone%3BfillColor%3Dnone%3B%22%20vertex%3D%221%22%20parent%3D%221%22%3E%3CmxGeometry%20x%3D%22310%22%20y%3D%22240%22%20width%3D%2240%22%20height%3D%2220%22%20as%3D%22geometry%22%2F%3E%3C%2FmxCell%3E%3CmxCell%20id%3D%2220%22%20value%3D%22%D0%9D%D0%B5%D1%82%22%20style%3D%22text%3Bhtml%3D1%3Balign%3Dcenter%3BverticalAlign%3Dmiddle%3Bresizable%3D0%3Bpoints%3D%5B%5D%3Bautosize%3D1%3BstrokeColor%3Dnone%3BfillColor%3Dnone%3B%22%20vertex%3D%221%22%20parent%3D%221%22%3E%3CmxGeometry%20x%3D%22550%22%20y%3D%22270%22%20width%3D%2240%22%20height%3D%2220%22%20as%3D%22geometry%22%2F%3E%3C%2FmxCell%3E%3CmxCell%20id%3D%2221%22%20style%3D%22edgeStyle%3DorthogonalEdgeStyle%3Brounded%3D0%3BorthogonalLoop%3D1%3BjettySize%3Dauto%3Bhtml%3D1%3BexitX%3D0.5%3BexitY%3D1%3BexitDx%3D0%3BexitDy%3D0%3BentryX%3D0.5%3BentryY%3D0%3BentryDx%3D0%3BentryDy%3D0%3B%22%20edge%3D%221%22%20source%3D%2222%22%20target%3D%2223%22%20parent%3D%221%22%3E%3CmxGeometry%20relative%3D%221%22%20as%3D%22geometry%22%2F%3E%3C%2FmxCell%3E%3CmxCell%20id%3D%2222%22%20value%3D%22%D0%A1%D0%BE%D0%B7%D0%B4%D0%B0%D1%82%D1%8C%20%D0%B2%D1%8B%D1%85%D0%BE%D0%B4%D0%BD%D0%BE%D0%B9%20%D1%84%D0%B0%D0%B9%D0%BB%22%20style%3D%22whiteSpace%3Dwrap%3Bhtml%3D1%3B%22%20vertex%3D%221%22%20parent%3D%221%22%3E%3CmxGeometry%20x%3D%22419.66%22%20y%3D%22370%22%20width%3D%22120%22%20height%3D%2260%22%20as%3D%22geometry%22%2F%3E%3C%2FmxCell%3E%3CmxCell%20id%3D%2223%22%20value%3D%22%D0%92%D0%BA%D0%BB%D1%8E%D1%87%D0%B8%D1%82%D1%8C%20%D1%80%D0%B5%D0%B6%D0%B8%D0%BC%20%D0%B7%D0%B0%D0%BF%D0%B8%D1%81%D0%B8%22%20style%3D%22whiteSpace%3Dwrap%3Bhtml%3D1%3B%22%20vertex%3D%221%22%20parent%3D%221%22%3E%3CmxGeometry%20x%3D%22419.66%22%20y%3D%22460%22%20width%3D%22120%22%20height%3D%2260%22%20as%3D%22geometry%22%2F%3E%3C%2FmxCell%3E%3CmxCell%20id%3D%2224%22%20value%3D%22%D0%94%D0%B0%22%20style%3D%22text%3Bhtml%3D1%3Balign%3Dcenter%3BverticalAlign%3Dmiddle%3Bresizable%3D0%3Bpoints%3D%5B%5D%3Bautosize%3D1%3BstrokeColor%3Dnone%3BfillColor%3Dnone%3B%22%20vertex%3D%221%22%20parent%3D%221%22%3E%3CmxGeometry%20x%3D%22480%22%20y%3D%22340%22%20width%3D%2230%22%20height%3D%2220%22%20as%3D%22geometry%22%2F%3E%3C%2FmxCell%3E%3CmxCell%20id%3D%2225%22%20style%3D%22edgeStyle%3DorthogonalEdgeStyle%3Brounded%3D0%3BorthogonalLoop%3D1%3BjettySize%3Dauto%3Bhtml%3D1%3BexitX%3D0.5%3BexitY%3D1%3BexitDx%3D0%3BexitDy%3D0%3BentryX%3D0.5%3BentryY%3D0%3BentryDx%3D0%3BentryDy%3D0%3B%22%20edge%3D%221%22%20source%3D%2226%22%20target%3D%223%22%20parent%3D%221%22%3E%3CmxGeometry%20relative%3D%221%22%20as%3D%22geometry%22%3E%3CArray%20as%3D%22points%22%3E%3CmxPoint%20x%3D%22480%22%20y%3D%22620%22%2F%3E%3CmxPoint%20x%3D%22600%22%20y%3D%22620%22%2F%3E%3CmxPoint%20x%3D%22600%22%20y%3D%2260%22%2F%3E%3CmxPoint%20x%3D%22260%22%20y%3D%2260%22%2F%3E%3C%2FArray%3E%3C%2FmxGeometry%3E%3C%2FmxCell%3E%3CmxCell%20id%3D%2226%22%20value%3D%22%D0%97%D0%B0%D0%BF%D0%B8%D1%81%D0%B0%D1%82%D1%8C%20%D0%B2%20%D1%84%D0%B0%D0%B9%D0%BB%20%D1%82%D0%B5%D0%BA%D1%83%D1%89%D0%B8%D0%B9%20%D0%B1%D0%B0%D0%B9%D1%82%22%20style%3D%22whiteSpace%3Dwrap%3Bhtml%3D1%3B%22%20vertex%3D%221%22%20parent%3D%221%22%3E%3CmxGeometry%20x%3D%22419.65999999999997%22%20y%3D%22540%22%20width%3D%22120%22%20height%3D%2260%22%20as%3D%22geometry%22%2F%3E%3C%2FmxCell%3E%3C%2Froot%3E%3C%2FmxGraphModel%3E

Он, разумеется, допустим. Но, как по мне, компонент должен "рисовать себя сам". И тогда у тебя получится очень простая иерархия вызовов. Кто-то (система) у родительского окна вызывает метод Draw, родительское окно у всех своих дочерних компонентов вызывает этот же метод, и так по цепочке до самого нижнего компонента. А тут у тебя получается то, о чем я говорил - размазывание ответственности. По сути, родительскому компоненту незачем знать детали отрисовки дочерних компонентов. Каждый отвечает сам за себя. Снова делаю отсыл к классу Glyph из книги "банды четырех". Там прямо очень четко это объяснено.

Правильный подход, но, сразу оговорюсь, что такое полезно не всегда и везде. Есть ряд случаев, где лучше применить композицию вместо наследования.

И снова у меня толком нет времени, чтобы тебе обстоятельно ответить, а давая контекст кусками, я создаю у тебя в голове впечатление противоречий. Это плохо. Давай так. Попробуй внимательно почитать про принципы SOLID. Если тебе что-то в них не будет понятно, пиши, постараюсь объяснить. На конкретных примерах кода в разных участках программы это делать сложно. Попутно - прочитать/перечитать книгу по паттернам от "банды четырех", внимательно вникая, как авторы рассуждают по ходу книги. Поинт на заметку - почему в винде каждый контрол является окном, туда же - в упомянутой книге почему в редакторе везде и всюду во главе всего идет класс Glyph.

https://en.wikipedia.org/wiki/Two's_complement По остальному - я вообще ничего не понял, если честно. Можешь алгоритм текстом расписать? Пока единственное, что могу предложить - не читай файл в память, а делай его отображение на память https://docs.microsoft.com/ru-ru/windows/win32/memory/creating-a-file-view

По-хорошему, в метода не должно быть "побочных эффектов". И если задача метода нарисовать кнопку, то проверять, надо ли ее вообще рисовать - выглядит как не его ответственность.

Если у тебя и сам if состоит из одного выражения, и else из одного - тогда да, смысла ставить нет, в других случаях - смысл есть, чтобы было единообразие кода. Я не устану повторять - в идеале код должен читаться, как книга. Из-за этого мне синтаксис Rust не очень нравится - его местами тяжело читать из-за его макроконструкций. Для начала, надо понять, какую проблему ты решаешь. Сейчас ты поменял одну конструкцию на другую, стало чуть более читаемо, но суть не изменилась. Суть же в том, что у тебя несколько вложенных условных конструкций, что и ведет к снижению читаемости кода.

Это же не мой репозиторий, это форк, посмотри внимательно )) Не видна. Большое количество вложений вызывает ухудшение читаемости и, соответственно, понимание кода. А вот если ты это растаскиваешь по методам c с говорящими именами - это куда лучше. Ты сразу понимаешь, что происходит в твоем метод, а если становятся интересны детали - проваливаешься в меньший метод. Надо посидеть, подумать, прикинуть архитектурно как это разрулить. Можно глянуть с точки зрения паттернов.

У нас на канале есть несколько видео о том, как отделять игрока от врага. Рекомендую их посмотреть.

Пробегусь чисто поверхностно: 1 - нет фигурных скобок. Ухудшается чтение. Можно вынести все условие целиком в отдельный действительно короткий метод. 2, 3, 4 - вынести в отдельный метод, завести сущность, характеризующую рисование для этого метода, и сразу три условия схлопнется. Типичный перегруз. Ошибки: 1. Опять местами отсутствуют операторские скобки. Да, там, где в условии одно действие, они не являются необходимыми, но для упрощения читаемости кода их всё равно рекомендуется указывать 2. Условие, вложенное в условие, вложенное в цикл, вложенный в условие, вложенное в цикл - мозг не сломался, не? Разбить на маленькие приватные методы для упрощения читаемости. 3. Если у тебя везде такой код, не предлагай мне его ревьюить, такой код в нашей платформе я бы ни за что не пропустил. Добавлю: насчет переменных в одном месте - ты точно не путаешь их с полями класса? Потому как поля класса должны быть в одном месте, а вот переменные должны быть рядом с местами, где используются. Основной посыл в том, что код метода должен в идеале читаться как книга - сверху вниз. А как это так получится, если ты все переменные метода соберешь в начале метода?

Ёшки-матрёшки! А говорил, что "Чистый код" прочитал...

Ты можешь сделать поиск по луа формуле, в которой делать преобразование полученного числа в строку и проверки наличия в строке 0001. Только, боюсь, это будет дико медленный поиск.

1. Картинки надо убирать под спойлер. 2. Тема названа не по правилам 3. На картинках ничего не видно. По первым двум пунктам на первый раз устное предупреждение.

Урок на канале по взлому шифрованных значений смотрел? Картинки битые, если что.

Расскажи, как взламывал, какие методы поиска значений использовал, на основании чего пришел к выводу, что в игре присутствует шифрование значений. Максимально подробно, пожалуйста. PS. Если речь об игре ВКонтакте (или другой социальной сети), скорее всего, значения, которые ты пытаешься взломать, хранятся на сервере.

Тут вариантов, на самом деле, много, как и в любой айтишной задаче. Я бы, наверное, в таком случае сделал бы какой-нибудь менеджер ресурсов, ответственностью которого было бы как раз предоставлять доступ к ресурсам и их потокобезопасное изменение. В случае с GUI винды уже давно всё придумано - у главного потока есть цикл обработки сообщений, в него и приходят сообщения от разных контролов. И есть глобальная очередь системных сообщений. Смотри, это нормально, когда классы внутри твоей библиотеки свободно общаются между собой. Но не забывай про инкапсуляцию - клиенты, то есть, те, кто будут пользоваться библиотекой, не должны иметь доступ в ее кишки. Наружу должны торчать только внятные API. Например, клиент хочет изменить размеры окна - ему неважно, как это делается внутри средствами системы или библиотеки - ему важно, чтобы у него был способ, то есть, какой-то метод, который можно вызвать, и библиотека сделает нужную работу. Исходя из вышесказанного - у тебя классы могут быть френдами внутри библиотеки, но то, что ты выставляешь на показ (для использования снаружи), должно быть четко регламентировано и иметь свои границы доступа. Если не понятно, скажи, постараюсь объяснить это на каком-нибудь конкретном примере. Есть и желание, и интерес, но не уверен, что смогу выделить на это много времени. В любом случае, постепенно отсматривать, конечно же, буду, и, если хочешь, будем проводить что-то вроде код ревью. Мне это поможет получше вспомнить плюсы, а то я давно на них не кодил, а тебе, возможно, мои советы по конкретному коду тоже будут полезны.

Ты путаешь теплое с мягким. Акторы - это не дизайн паттерн. Это модель программирования. Многопоточность и акторы - это тоже не совсем друг про друга. Тут, скорее, при многопоточности акторная модель удобна тем, что не существует общих частей данных, а значит нет рисков словить состояние гонки. Но при этом программирование акторов несет в себе большой оверхед по количеству кода, который необходимо написать, потому к этому нужно подходить с умом. При грамотном подходе с помощью акторов можно строить очень крутые легко масштабируемые системы. Но если у тебя суть много поточности состоит именно в том, чтобы передавать/получать состояния между основным потоком и остальными - тебе за глаза хватит семафоров, мьютексов, и, на худой конец, очередей. Хэндл какого-то окна, как правило, вещь иммьютабельная, потому его спокойно можно хранить где-то в общем хранилище объектов, к которому есть доступ только на чтение у всех потоков, кроме главного (окошки порождаются в главном потоке, и их надо заносить в реестр). И еще, мне кажется, тебя захлестнуло волной новых знаний, и ты начинаешь оверинжинирить там, где это совершенно ни к чему. Постарайся пройти путь от нечеткой постановки задачи (запилить кнопку) до деталей реализации архитектуры. И не забывай, что в идеале программировать надо интерфейсами, чтобы потом можно было без проблем запиливать столько реализаций, сколько понадобится. В этом плане очень хороша книга по паттернам от "банды четырех". Ее я тоже скидывал, вот она тоже обязательна к прочтению после ознакомления с самими паттернами. В книге "банды четырех" очень хорошо показана применимость паттернов в различных ситуациях, с которыми сталкиваются кодеры. И у нее, кстати, вполне вменяемый перевод на русский, я ее как-то не так давно перечитывал, когда на русском она мне попалась. Читал вот эту редакцию https://www.litres.ru/dzhon-vlissides/priemy-obektno-orientirovannogo-proektirovaniya-patterny-proektirovaniya-16419747/

Потому что переводы, как правило, корявые. Есть книги хорошо вылизанные. Например, переводы книг серии HeadFirst - шикарнейшие книги в английском варианте, и весьма достойно переведены на русский. Одна из них, которую я всегда джунам рекомендую наравне с "Чистым кодом" от дядюшки Боба - это "Паттерны проектирования" серии HeadFirst - более крутого разжевывания паттернов для новичков я не встречал. Впрочем, я вроде эту книгу уже упоминал. Оставлю еще раз тут линк на всякий случай https://www.oreilly.com/library/view/head-first-design/0596007124/ О, у них обновленная версия появилась, надо будет глянуть https://www.oreilly.com/library/view/head-first-design/9781492077992/

Вот потому я и предлагал сначала прочитать, а потом кодить. Чтобы избежать переписывания всего уже написанного ) Впрочем, в твоем случае ты и так уже много кода написал, так что однозначно пришлось бы переписывать. Всё так, да. Обычно так и делается - есть главный поток приложения, в нем управление GUI осуществляется, а вся остальная логика - в других потоках с уведомлением GUI, или с системой событий, как во фреймворке Qt, например. Правильный Не так. Избыточные комментарии есть признак грязного кода. Потому что методы и их параметры должны иметь говорящие названия. А вот комментарии с общими назначениями классов и рекомендациями по их использованию - это правильные комментарии. И про это в книге тоже сказано (по крайней мере, в английской версии, в русской - хз, не читал).

Привет! А расскажи подробнее, как ты пытался

1. То есть (без дефиса) 2. Ты никому ничего не должен на нашем форуме 3. В свою очередь, на форуме тоже тебе никто ничего не должен 4. Если ты хочешь получить конкретный ответ, ты формулируешь вопрос максимально конкретно. 5. Сформулировал неправильно - получил неправильный ответ. 6. Штатные телепаты форума утратили способности после пандемии ковида, потому не представляется возможным угадать, что, задавая один вопрос, ты ждал ответ на другой.