История изменений

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

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

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