LINUX.ORG.RU

Посоветуйте книжку по C#

 ,


0

2

Собственно что у нас хорошего появилось? Я писал на нём когда был C# 5.0, нынче многое поменялось, добавили readonly, сильно улучшили асинхронщину, внесли кортежи и так далее. Это не могло не повлиять на то как сейчас принято писать. У Python-а есть удобные pep (PEP8, PEP20 как самые известные, которых я всегда стараюсь придерживаться), а что есть у C# взамен, чего придерживается большинство разработчиков?

Хотелось бы глянуть как на конструкции и советы когда их лучше использовать, так и что-то по принятым методикам проектирования приложений. Я сейчас пользуюсь общими соображениями, которые годятся для любого ООП языка (в основном соображениями полученными от разработки на C++ в плане проектирования, паттернов и глобальной архитектуры и немного соображениями Python-а в плане оформления ну и плюс понятно старые подходы в C# которые никуда не делись и про которые я не забыл, вроде _somePrivateField для наименования закрытых полей). Но хочется чего-то характерное для C# глянуть.

Посмотрел пока «Паттерны проектирования для C# и платформы .NET Core» но оно как на мой взгляд слишком для новичков, есть какие-то крупицы полезной для меня информации в последних главах, но оно такое, немного не то что я хотел бы в приоритете увидеть. Мне интереснее было бы почитать про хороший тон проектирования библиотек и крупных приложений (и использование в них интерфейсов - понятно что для масштабируемости в плане роста кодовой базы, множественного наследования, контроля реализации их стоит использовать).

Например, есть костыли и хаки когда через них делают группировку методов по сути, чтоб, например, обращаться к классу с сотнями методов, особенно когда в разных интерфейсах есть одинаковые названия через . По типу Human.Head.Nose.GetHP();, Вместо Human.GetNoseHP(); когда у хумана не только нос, на голове но скажем и каждая фаланга в пальцах есть. Делается это, например, через explicit interfaces но там начинаются сомнительные конструкции, которые требуют и partial class и шаманство с интерфейсами, которое далеко не в каждой книжке для нубасов описывается, да и когда-то в дремучие времена такие классы ломали mvc3 а без него, возможно, работали (не проверял но учитывая то сколько предупреждении о таких конструкциях я видел на стаковерфлоу то я не знаю либо оно не работало именно с mvc3 и работало без него, либо mvc3 построенный вокруг c#4 жил сильно дольше чем сам C# 4, но скорее первое если верить датам, например, тут, а значит это просто грязный хак), а значит это не очень хорошая практика.

Дробить классы на подклассы, которые включать в члены класса тоже такое себе, если следовать правилу что выделенный класс должен быть самостоятельным (и иметь самостоятельное время жизни к примеру), голова это не совсем самостоятельный живой организм, без тушки существовать не должна, а если и должна, например, в виде объекта в игре если её отрубили, то уже не в том виде, например глазами моргать отрубленная голова не должна и говорить тоже. Потому логично что и отдельным независимым объектом в составе человечка в игре она не должна быть.

★★★★★

Последнее исправление: peregrine (всего исправлений: 5)

Ответ на: комментарий от MoldAndLimeHoney

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

Я не спрашиваю конкретно про этот пример, я привёл его как пример спорной проблемы, про которые и хочется почитать.

peregrine ★★★★★
() автор топика
Последнее исправление: peregrine (всего исправлений: 1)
Ответ на: комментарий от ox55ff

Сейчас отформатирую. Кстати, в том же Python-е решение простое, открываешь PEP20, а там сказано что развёрнутое лучше вложенного, а значит идеология питона будет сильнее подталкивать к огромному классу со 100500 методов, чем в условной java, где обожают вложенность, одно только System.out.println чего стоит. В python-е просто print() там вложенность не любят совсем, в C# к вложенности более толерантно относятся Console.Writeline()

peregrine ★★★★★
() автор топика
Ответ на: комментарий от ox55ff

Не про юзинги я знаю. Как и про то что при желании я могу писать код следуя PEP-ам python-а (даже на C++, правда я не думаю что код на C++ они улучшат, в отличии от кода на питоне, скорее хуже сделают снизив читабельность и то что ожидается от кода на C++). Больше хочется про общую высокоуровневую философию современного C# почитать, а не про 100500 описание дженериков и как их использовать с точки зрения синтаксиса.

peregrine ★★★★★
() автор топика
Последнее исправление: peregrine (всего исправлений: 3)

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

Читать исходники хороших библиотек и крупных приложений?

theNamelessOne ★★★★★
()

Возьми любую литературу по ASP.Net свежим и почитай. Там вся архитектура вокруг DI и IoC теперь строится из коробки. Это важно, если web приложения предполагается делать.

А на ту мелочёвку, что ты описываешь - можешь не обращать внимания первое время. Остальное сильно вторично (ИМХО).

Norgat ★★★★★
()

обкуривайся выступлениями и статьями (и устаревшей tC#PLC 4th :) ) архитектора всей этой net(с где-то точкой) Хейлсберг

https://www.youtube.com/watch?v=6udlQakSXZY

https://youtu.be/2K_4T7M1DKk

https://youtu.be/JckLuXcovl8

а в целом оно ща очевидно полимультипарадигмоменеджероудобноновичнкубыстровзаимозаменяемаягалра так что кури фундамент транслируй мудрость в синтаксис шарпы

и да кури лучшие библиотеки и их сырцы - так и стиль и дух впятаешь

qulinxao3
()