Вы покупаете историю повторного использования для уровня представления в MVP и его изменениях? [закрытый]
Это буквально один из самых распространенных вопросов интервью.
Ваше текущее решение имеет временную сложность O (N ^ 2) , что не хорошо, однако оно имеет пространственную сложность O (1) , которая равна хорошо.
Вот рабочая версия этого подхода:
fun findSumOfTwo(arr: IntArray, targetSum: Int): Pair {
if (arr.size < 2) return Pair(-1, -1)
var sum: Int
for (i in 0..arr.size - 2) {
for (j in i + 1..arr.size - 1) {
sum = arr[i] + arr[j]
if (sum == targetSum) {
if (arr[i] < arr[j]) {
return Pair(i, j)
}
return Pair(j, i)
}
}
}
return Pair(-1, -1)
}
После кодирования чего-то похожего на вышеизложенное ваш интервьюер, скорее всего, попросит вас оптимизировать сложность времени до O (N) , (пространственная сложность должна увеличиться до O (N) , но это нормально, временная сложность более важна в большинстве случаев).
Вы можете сделать это, используя один проход, используя HashMap :
fun findSumOfTwo(arr: IntArray, targetSum: Int): Pair {
if (arr.size < 2) return Pair(-1, -1)
var map = HashMap()
for (i in 0..arr.size - 1) {
var complement = targetSum - arr[i]
if (map.containsKey(complement)) {
var complementIndex = map.get(complement)!!
if (arr[i] < complement) {
return Pair(i, complementIndex)
}
return Pair(complementIndex, i)
}
map.put(arr[i], i)
}
return Pair(-1, -1)
}
Примечание. Эти два решения дают два предположения: 1) входной массив не отсортирован. 2) Если во входном массиве более одной действительной пары, возвращающей только одну действительную пару, то все в порядке.
10 ответов
Значение MVC/MVP действительно находится в двух различных разделениях.
Разделение между Вашим уровнем представления и Вашими моделями (однако Вы решаете реализовать их) является одной из более важной разработки программного обеспечения принципалов для чего-либо кроме простых систем. Если у Вас будут какая-либо бизнес-логика или невидимая логика в Вашем приложении, то Вы будете определенно видеть преимущества того разделения.
Разделение между уровнем представления и контроллером кажется немного менее важным для меня. В приложениях толстого клиента Вы будете редко видеть преимущество от этого разделения; в веб-фронтэндах это намного более распространено (например, ASP.NET aspx и код - позади или J2EE jspx и сервлет).
Возможно, я не полностью схватываю способ, которым Вы объяснили MVP, но я не сказал бы, что одно из преимуществ является возможностью многократного использования уровня представления - скорее я сказал бы, что основное преимущество является возможностью многократного использования моделей. Это - также одно из основных преимуществ использования любой n-tier системы. Если Вы хотите развернуть и создать новый тип фронтенда (например, WinForms, WPF, и т.д.), можно сделать так, не пытаясь разделить всю логику из веб-приложения, которое Вы просто создали.
Я думаю, что можно неправильно понимать роль или предъявителя.
Я утверждал бы, что предъявитель должен почти не иметь никакого отношения к UI, то есть, способ, которым отображена информация.
Предъявитель должен взять любой вход от UI (или сеть или winform), начать необходимую обработку на уровне контроллера и держать вывод.
UI должен иметь полный контроль над тем, как тот возврат используется.
Пример:
Позволяет говорят, что Вы вытягиваете данные из базы данных об автомобиле.
Можно передать идентификационный номер транспортного средства от UI до предъявителя, затем просят, чтобы это возвратило данные. Когда это сделает обработку, это будет содержать возвращенные данные: давайте предположим, что это имеет делание, модель, год и последняя дата регистрации.
От Вашего UI необходимо смочь отобразить это однако, Вы хотите, и это делает предъявителя допускающим повторное использование. Можно отобразить все 4 объекта на winform, но на веб-UI для мобильных телефонов можно просто отобразиться, основы (сделайте, смоделируйте, и год).
Я в согласии с chills42 - цель MVP не состоит в том, чтобы сделать предъявителя столь универсальным, что это могло использоваться с любой технологией UI. Цель состоит в том, чтобы сделать модели и (возможно) контроллеры универсальными так, чтобы можно было создать UI с любой технологией, которую Вы хотите.
Снова, могло случиться так, что я неправильно понимаю Вас, но связываю с данными, не особенно относится к Вашему вопросу (который должен сказать, что я не вижу соединение). Цель - это:
Вы разрабатываете свою прикладную логику, также известную как контроллеры (например, Когда Bob отправляет счет, система делает x, y, и z, и затем показывает Bob список счетов).
Вы разрабатываете свои бизнес-данные, также известные как модели (например, Счета, которые имеют список позиций).
Теперь, Вы задаетесь вопросом, где heck является UI? У Вас есть что-то, что знает, как вести Ваш процесс, и у Вас есть все данные, необходимо сделать это, таким образом, Вам просто нужно что-то, чтобы показать Вам, на что все это похоже. Это - то, где предъявитель входит.
Вы разрабатываете приложение WinForms.NET, которое взаимодействует через интерфейс с Вашими контроллерами и моделями. Вы делаете красивую форму, которая предоставляет Вашим пользователям способ создать счета. Затем Вы передаете все данные своим контроллерам, которые берут их, обрабатывают их с помощью моделей и затем говорят Вам, что сделать затем. Ваше приложение WinForms счастливо продолжает свой веселый (неинформированный) путь и делает то, что оно сказано, получив данные для следующей формы и отобразив его.
Затем Ваш босс входит и заявляет, "Эй, Jiho Han, это ваше приложение является общим успехом. Мне нужны Вы для создания меня приложение ASP.NET и пакетный процессор, это сделает все это, также.
Дерьмо. Он хочет Вас к какой? О, без проблем. Вы использовали MVP. Все, что необходимо сделать, создать UI ASP.NET (который следует за веб-стандартами, конечно), который будет действовать как симпатичная поверхность для всех данных. Никакая проблема - три дня - поставляют его.
Это - преимущество MVP. Вы не должны были переписывать всю свою прикладную логику; Вы не должны были писать тонны запросов для получения данных в другой формат; Вы не должны были действительно делать никакой работы. Я имею в виду, делание UIs является забавой, правильно? Теперь Вам решать, чтобы определить, думаете ли Вы, что это стоит времени, но ожидается почти в любом реальном программном обеспечении, что у Вас будет некоторое разделение этих компонентов, является ли это MVP или чем-то больше enterprisey как n-tier.
Я думаю, что Вы абсолютно правы со своим чувством "отупления".
Возможность многократного использования является одной из самых глубоких, самых темных и самых противных дыр крысы вниз, которые проект может исчезнуть, говорящий приблизительно с 15 лет опыта разработки OO, во время которого о возможности многократного использования возвестили как одна из основной пользы, которую мы будем извлекать.
Разработка для повторного использования похожа на разработку для производительности - это должен быть фоновый руководящий принцип, но в большинстве случаев, обращение слишком большого внимания впереди укорачивает Вашу трясину процесса разработки и заставляет Вас сверхобобщать все.
Моя обычная рекомендация состоит в том, чтобы реализовать самый сложный, гибкий GUI сначала и затем осуществить рефакторинг к более допускающей повторное использование, универсальной архитектуре. В зависимости от размера проекта сделайте это в прототипе с некоторыми явными целями относительно того, что Вы оцениваете. Можно затем заархивировать прототип и сохранить его при взятии извлеченных уроков и некоторый код назад к основному проекту.
Примечание: прототип при исследовании архитектуры GUI, должен использовать технологию, которую Вы намереваетесь использовать, и является глубоким и узким, а не традиционный прототип GUI, который сделан для демонстрации стиля GUI.
chills42,
Я думаю, что можно неправильно понимать роль или предъявителя.
Я полагаю, что понимаю роль предъявителя очень хорошо.
Я не сомневаюсь, что Вы, CAN делает предъявителя универсальным так, чтобы он работал на любой UI. Мой вопрос состоит в том, стоит ли это усилия при потере возможности использовать в своих интересах преимущества, которые может обеспечить определенная платформа UI.
Думайте связывая с данными на WinForms. Путем реализации определенных интерфейсов (IDataErrorInfo, INotifyPropertyChanged, IEditableObject, и т.д.) предъявитель может сделать UI что намного более простым с меньшим количеством кода. Некоторые могут сказать, привязка данных не является преимуществом - это не относится к делу. Многие из этих интерфейсов не имеют смысла к сети, хотя это, вероятно, не повреждает его. Я мог создать адаптер для WinForms для привязки данных целей. Таким образом, у меня есть другой слой. Вопрос, действительно ли это стоит усилия?
Я покупаю историю повторного использования, потому что она удалась для меня однажды, и потому что я не ожидаю подкачивать от одного типа UI к полностью другому типу для тривиальных EA.
В целом, и в Вашем случае, я ожидал бы должным быть изменять Предъявителя вполне немного. И это в порядке, это - то, для чего это там. Это - по существу адаптер между UI и Доменной логикой. И так как это помогает не допустить Доменную логику в UI, это, сделает свопинг UIs что намного легче.
О, и BTW, веб-приложения начинают становиться намного более мощными. Вам, вероятно, придется привести Вашего Предъявителя в порядок для сети!
Mike
MVC является хорошим шаблоном, чтобы использовать, даже если Вы закончите тем, что использовали его только для одного frontend. Помогает, что Вы разработать приложение с cleany разделили части. Это дает несколько преимуществ.
Это ослабевает автоматизированное тестирование частей, например, можно назвать модели непосредственно без потребности gui.
С тех пор существует чистая строка разделения свое более легкое для перепроектирования частей приложения, не взламывая другой код (например, перепроектирующий GUI).
Наличие нескольких меньших (и независимый как возможное) части, а не один большой беспорядок вещей помогает отладить.
Представление новых программистов к коду будет легче, так как они могут исследовать одну логическую часть за один раз.
Вообще говоря, MVC является хорошее OO способ разработать приложения, так как это предоставляет Вам естественный способ инкапсулировать Ваше приложение на высоком уровне.
Ed Altorfer,
Я немного смущен тем, что Вы называете контроллером.
Вы разрабатываете свою прикладную логику, также известную как контроллеры (например, Когда Bob отправляет счет, система делает x, y, и z, и затем показывает Bob список счетов).
Вы разрабатываете свои бизнес-данные, также известные как модели (например, Счета, которые имеют список позиций).
Но Вашими операторами, кажется, что контроллеры - то, что содержит прикладную логику (бизнес-логика?) и Ваши модели являются просто держателями данных.
Из того, что я понимаю, P обозначает Презентацию. P касается логики представления - как лучше всего подарить пользователю базовую бизнес-информацию. Фактическая бизнес-логика / правила была бы containe в образцовом слое. На самом деле то, что Вы называете контроллерами, также было бы частью образцового слоя - M.
В любом случае Ваш пример относительно "требовательного" босса кажется, что это является прямым из учебника - все мы знаем это. Это не то, что я обсуждаю.
Снова, если P для презентации, Ваш WinForms и сеть могут иметь совершенно другой поток для их потребностей презентации. Не говоря уже о консоли один для пакетного приложения, где Вам даже, возможно, не понадобится Слой p-типа. Привязка данных делает уровень WinForms UI настолько более простым - V - принимающий привязку данных технологических работ, как разработано. Попытайтесь сравнить источники привязки данных по сравнению с непривязкой данных приложений. В непривязке данных сценария существует больше подвижных частей, которыми необходимо управлять сами. Вы имеете больше контроля, но тем не менее необходимо управлять им. По-моему, связывая с данными вопросы к тому, как я пишу P.
Я не не соглашаюсь, что Вы, CAN заставляет один Слой p-типа работать на все виды UIs, но я боюсь при выполнении так, необходимо пойти на компромисс на наименее общем знаменателе для всего UIs. И также что Вы могли бы продвигать больше логики представления на уровень UI - который в свою очередь делает поблочное тестирование более трудным.
Я надеюсь, что разъяснил мою исходную дилемму. Я боюсь, что могу испытывать недостаток в способности выразиться соответственно...
Вы делаете прекрасное задание объяснения себя - никакие заботы.:)
Бойтесь путать прикладную логику с бизнес-логикой. Прикладная логика иногда упоминается как управление процессом приложения, которое является, вероятно, более способным названием ее. Это - в основном пользовательские действия и системные ответы. Например, Шаг 1: Пользователь входит в систему, Шаг 2: Пользователь нажимает "Create New Invoice", Step 3: Пользователь отправляет основную информацию, Шаг 4: Пользователь добавляет позиции, Шаг 5: Пользователь отправляет счет базе данных счета.
Шаги, которые я обрисовал в общих чертах ниже, являются управлением процессом, которое относится к любому UI, который Вы разработали бы для своего приложения счета. Бизнес-логика, с другой стороны, инкапсулируется в Ваших моделях. P для презентации, да, но это не для логики представления. В большинстве случаев P собирается относиться к Вашему стоящему с клиентом содержанию (например, ASPX, JSPX, представления Ruby on Rails, и т.д.) - это - строго разметка. Другими словами, Ваши контроллеры обеспечивают некоторое поведение для Вашего уровня представления.
Учитывая эти определения, можно, вероятно, видеть, как, если бы Вы создали свои контроллеры и модели правильно, они были бы полностью агностиком UI. Вы не должны были бы угождать наименьшему общему знаменателю, потому что они просто инкапсулируют Вашу логику процесса и бизнес-логику, позволяя Вашему уровню представления угодить носителю, с помощью которого Вы выставляете ту логику (например, Интернет, консоль или настольные приложения).
Как примечание стороны, иногда контроллеры и модели на самом деле выставляются некоторым другим абстрактным способом (как веб-сервисы) так, чтобы у Вас мог быть набор UIs или веб-серверов для балансировки части входящего трафика, и можно все еще усилить тот же бэкэнд.
Надежда это помогает немногому?
reuseability, предоставленный дизайном MVC, не таков, что то же представление/предъявитель может представить ту же модель/контроллер различным выводам, а скорее, различные наборы модели/контроллера могут быть представлены на общем представлении.
Система, как это назревает, вероятно, будет иметь потребность в нескольких представлениях: веб-интерфейс, настольный редактор, автоматизированный сценарий API и несколько различных моделей: Тарификация за Клиента A является порядком согласно порядку, но Клиенту B нужен он Ежеквартально клиентским отделом.