Структура пространства имен/решения
Хотя я согласен с другими, что прямое использование итеративного контейнера является предпочтительным решением, я хочу указать, что стандарт C ++ гарантирует достаточную поддержку для самостоятельного решения, если вы хотите его по какой-либо причине.
А именно, вы можете наследовать от std::queue и использовать его защищенный член Container c; для доступа к begin () и end () базового контейнера (при условии, что такие методы существуют там). Вот пример, который работает в VS 2010 и , протестированный с ideone :
#include
#include
#include
template >
class iterable_queue : public std::queue
{
public:
typedef typename Container::iterator iterator;
typedef typename Container::const_iterator const_iterator;
iterator begin() { return this->c.begin(); }
iterator end() { return this->c.end(); }
const_iterator begin() const { return this->c.begin(); }
const_iterator end() const { return this->c.end(); }
};
int main() {
iterable_queue int_queue;
for(int i=0; i<10; ++i)
int_queue.push(i);
for(auto it=int_queue.begin(); it!=int_queue.end();++it)
std::cout << *it << "\n";
return 0;
}
6 ответов
Существует миллион способов освежевать кошку. Однако самый простой является всегда лучшим. Какой путь является самым простым для Вас? Зависит от Ваших требований. Но существуют некоторые общие эмпирические правила, за которыми я следую.
Во-первых, сократите общее количество проектов как можно больше. Когда Вы компилируете двадцать раз в день, который складывает дополнительная минута.
Если Ваше приложение разработано для расширяемости, рассмотрите разделение Ваших блоков вроде дизайна по сравнению с реализацией. Поместите свои интерфейсы и базовые классы в общедоступном блоке. Создайте блок для реализаций своей компанией этих классов.
Для крупных приложений разделите свою логику UI и бизнес-логику.
УПРОСТИТЕ свое решение. Если это выглядит слишком сложным, это, вероятно. Объедините, уменьшите.
Мой совет, начав подобное обязательство, не состоит в том, чтобы мучиться над пространствами имен..
Только начните разрабатывать с несколькими важными свободными инструкциями, потому что однако Вы начинаете, Ваш проект является органическим, и Вы закончите тем, что реорганизовывали пространства имен и классы со временем.
Не напрасно тратьте время, говоря слишком много о Вашем проекте. Просто сделайте это.
Я недавно испытал то же самое на работе. Много специального кода, который должен был быть структурирован и организован.
Его очень твердое сначала, так как существует так. Я думаю лучший совет, который я мог дать, должен просто инвестировать время в него на ветру вниз в пятницу днем, в течение нескольких недель, я просто выбрал бы приложение/блок кода, исследовал бы то, что было там, думайте о том, что мы могли сделать универсальным, скопировать его, поместить его в новую библиотеку везде, где я думал, что это должно быть. После того как у меня был весь код в рамках перемещенного приложения, я буду затем работать над рефакторингом рвения от общих основ.. Это иногда вызывало проблемы, которые должны были быть решены, но пока Ваше полное это не должно быть слишком большое соглашение.
Часть частью, это - единственный способ сделать это.
С точки зрения структуры я попробовал к виду имитатора пространство имен MS с тех пор по большей части ее довольно логическое (например, Компания. Данные, Компания. Сеть, Компания. Сеть. UI и так далее.
Одно из главных преимуществ является, вероятно, удаленной простофилей объема кода. Да немного рефакторинга требовалось в приложениях, но кодовая база намного более минимизирована, и во многих отношениях "более умна".
Другая вещь, которую я заметил, состоит в том, что у меня часто были бы проблемы при попытке выяснить, куда поместить материал (с точки зрения пространства имен), так как я не был уверен, чему это принадлежало. Теперь это действительно коснулось меня, я просмотрел его как таковой неприятный запах. Начиная с re-org все теперь обрушивается для интервала намного более приятно. И с (теперь очень небольшое количество) приложения specfic код, они помещаются в Компанию. Приложения. ApplicationName Это помогает мне действительно думать о бизнес-объектах намного больше, так как я не хочу слишком много в этом пространстве имен, таким образом, я придумываю более гибкие проекты.
Извините за длинное сообщение.. Это - вид быстрого движения!
Мы называем блоки в.NET следующим путем Компанией. Проект. XXXX.YYYY, где XXXX Проект и YYYYY, является подпроектом, например:
- LCP.AdmCom. Распространенный
- LCP.AdmCom. BusinessObjects
- LCP.AdmCom. Распространенный. Dal
Мы берем это от книжной Платформы вызова Руководство по проектированию Krzysztof Cwalina (Автор), Brad Abrams (Автор)
Для крупных проектов подход, который мне нравится проявлять, должен иметь одно Доменное пространство имен для моих бизнес-объектов и затем использовать Объекты Передачи данных (DTO) в моих слоях, где устройство хранения данных и извлечение бизнес-объекта необходимы. DTO является простым объектом, который не содержит бизнес-логики.
Вот ссылка, которая объясняет DTO:
Большие решения с большим количеством проектов могут вполне не спешить компилировать, но легче справиться вместе.
У меня часто есть блоки Модульного теста в том же решении как те, они тестируют, поскольку Вы склонны вносить изменения в них вместе.