В этом посте я расскажу о чистом коде: структурах данных, объектах и ​​процедурных и законе Деметры.

В этом предыдущем посте я описал, что такое Чистый код и что значит использовать осмысленные имена в своем коде. На этот раз я расскажу о структурах данных и объектах. Но подождите, мы действительно знаем их определение? Давайте посмотрим, что говорит о них Дядя Боб в своей книге Чистый код:

Объекты скрывают свои данные за абстракциями и предоставляют функции, которые работают с этими данными. Структуры данных раскрывают свои данные и не имеют значимых функций.

Легко заметить, что они противоположны. Многие программисты убеждены в том, что в разработке программного обеспечения все должно быть объектом. Если вы подумаете о природе объектов, вы увидите, что иногда вам нужны простые простые структуры данных, которыми можно манипулировать процедурным способом. Это следствие того, что добавление новых функций к объекту может потребовать гораздо больше работы, потому что, возможно, вам потребуется модифицировать все объекты одного типа, чтобы добавить новую функцию. Это дает нам следующие определения, изложенные дядей Бобом в его книге Чистый код:

Процедурный код (код, использующий структуры данных) упрощает добавление новых функций без изменения существующих структур данных. С другой стороны, объектно-ориентированный код упрощает добавление новых классов без изменения существующих функций.

Процедурный код затрудняет добавление новых структур данных, поскольку все функции должны измениться. Объектно-ориентированный код затрудняет добавление новых функций, поскольку все классы должны измениться.

Этот набор правил должен направлять нас, когда нам приходится выбирать между объектами и процедурной реализацией:

  • Вы планируете добавлять в свой код все больше и больше функций и не изменять структуры данных, которые используете? Хорошо, давайте рассмотрим процедурный код 😌
  • Вы ожидаете добавления новых типов без добавления новых функций в свой код? Ну, используйте объекты 😬.

Что касается объектно-ориентированного программирования, дядя Боб говорит о законе Деметры, согласно которому модуль не должен знать о внутренностях объектов, которыми он манипулирует. Целью этого закона является улучшение разделения объектов. Более точно его определение:

МетодfклассаCдолжен вызывать только следующие методы:

• C

объект, созданный f

объект, переданный в качестве аргумента f

объект, хранящийся в переменной экземпляра C

Это приводит нас к разговору о том, что называется крушение поезда: объединение вызовов функций/свойств. Разница между объектами и структурами данных дает нам четкое представление о том, когда крушение поезда действительно опасно:

  • если в методе вы работаете со структурами данных, к ним не применяется закон Деметры, потому что структура данных естественным образом раскрывает свою внутреннюю структуру.
  • если в методе вы работаете с объектами, то конкатенацию вызовов методов следует рассматривать как нарушение закона Деметры

В следующий раз, когда вы будете писать код, постарайтесь рассмотреть эти концепции и то, как они могут улучшить ваш код.

Первоначально опубликовано на www.fabrizioduroni.it 24 апреля 2018 г.