Исключение составляет код, реализующий сложный алгоритм с сильной математической базой. Его практически невозможно очень сложно понять, пока не прочитаешь сам алгоритм.
Если же все дробить на мельчайшие части, то объем кода сильно растет и его поддержка занимает больше времени
Не согласен. Необходимо просто дробить таким образом, чтобы взгляда на имя метода и набор параметров было достаточно для того, чтобы вспомнить, что оно делает. Тогда навигация до нужного места происходит интуитивно, без лишнего обдумывания.
«Рисование персонажа» — это одна ответственность, да. Поэтому не надо туда сваливать рисование треугольника — это уже другая ответственность :-) Понимаешь принцип?
Работа с движком — инкапсулируется в отдельный класс>
Получение простейших компонентов, таких как линии, плоскости, примитивы — все в отдельный класс, на каждый компонент — отдельный метод.
Элементарные преобразования — в отдельный класс, на каждое преобразование — отдельный метод.
Различные сложные компоненты и преобразования также по отдельным классам.
Рисование каждой части тела — в отдельный метод. Возможно, сложную часть тела типа «рука» имеет смысл разбить на зап. части, по методу на каждую.
Рисование первонажа — отдельный метод.
Как разбивать (и разбивать ли) внутри данных методов — сильно зависит от того, какой код будет получаться в итоге. Правила, которыми имеет смысл руководствоваться, давно известны и написаны, например, у Макконнелла.
public interface BaseSmth {
public int getSomeInt();
public String getSomeString();
}
public interface MySmth extends BaseSmth {
public double getSomeDouble();
}
public class BaseSmthImpl implements BaseSmth {
// get- и set-методы
}
public class MySmthImpl implements MySmth {
// get- и set-методы
}
И везде, где нужно передавать Immutable, передаем read-only интерфейс.
А насчет возможного cast-а… от кого мы защищаемся? От случайных ошибок интерфейсы прекрасно закроют, особенно если классы-имплементации сделать не public, а package. А от попытки работать с имплементациями… ну, пусть попробует, будет сам себе злобный буратино, когда что-нибудь сломается. Для этого и придуманы интерфейсы, если что.
У Макконнелла, помнится, было написано наоборот :-) Приводятся штук 10 практик по написанию хороших методов, а потом сказано, что предложенных выше методик вполне достаточно, и требование о длине методов излишне.
И я с ним согласен.
2. Комментарии к публичным методам и их параметрам.
Под публичными здесь нужно понимать не public-методы, а внешний интерфейс системы или модуля. Внутренних интерфейсов, как правило, слишком много для того, чтобы тратить время на поддержание их в чистоте и порядке.
Дублирование кода в трех местах требует переписывания.
Дублирование кода в двух местах требует переписывания, если это не приведет к излишнему усложнению.
Ага ) Вспоминаю поиск в исходниках на Ruby нужного мне метода. Который, как оказалось, создается динамически :-) И IDE с такими конструкциями ой как не дружит…
А если все это писал не ты — это покруче чем #define true (random() > 0.5).
Это «что» лучше тоже писать в коде ) например, в именах функций, методов, полей и классов.
Меня больше зацепили в статье не комментарии, за которые ухватились куча народу, а само понятие «метаинформации». Т.е. самодокументирующий код пишут нубы? Думаю, с автора (не статьи, а исходника) таки нужно взять листинг его собственного кода, и посмотреть, кто он такой.
А до какой степени все выносить в отдельные функции и классы — это уже другой вопрос
Используем давно известный принцип единой ответственности. Если есть трудности с определением, выполняет ли предложенный код одну или несколько задач, советую прочитать «Чистый код».
практически невозможноочень сложно понять, пока не прочитаешь сам алгоритм.Не согласен. Необходимо просто дробить таким образом, чтобы взгляда на имя метода и набор параметров было достаточно для того, чтобы вспомнить, что оно делает. Тогда навигация до нужного места происходит интуитивно, без лишнего обдумывания.
Как разбивать (и разбивать ли) внутри данных методов — сильно зависит от того, какой код будет получаться в итоге. Правила, которыми имеет смысл руководствоваться, давно известны и написаны, например, у Макконнелла.
public class MySmthImpl extends BaseSmthImpl implements MySmth { // get- и set-методы }public interface BaseSmth {
public int getSomeInt();
public String getSomeString();
}
public interface MySmth extends BaseSmth {
public double getSomeDouble();
}
public class BaseSmthImpl implements BaseSmth {
// get- и set-методы
}
public class MySmthImpl implements MySmth {
// get- и set-методы
}
И везде, где нужно передавать Immutable, передаем read-only интерфейс.
А насчет возможного cast-а… от кого мы защищаемся? От случайных ошибок интерфейсы прекрасно закроют, особенно если классы-имплементации сделать не public, а package. А от попытки работать с имплементациями… ну, пусть попробует, будет сам себе злобный буратино, когда что-нибудь сломается. Для этого и придуманы интерфейсы, если что.
У Макконнелла, помнится, было написано наоборот :-) Приводятся штук 10 практик по написанию хороших методов, а потом сказано, что предложенных выше методик вполне достаточно, и требование о длине методов излишне.
И я с ним согласен.
Под публичными здесь нужно понимать не public-методы, а внешний интерфейс системы или модуля. Внутренних интерфейсов, как правило, слишком много для того, чтобы тратить время на поддержание их в чистоте и порядке.
Дублирование кода в двух местах требует переписывания, если это не приведет к излишнему усложнению.
«Пишите код так, как будто сопровождать его будет склонный к насилию психопат, который знает, где вы живете» © Стив Макконнелл
Хотя времени убьешь…
А если все это писал не ты — это покруче чем #define true (random() > 0.5).
Меня больше зацепили в статье не комментарии, за которые ухватились куча народу, а само понятие «метаинформации». Т.е. самодокументирующий код пишут нубы? Думаю, с автора (не статьи, а исходника) таки нужно взять листинг его собственного кода, и посмотреть, кто он такой.
Это не плохо. Плохо обычно в том случае, когда этот код представляет собой кашу.
Используем давно известный принцип единой ответственности. Если есть трудности с определением, выполняет ли предложенный код одну или несколько задач, советую прочитать «Чистый код».