Что имел в виду Рич Хики, когда сказал: «Вся эта специфика [интерфейсов / классов / типов] убивает ваше повторное использование!»

В 29 -минутном выступлении Рич Хики, посвященном размышлениям на конференции Goto « Значение ценностей », он рассказывает о накладных расходах такого языка, как Java, и делает следующее заявление: «Все эти интерфейсы убивают ваше повторное использование». Что он имеет в виду? Это правда?

В поисках ответов я наткнулся на:

• Принцип Наименьшего Знания AKA Закон Деметры, который поощряет герметичные интерфейсы API. В Википедии также перечислены некоторые недостатки.

• Кризис Имперской Одежды Кевлина Хенни, который утверждает, что использование, а не повторное использование является соответствующей целью.

• Лекция Джека Дидерича " Остановка написания классов ", в которой высказывается аргумент против чрезмерной инженерии в целом.

Понятно, что все написанное достаточно плохо будет бесполезно. Но как интерфейс хорошо написанного API предотвратит использование этого кода? В истории есть примеры того, как что-то сделано для одной цели и используется больше для чего-то другого . Но в мире программного обеспечения, если вы используете что-то для целей, для которых оно не предназначено, оно обычно ломается.

Я ищу один хороший пример хорошего интерфейса, предотвращающего законное, но непреднамеренное использование некоторого кода. Это существует? Я не могу представить это.

Не смотрел полную презентацию Рича Хикки, но если я правильно его понимаю, и, судя по тому, что он говорит о 29-минутной отметке, он, кажется, спорит о повторном использовании типов, убивающих. Он использует термин «интерфейс» свободно как синоним «именованного типа», что имеет смысл.

Если у вас есть две сущности { "name":"John" }типа Personи { "name": "Rover" }типа Dog, в Java-земле они, вероятно, не смогут взаимодействовать, если у них нет общего интерфейса или предка (например Mammal, это означает написание большего количества кода). Таким образом, интерфейсы / типы здесь «убивают ваше повторное использование»: хотя Personи Dogвыглядят одинаково, один не может использоваться взаимозаменяемо с другим, если вы не напишите дополнительный код для поддержки этого. Обратите внимание, что Хикки также шутит о проектах в Java, требующих большого количества классов («Кто здесь написал приложение Java, использующее всего 20 классов?»), Что является одним из следствий вышеприведенного.

Однако в «ориентированных на значение» языках вы не будете присваивать типы этим структурам; это просто значения, которые имеют общую структуру (в моем примере оба имеют nameполе со значением String) и поэтому могут легко взаимодействовать, например, их можно добавлять в одну коллекцию, передавать в одни и те же методы и т. д.

Подводя итог, все это, кажется, что-то о структурном равенстве против явного равенства типа / интерфейса . Если только я не пропустил что-то из частей видео, которое еще не смотрел :)

Он, скорее всего, ссылается на тот факт, что интерфейс не может быть создан. Вы не можете reuseинтерфейс. Вы можете реализовать только код, который его поддерживает, и когда вы пишете код для интерфейса, повторное использование отсутствует.

Java имеет историю предоставления структур многих API, которые принимают интерфейс в качестве аргументов, но команда, которая разработала API, никогда не реализовала широкий спектр классов, чтобы вы могли повторно использовать эти интерфейсы.

Это что-то вроде инфраструктуры GUI, в которой есть IWindowинтерфейс для диалогового окна, а затем вы можете добавить IButtonинтерфейсы для элементов управления. За исключением того, что они никогда не давали вам хороший Buttonкласс, который реализует IButton. Таким образом, вы оставили создавать свои собственные.

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

Java-разработчики начали делать это там, где выставлены только их API-уровни interfaces. Вы можете реализовать эти интерфейсы, но вы никогда не сможете повторно использовать классы от разработчика, который реализовал эти интерфейсы. Это что-то вроде плаща и кинжала в стиле API.

Я думаю, что слайд 13 в его презентации ( Ценность ценностей ) помогает понять это:

Значения

• Не нужно методы
  • Я могу отправить вам значения без кода,
    и вы в порядке

Насколько я понимаю, Хикки предполагает, что если мне нужно, скажем, удвоить значение, которое вы мне прислали, я просто напишу код, похожий на

    MyValue = Double(YourValue)

Видите ли, приведенный выше код один и тот же, независимо от того, какое значение вы отправили - идеальное повторное использование .

Теперь, как это будет выглядеть в языке, имеющем объекты и интерфейсы?

    Doublable MyValue = YourValue.Double()

о, подожди! что если YourValueне реализовать Doublable? не то, чтобы это не могло быть удвоено, это может быть идеально, но ... что если просто нет метода Double ? (что если есть метод с именем сказатьTwiceAsMuch ?)

У нас проблема. YourValue.Doubleне будет работать, его нельзя больше использовать . Согласно моему прочтению вышеупомянутого слайда, это то, что имел в виду Хикки, когда сказал: «Все эти интерфейсы убивают ваше повторное использование!»

Видите ли, интерфейсы предполагают, что объекты передаются «вместе со своими методами» вместе с кодом, который работает с ними. Чтобы использовать объекты, нужно понимать, как вызывать этот код, какой метод вызывать.

Когда ожидаемый метод отсутствует, возникает проблема, хотя семантически желаемая операция имеет смысл для объекта. Как указано в презентации, значения не нуждаются в методах («Я могу отправлять вам значения без кода, и у вас все хорошо»), что позволяет писать код, работающий с ними в общем виде.

Примечание: идея передачи значений без кода как- то напоминает мне шаблон Flyweight в ООП.

^{объект, который минимизирует использование памяти, разделяя как можно больше данных с другими подобными объектами; это способ использовать объекты в больших количествах, когда простое повторяющееся представление будет использовать недопустимый объем памяти ... Малогабаритные объекты по определению являются объектами значений . Идентичность экземпляра объекта не имеет значения, поэтому два экземпляра Flyweight одинакового значения считаются равными ...}

Использование мухи, которое я видел, как правило, следовало тому же подходу: отрывать код (методы, интерфейсы) от объектов и передавать вещи вокруг, ну, в общем , без кода значений , ожидая, что для получения кода есть средства, необходимые для работы с ними.

Это выглядит почти так же, как на слайде: «значениям не нужны методы. Я могу отправить вам значения без кода, и у вас все хорошо».

В (то есть в моем) идеальном мире классы и интерфейсы всегда описывают поведение, но факт заключается в том, что слишком часто они действительно просто описывают данные. Только вчера я смотрел видео о том, как кто-то строит так называемый BankAccountкласс, который был не чем иным, как прославленным int(действительно, он был гораздо менее полезен, чем класс int, таким образом, «убивая» повторное использование, которое я бы имел, если бы его просто оставили как int), все во имя «хорошего» дизайна. Количество кода, пота и слез, потраченных на постоянное переизобретение запутанных представлений данных, просто поражает; если вы не используете данные осмысленным образом, тогда, пожалуйста, оставьте это.

Теперь, на этой стадии, Рич Хики доволен выплеснуть ребенка водой из ванны и сказать, что мы все должны жить в стране ценностей (сосед царства существительных). Я думаю, с другой стороны, что ООП может и действительно способствует повторному использованию (и, что важно, обнаружению, которого, как мне кажется, не хватает в функциональном программировании), при разумном использовании. Если вы ищете принцип ООП, который лучше всего отражает это напряжение, я думаю, что это может быть http://c2.com/cgi/wiki?TellDontAsk (который, конечно, является близким родственником Деметры)