Как Вы идете от абстрактного описания проекта до фактического кода?
Возможно, потому что я кодировал приблизительно два семестра теперь, но главный камень преткновения, который я имею в этой точке, преобразовывает описание проекта преподавателя и требования к фактическому коду. Так как я в настоящее время нахожусь в Алгоритмах 101, я в основном делаю восходящий процесс, начиная с пустой электронной доски и вытягиваю объект и взаимодействия метода, затем перевожу это в классы и код.
Но теперь профессор бросил интерфейсы и абстрактные классы в соединение. Интеллектуально, я могу распознать, как они работают, но блокирую мои пальцы ног, выясняющие, как использовать эти новые инструменты с текущим проектом (моделирование веб-сервера).
В моих преподавателях собственные слова, отображая абстрактное описание на код Java реальный прием. Таким образом, какие шаги лучше всего используются для движения с английского языка (или независимо от того, что язык) к машинному коду? Как Вы решаете, где и когда создать интерфейс или использовать абстрактный класс?
4 ответа
Итак, какие шаги лучше всего использовать для перехода от английского (или любого другого вашего языка) к компьютерному программированию?
Опыт - это то, что учит вас делать это. Если это еще не происходит естественным путем (и не расстраивайтесь, если это не так, потому что это занимает много времени!), Вы можете задать себе несколько вопросов:
Каковы основные концепции системы? Как они связаны друг с другом? Если бы я описывал это кому-то еще, какие слова и фразы я бы использовал? Эти мысли помогут вам решить, о каких занятиях полезно подумать.
Какое поведение у этих существ? Есть ли между ними естественные зависимости? (Например,
LineItemне актуален и не имеет смысла без контекстаOrder, равно как иEngine] часто используется безCar.) Как поведение влияет на состояние других объектов? Общаются ли они друг с другом, и если да, то каким образом? Эти мысли помогут вам разработать общедоступные интерфейсы ваших классов.
Это, конечно, только верхушка айсберга. Подробнее об этом мыслительном процессе в целом см. В превосходной книге Эрика Эванса Domain-Driven Design .
Как вы решаете, где и когда создавать интерфейс или использовать абстрактный класс?
Нет никаких жестких и быстрых предписаний; опять же, опыт - лучший гид здесь. Тем не менее, безусловно, есть некоторые практические правила, которым вы можете следовать:
Если несколько несвязанных или существенно разных типов объектов предоставляют одинаковые функциональные возможности, используйте интерфейс.Например, если интерфейс
Управляемыйимеет методУправление (вектор пеленг), может быть много разных вещей, которыми можно управлять:Лодкаs,Самолетs,CargoShips,Автомобильs и так далее. Это совершенно не связанные между собой вещи. Но все они имеют общий интерфейс - возможность управлять.В общем, старайтесь отдавать предпочтение интерфейсу, а не абстрактному базовому классу. Таким образом вы можете определить одну реализацию, реализующую N интерфейсов. В случае Java у вас может быть только один абстрактный базовый класс, поэтому вы будете привязаны к определенной иерархии наследования, как только вы скажете, что класс наследуется от другого.
Если вам не нужна реализация из базового класса, определенно отдавайте предпочтение интерфейсу, а не абстрактному базовому классу. Это также будет удобно, если вы работаете на языке, где наследование не применяется. Например, в C # вы не можете наследовать структуру
structот базового класса.
На самом деле вам следует кодировать сверху вниз, а не снизу вверх . Напишите свою основную функцию настолько ясно и кратко, насколько это возможно, используя API, которые вы еще не создали, как если бы они уже существовали. Затем вы можете реализовать эти API-интерфейсы аналогичным образом, пока не получите функции длиной всего в несколько строк. Если вы кодируете снизу вверх, вы, скорее всего, создадите множество вещей, которые вам на самом деле не нужны.
С точки зрения того, когда создавать интерфейс ... почти все должно быть интерфейсом. Когда вы используете API, которые еще не существуют, предполагайте, что каждый конкретный класс является реализацией некоторого интерфейса, и используйте объявленный тип, который указывает на этот интерфейс. Ваше наследование должно осуществляться исключительно с помощью интерфейсов. Создавайте конкретные классы только в самом низу, когда вы предоставляете реализацию. Я бы посоветовал избегать абстрактных классов и просто использовать делегирование, хотя абстрактные классы также разумны, когда две разные реализации отличаются незначительно и имеют несколько функций, которые имеют общую реализацию.Например, если ваш интерфейс позволяет выполнять итерацию по элементам, а также предоставляет функцию суммы, функция суммы является тривиальной для реализации в терминах функции итерации, так что это было бы разумным использованием абстрактного класса. В этом случае альтернативой было бы использование шаблона декоратора.
Вы также можете найти Google Techtalk « Как создать хороший API и почему это важно », чтобы быть полезным в этом отношении. Вам также может быть интересно прочитать некоторые из моих собственных наблюдений за разработкой программного обеспечения .
В общем ...
- Читайте много чужого кода. Для этого отлично подходят проекты с открытым исходным кодом. Однако уважайте их лицензии.
- Вы никогда не добьетесь совершенства. Это итеративный процесс. Не расстраивайтесь, если вы не все поняли правильно.
- Практика. Упражняться. Упражняться.
- Часто исследуйте. Продолжайте заниматься все более и более сложными проектами / дизайнами. Даже если вокруг есть легкие.
Не существует волшебной палочки или алгоритма для хорошего дизайна.
В настоящее время я использую дизайн, который считаю достойным, и работаю с ним.
Когда придет время, я пойму, что результат придется реорганизовать (переписать) раньше, чем позже.
Дайте этому проекту лучший шанс, следите за своими ошибками и как все должно было быть сделано после того, как вы получите свои результаты.
Продолжайте делать это, и все будет в порядке.
Также, на будущее, вы можете продолжать читать основы domain driven design, чтобы привести себя в соответствие с реальными сценариями - это дает прочную основу для отображения требований на реальные классы.