 |
Аргументы функций. Приемлемое количество и качество аргументов. Побочные эффекты в функциях. Примеры
|
|
|
|
Вопрос 6
Аргументы функций. Приемлемое количество и качество аргументов. Побочные эффекты в функциях. Примеры
Аргументов функции должно быть как можно меньше. Идеальная функция без аргументов. Не допускается испытание так называемых выходных аргументов. Большое количество аргументов затрудняет тестирование функций, так как необходимо проверять большое количество случаев.
Не следует использовать так называемые аргументы флаги. Их наличие явно указывает наличие у функций более одного действия. Использование более одного параметра иногда бывает аргументировано в том случае, если эти параметры являются параметрами одного уровня абстракции.
Если функция должна получать более 2 или 3 аргументов, то в данном случае рационально использовать объект, в каждый будут упакованы некоторые из аргументов. Следует избавляться от побочных эффектов.
Пример. Функция проверяет пароль пользователя входящего в систему.
Побочный эффект создает временную привязку. А именно, функция может вызываться только в определенные моменты времени (когда инициализация сеанса может быть выполнена безопасно). Несвоевременный вызов может привести к непреднамеренной потере сеансовых данных.
Вопрос 9
Форматирование исходного кода. Цель форматирования. Вертикальное разделение концепций, вертикальное сжатие. Вертикальное расстояние
Форматирование кода направлено на передачу информации, а передача информации является первоочередной задачей профессионального разработчика. Оно улучшает удобочитаемость и как следствие сопровождаемость и расширяемость.
Вертикальное разделение концепций
|
|
|
Практически весь код читается слева направо и сверху вниз. Каждая строка представляет выражение или условие, а каждая группа строк представляет законченную мысль. Эти мысли следует отделять друг от друга пустыми строками. Это чрезвычайно простое правило оказывает глубокое воздействие на визуальную структуру кода. Каждая пустая строка становится зрительной подсказкой, указывающей на начало новой самостоятельной концепции.
Вертикальное сжатие
Если вертикальные пропуски разделяют концепции, то вертикальное сжатие подчеркивает тесные связи. Таким образом, строки кода, между которыми существует тесная связь, должны быть «сжаты» по вертикали.
Вертикальные расстояния
Концепции, тесно связанные друг с другом, должны находиться поблизости друг от друга по вертикали. Если концепции связаны тесно, то их вертикальное разделение должно показывать, насколько они важны для понимания друг друга.
Вопрос 10
Форматирование исходного кода. Цель форматирования. Горизонтальное форматирование. Горизонтальное разделение и сжатие. Отступы
Форматирование кода направлено на передачу информации, а передача информации является первоочередной задачей профессионального разработчика. Оно улучшает удобочитаемость и как следствие сопровождаемость и расширяемость.
Горизонтальное форматирование, разделение и сжатие
Горизонтальное форматирование служит для группировки взаимосвязанных компонентов и разделение разнородных. Длина строки 80-120 символов. Как правило, при горизонтальном форматировании имеют место следующие правила:
Например, Знаки «=» окружаются пробелами. Это обеспечивает их визуальное выделение. В арифметических выражениях операции с более высоким приоритетом могут пробелами не выделяться.
Не следует отделять имена функций от открывающих скобок, потому что имя функции тесно связано с ее аргументами. Пробелы изолируют их вместо того, чтобы объединять.
|
|
|
Вопрос 11
Объекты и структуры данных. Отличия процедурного и объектно-ориентированного кода. Случаи применения
Объекты отличаются от структур данных. Объекты скрывают свои данные за абстракциями и предоставляют функции, работающие с этими данными. Структуры данных раскрывают свои данные и не имеют осмысленных функций.
Возьмем процедурный пример из листинга 6. 5. Класс Geometry работает с тремя классами геометрических фигур. Классы фигур представляют собой простые структуры данных, лишенные какого-либо поведения. Все поведение сосредоточено в классе Geometry.
Листинг 6. 5. Процедурные фигуры
public class Square {
public Point topLeft;
public double side;
}
public class Rectangle {
public Point topLeft;
public double height;
public double width;
}
public class Circle {
public Point center;
public double radius;
}
public class Geometry {
public final double PI = 3. 141592653589793;
public double area(Object shape) throws NoSuchShapeException
{
if (shape instanceof Square) {
Square s = (Square)shape;
return s. side * s. side;
}
else if (shape instanceof Rectangle) {
Rectangle г = (Rectangle)shape;
return r. height * r. width;
}
else if (shape instanceof Circle) {
Circle с = (Circle)shape;
return PI * c. radius * с radius;
}
throw new NoSuchShapeExceptionO;
}
}
Теперь рассмотрим объектно-ориентированное решение из листинга 6. 6. Метод агеа() является полиморфным, класс Geometry становится лишним. Добавление новой фигуры не затрагивает ни одну из существующих функций, но при добавлении новой функции приходится изменять все фигуры.
Листинг 6. 6. Полиморфные фигуры
Polymorphic Shapes
public class Square implements Shape {
private Point topLeft;
private double side;
public double areaO {
return side*side;
}
}
public class Rectangle implements Shape {
private Point topLeft;
private double height;
private double width;
public double area О {
return height * width;
}
}
public class Circle implements Shape {
private Point center;
private double radius;
public final double PI = 3. 141592653589793;
public double areaO {
return PI * radius * radius;
}
}
Процедурный код (код, использующий структуры данных) позволяет легко добавлять новые функции без изменения существующих структур данных. Объектно - ориентированный код, напротив, упрощает добавление новых классов без изменения существующих функций.
Обратные утверждения также истинны.
Процедурный код усложняет добавление новых структур данных, потому что оно требует изменения всех функций. Объектно-ориентированный код усложняет добавление новых функций, потому что для этого должны измениться все классы.
|
|
|
Таким образом, то, что сложно в ОО, просто в процедурном программировании, а то, что сложно в процедурном программировании, просто в ОО!
|
|
|
