В процессе разработки новых функций в программном обеспечении, что процесс является лучшей практикойЧто приходит первым - интерфейс или класс
Если вы идете на маршрут номер 2, когда вы решите, что нужен интерфейс?
Интерфейс отображается, когда вам нужно реорганизовать общие функции из нескольких классов.
Пока у вас не будет нескольких классов с общими функциями, трудно предвидеть, каким должен быть интерфейс.
После того, как у вас есть несколько классов, гораздо проще понять, какой должен быть интерфейс, а затем вернуться и реорганизовать эти классы, чтобы правильно реализовать вновь обнаруженный интерфейс.
Некоторые люди разрабатывают множество классов на бумаге, чтобы выяснить, какие интерфейсы должны быть. Сохраняет рефакторинг реального кода. Вместо этого вы должны реорганизовать свой дизайн.
Ну, если вы действительно пройдете этап проектирования, вы также должны создать проекты для интерфейса и класса перед кодированием. Правильно?
Как правило, вам не нужен интерфейс, если вы не имеете в виду несколько классов, которые его реализуют. Итак, интерфейс будет первым.
Разве вы не пытаетесь сказать «Итак, КЛАСС пришел первым?» –
Занятия идут сначала только в валовом абстракте. –
Я бы сказал, что интерфейсы на первом месте, но они появляются, когда вы разрабатываете определенный класс/метод. Когда вы нажимаете точку, которая, как вы знаете, зависит от какого-либо другого класса/метода, используйте интерфейс для добавления зависимостей и продолжайте писать свой код. Затем вернитесь после завершения записи текущего компонента и создайте компоненты, которые реализуют необходимые вам интерфейсы.
Все зависит от ситуации ...
Когда вы знаете, в дизайн-фазе, вы будете иметь несколько классов, которые имеют один и тот же «общность», но их реализация отличается, то интерфейс приходит первым ,
Однако программное обеспечение является органическим; он постоянно развивается, поэтому я могу представить, что в некоторых случаях у вас будет класс, и через некоторое время потребуется извлечь интерфейс из этого класса.
Я бы согласился с С. Лоттом, добавив, что дизайн интерфейса «установлен в камне» после его создания.
По этой причине интерфейс не должен создаваться, пока вы не узнаете все, что, что оно будет содержать.
Любой публичный API, безусловно, будет «установлен в камне», но большинство интерфейсов, даже объявленных «общедоступными», используются только внутри проекта и могут быть легко изменены в любое время. –
Но как бы вы справились с этим при разработке совершенно нового процесса. Тем не менее, я не знаю, все типы использования, которым это будет подвергнуто. Это черновик, работа над прототипом уровня, –
В этом случае сначала создайте его реализацию, и как только вы выясните, что все, что он должен содержать, извлеките из него интерфейс. – Powerlord
Обычно я выбираю второй вариант. Напишите интерфейс класса и извлеките позже. Обычно причиной извлечения интерфейса является необходимость второй реализации этого интерфейса (часто как макет для модульного тестирования).
В конечном счете, ваша фаза проектирования должна быть выполнена до вашей фазы реализации независимо от того. Прежде чем вы начнете кодирование, вы должны иметь четкое представление о том, какие будут взаимодействия между вашими классами, и, надеюсь, ваши решения интерфейса будут очевидны из этого.
Однако, если вы уже написали класс и теперь необходимо реорганизовать его, чтобы иметь интерфейс, тогда имейте в виду, что интерфейс просто выбирает набор функций/методов, которые имеют общую цель, которая будет необходимых более чем одному классу. Если вы обнаружите, что есть несколько полезных функций с вашими другими классами, то эти методы будут хорошими кандидатами для интерфейса.
Другая часть интерфейсов, которая делает их действительно полезными, - если вы обнаружите, что есть определенные части вашего класса, которые не являются частными, но что вы хотите скрывать от некоторых других объектов, в этом случае вы можете выполнять функции вы хотите разоблачить и сделать их интерфейсом.
Я не согласен с тем, кто говорит, что вы не должны заранее проектировать. Кодеры все любят прыгать прямо в нее, а иногда и рефакторинг необходим, но сильный этап проектирования сэкономит вам огромное количество времени рефакторинга позже.
Trick вопрос! Тест идет первым. Затем выполняется реализация теста, который является классом, который уже может или не может реализовывать интерфейс. Часть выполнения тестового прохода может включать извлечение интерфейса из существующего класса, но не пытайтесь угадать, что потребуется вашему интерфейсу, прежде чем вы получите что-то, что нуждается в этом интерфейсе.
Ты собираешься с ума сойти, пытаясь понять это раньше времени - или, во всяком случае, я всегда делал это в свои дни до TDD. Решите, какие функции требуется вашему приложению, напишите тест и дайте этому руководству по тестированию, что вы делаете с вашим кодом.
Интерфейс - это действительно важная вещь для большинства классов, поскольку реализация может быть изменена в любое время, но как только что-то было предоставлено в интерфейсе, трудно или невозможно отменить ее. К остальной части проекта интерфейс имеет значение, а реализация - это чья-то проблема.
В идеале основные функции интерфейса будут указаны до начала любой работы по внедрению. (Это также хорошая идея для разработки тестов вверх.) Детали могут быть разрешены для развития, но любые изменения интерфейса должны основываться на том, что нужны другим классам и подпрограммам, а не на артефактах реализации. Реализация всегда должна определяться интерфейсом, а не наоборот.
(Так как это языковой вопрос, я предполагаю, что обсуждаемый «интерфейс» является публичной функциональностью класса, а не заменой Java для абстрактных классов C++. В C++ это быть частью определения класса с пометкой «public».)
Спасибо за партициальный отклик. Я пишу на C#, так что да, это для общедоступных функций класса. Я отметил его язык-агностик, потому что неважно, что я пишу в C#, VB (.NET или другой), Java или псевдокоде. Я пытаюсь понять, когда и почему. –
Класс должен быть первым.
Прекрасный дизайн можно определить только как красивый, поскольку он подвергается тиглу изменений. Откуда вы знаете, будут ли ваши интерфейсы выдерживать проверку времени, если они не были подделаны из кода для начала?
Я согласен с Брайаном Гатри. Тест идет первым, потому что он будет управлять вашим дизайном. Хотя обычно это означает, что вы получаете конкретный класс (тот, который вы разрабатываете, определяя его поведение в виде набора тестов), зависимости обычно будут выражаться с помощью интерфейсов (чтобы можно было насмехаться и следовать за dependency inversion principle).
Это часто означает, что у вас будут интерфейсы до того, как у вас будут занятия, но только потому, что вам нужно их раньше.
Я не знаю, что лучше, но я уверен, что правильный ответ всегда является одним из этих двух вариантов во всех контекстах!
Я хотел бы, чтобы бросить в двух разных взглядах на то, что интерфейсы являются:
Однако в обоих случаях вы проектируете сначала, а затем код.
Для новой системы я ожидал, что сначала будут определены интерфейсы кандидатов, которые позже будут реализованы классами. Для существующей системы разработка интерфейса из существующих классов происходит, когда вы обнаруживаете важный объект или точку изменения в вашей системе, где это было не так важно, прежде чем или где вам не нужно было указывать точку изменения раньше.
Что на первом месте? Необходимость в функции или реализации функции?
В моем собственном рабочем процессе интерфейс приходит сначала спонтанно. Если какой-то части моего проекта нужна новая функция, она построена вокруг того, как я хочу ее использовать, т. Е. Ее интерфейса. Затем следует реализация.
Таким образом, реализация содержит только то, что на самом деле необходимо, и ничто не тратится впустую на чрезмерную работу с блестящей бесполезной частью кода.
Интерфейсы развиваются очень плохо со временем. Всякий раз, когда вы меняете интерфейс, вы нарушаете договор. Все классы, реализующие интерфейс, должны быть реорганизованы. Чтобы оставаться обратно совместимыми разработчиками, нужно создавать креативные и дизайн IFoo2 поверх IFoo. С течением времени это становится кошмаром для обслуживания.
Обратите внимание на следующее: предпочитайте определять классы по интерфейсам. Используйте интерфейсы, если вы хотите предоставить полиморфную иерархию типов значений. Другой способ использования интерфейсов - добиться аналогичного эффекта с множественным наследованием.
Да. У меня также намного лучшая удача, извлекая «интерфейсы» (в смысле Java) из существующих классов, чем я их проектирую. Но, с другой стороны, я всегда разрабатываю индивидуальный класс изнутри - я знаю API до реализации. – emk
Поскольку я работаю на Python, нет формальных интерфейсов Java-стиля. Однако часто случается, что вам нужно поднять некоторые функции некоторых классов, чтобы определить их как видимые и важные, например, Java-интерфейс. –