Вещи, которые рассмотрят при создании платформы
Объекты маленького intgers (-5.. 256) никогда создаваемый дважды:
>>> a1 = -5; b1 = 256
>>> a2 = -5; b2 = 256
>>> id(a1) == id(a2), id(b1) == id(b2)
(True, True)
>>>
>>> c1 = -6; d1 = 257
>>> c2 = -6; d2 = 257
>>> id(c1) == id(c2), id(d1) == id(d2)
(False, False)
>>>
Редактирование: Объекты списка никогда не уничтожали (только возражает в списках). Python имеет массив, в котором он поддерживает на высоком уровне к 80 пустым спискам. При уничтожении объекта списка - Python помещает его в тот массив и когда Вы создаете новый список - Python получает последний загнанный список от этого массива:
>>> a = [1,2,3]; a_id = id(a)
>>> b = [1,2,3]; b_id = id(b)
>>> del a; del b
>>> c = [1,2,3]; id(c) == b_id
True
>>> d = [1,2,3]; id(d) == a_id
True
>>>
5 ответов
Несколько идей:
- Легче добавить полезные функции позже, чем удалять функции, которые оказались плохо спроектированными или вредными.
- Создавайте для наследования или запрещайте это : наследование вводит целый дополнительный уровень сложности, так как вам нужно проработать взаимодействия между суперклассами и подклассами. Это не значит, что это зло, но это должно быть очень тщательно продумано.
- По моему опыту, интерфейсы обычно чище, чем абстрактные классы, поскольку они способствуют композиции, а не наследованию.
- Для интерфейсов, задокументируйте, чего следует ожидать вызывающему и что следует ожидать разработчику . В основном подумайте о контракте с обеих сторон и задокументируйте его. В частности, ограничения на недействительность документа - должны ли методы принимать null или нет? Должны ли они гарантировать, что они никогда не вернут значение NULL?
- Разрабатывайте тестируемость, как вашего фреймворка, так и других, использующих ваш фреймворк. Какие части фреймворка можно разумно использовать в тестовом коде, а какие нужно смоделировать?
- Используйте свою собственную фреймворк с самого начала. Создайте образец приложения, которое другие смогут использовать для понимания структуры.
Вот как бы я поступил:
- создайте общий дизайн высокого уровня - например, веб-приложение или толстый клиент, есть ли средний уровень, как БД происходит взаимодействие, какие API / технологии будут использоваться и т. д.
- выберите функцию, которая позволит вам писать код на всех уровнях приложения (что обычно называется всплеском).
- реализуйте минимум для создания эта функция работает ( K eep I t S Imple, S tupid ) вместе с тестами, подтверждающими ее работу. 1231] выберите другую функцию goto 3 (рефакторинг по мере необходимости).
Я всегда считал, что этот способ работы развивает систему, и что на самом деле заставляя что-то работать, вы сосредотачиваете свой дизайн на том, что важно (а не на полетах фантазии, которые могут бывает с бумажным дизайном).
И я думал, что агилиста во мне больше нет; -)
Помимо общих советов по программированию, стоит изучить некоторые основы теории проектирования программных фреймворков. Для начала разберемся с понятиями «горячие точки» и «замороженные точки». Хотя это может показаться не сразу полезным, его хорошо держать в голове во время разработки.
Как всегда, хорошей отправной точкой является википедия:
http://en.wikipedia.org/wiki/Software_framework
Также хорошее резюме здесь:
http://www.acm.org/crossroads/xrds7-4/frameworks.html
Если вы хотите глубже, взгляните на цитаты в обеих этих статьях .
Некоторые из приведенных ниже советов зависят от того, создаете ли вы фреймворк исключительно для внутреннего использования небольшой командой на ограниченном наборе проектов или создаете что-то для использования многими анонимными разработчиками. Также имейте в виду, что многое зависит от размера вашего фреймворка и от того, насколько широк или узок его охват. Некоторые из моих советов действительно применимы только к более крупным многоцелевым фреймворкам.
Общий совет
- Найдите время, чтобы поговорить с некоторыми разработчиками, которые будут использовать ваш фреймворк. Убедитесь, что вы действительно понимаете, что будет полезно, а что нет.
- Найдите время, чтобы убедиться, что абстракция, которую вы создаете, понятна и интуитивно понятна вашим будущим пользователям.
- Если вы не создаете что-то уникальное и революционное, найдите время, чтобы взглянуть на другие структуры, которые существуют в вашем домене . Избегайте их ошибок, но не бойтесь заимствовать успешные концепции ... не все должно быть изобретено вами.
- Создайте документацию - как в форме формальных документов API, так и в виде примеров кода. Если люди не могут понять, как применить вашу структуру, это не удастся.
- Назовите вещи ясно, но кратко. Вероятно, это одна из самых сложных задач для разработчиков фреймворков, особенно при реализации абстрактных или обобщенных концепций. Прежде чем выбрать имя, поговорите с людьми. некоторые имена имеют несколько значений и могут интерпретироваться иначе, чем вы ожидаете.
- Рассмотрите возможность обеспечения совместимости вашей структуры с другими низкоуровневыми структурами (например, для ведения журнала, имитации и внедрения зависимостей). Это сделает ваших пользователей счастливыми и уменьшит препятствия для внедрения.
- Инвестируйте в хорошие модульные тесты. Фреймворки обычно имеют большую поверхность, с которой пользователи могут взаимодействовать ... множество классов, множество методов, производных, реализации интерфейсов. Без возможности быстрого регрессионного тестирования фреймворки могут быстро вырасти за пределы уровня, на котором их можно поддерживать.
- Делайте ваши общедоступные интерфейсы узкими и маленькими. Помните о принципе единственной ответственности при разработке функциональности в рамках ... это действительно важно на этом уровне.
Рекомендации по проектированию
- Разработка и тестирование на параллелизм. Большинство фреймворков в наши дни используются для создания приложений с некоторой (а часто и большой) параллельной обработкой. Фреймворки, предназначенные для использования в веб-приложениях, особенно нуждаются в тщательном осмыслении того, как на них повлияет многопоточный доступ. Вот некоторые общие принципы, которым я следую:
- По возможности избегайте блокировок. Когда это невозможно, используйте явные блокирующие объекты вместо операторов .NET lock (...).
- Используйте блокировки чтения / записи для общих объектов, которые читаются чаще, чем записываются.
- Создавайте функциональные возможности в слоях . Для больших фреймворков это помогает не только сохранять функциональность развязанной, но также позволяет пользователям более легко использовать только ту часть вашего фреймворка, которая им действительно нужна.
- Для фреймворков, предназначенных для использования с .NET 2.0 и выше, используйте общие коллекции! Чрезвычайно сложно понять, что хранится в объекте [], ArrayList или Hashtable ... особенно в большой структуре, где такие коллекции передаются внутри.
- Избегайте использования объекта или объекта [] в публичном доступе интерфейс ... это зло для фреймворка и основная причина ошибок и проблем с ремонтопригодностью. Вы почти всегда можете найти интерфейс или использовать вместо него дженерики. В тех редких случаях вы не можете задокументировать в точности то, что вы ожидаете передать или передать ... и утвердить для этого.
- Предпочитайте агрегирование наследованию. Хотя наследование - полезная и мощная концепция, авторы фреймворков часто злоупотребляют ею или злоупотребляют ею. Тщательно подумайте, действительно ли наследование является правильным инструментом для решения проблемы проектирования.
- По возможности избегайте приведений типов и проверок типов во время выполнения. По моему опыту, это вообще дизайнерский запах. Лот приведений указывает на то, что вы не используете эффективно интерфейсы, универсальные шаблоны или общие ограничения. Это может привести к ошибкам и путанице со стороны разработчиков относительно того, как использовать вашу структуру.
- Разрешить вызывающим абонентам внедрять функциональность, используя стратегии, когда это возможно. Для некоторых специализаций наследование является излишним. С таким уровнем функций поддержки, который получают граждане в среде .NET, вы должны использовать их (в форме лямбда-выражений или делегатов), чтобы позволить потребителям специализировать предоставляемые вами функции.
Рекомендации по реализации
- Избегайте свойств геттеры которых вызывают побочные эффекты. Иногда это неизбежно (например, геттеры, которые выполняют внутреннее кэширование или лениво создают экземпляры объектов). Однако, по моему опыту, геттеры с побочными эффектами (особенно в коде уровня фреймворка) - это самый быстрый способ ввести Heisenbugs и заставить пользователей проклинать ваше имя при отладке.
- Когда это возможно, сделать небольшие временные объекты неизменными. Обеспечьте это с помощью ключевого слова readonly (или аналогичного) на языке. Преимущества неизменяемости огромны - а в .NET (где затраты на размещение сокращены) это не так дорого, как вы могли подумать.
- По возможности используйте самоинкапсуляцию . Этот метод помогает избежать ошибок и упрощает рефакторинг, избегая разной семантики доступа к данным для внутренних и внешних вызывающих объектов.
- Избегайте магических чисел и жестко запрограммированных констант. Фреймворк - это один из типов кода, в котором очень трудно предвидеть точные потребности пользователей. Оставьте некоторую гибкость, используя конфигурацию, а не встроенные константы.
- Делайте количество параметров методов небольшим (менее 7). Когда вам нужно передать много параметров, подумайте о создании облегченного объекта данных для поддержки метода.
- Предпочитайте универсальные методы множественным перегрузкам методов для разных типов. По возможности позвольте языку и компилятору сделать эту работу. Это также позволяет сделать ваш код более гибким и полезным. Изучите структуру LINQ, чтобы понять, как это работает на практике.
Использовать интерфейсы в контрактах API. Это позволяет полностью отделить беспорядочные детали и при необходимости легко их украсить. (Просто посмотрите Свойства, которые представляют собой тонко замаскированные Карты.)
Очень хороший совет - использовать дизайн, управляемый тестированием, то есть сначала напишите тест, а затем реализацию. Это заставляет вас думать как ПОЛЬЗОВАТЕЛИ, а не дизайнер, что в конечном итоге приведет к созданию лучшего API.