Все это поток? -- language-agnostic пол Связанный проблема

Everything is a flow?


5
vote

проблема

русский

Некоторые из моих недавних веб-проектов, над которыми я работал, используйте двигатель потока в качестве центральной абстракции в презентации и / или (более или менее) бизнес-слое. Размышляя о моем опыте, я могу честно сказать, что я не фанат о расходоменного подхода. Наоборот даже. Я вижу те же симптомы, которые появляются в проектах, которые используют потоки в качестве центральной абстракции.

    .
  • все это поток. Вы не просто начнете приложение, нет, вы "введите основной поток", даже если это просто чтобы показать меню с огромным диспетчером позади Это. Я не против потоков как таковой. Некоторые случаи использования продолжают появляться повсюду и должны быть включены в различные точки в других случаях использования (LookupCustomer, ...), но для теплицентрических людей все - это поток, даже то, что есть. .. не течет.

  • фрагментация. приложения на основе потока, как правило, имеют много кусочков логики (действия, команды, фрагменты кода для подготовки вида ...), диспергированные по всему коду. Картирование и из этих действий добавляет накладные расходы, утомительно и раздувает код. Хотя легко следовать абстрактным потоком, на самом деле выяснение того, что происходит внутри этих маленьких (или больших) кусков кода, это еще одна вещь. Хотя каждый стиль приложения позволяет людям писать плохие и непоследовательные кодовые приложения, ориентированные на то, чтобы он был особенно легко сделать.

  • config файлы. Большинство приложений используют некоторое формат XML для объявления потоков и действий, которые сопровождают изменения состояния. Язык, в котором написано приложение (скажем, Java, C #, Ruby, ...), вероятно, гораздо более богаче и выразительна, чем когда-либо формат XML. Зачем беспокоить?

  • flow> encapsulation. Если вы дадите мне компонент, который имеет определенную встроенную логику потока, то поток должен быть частью компонента, и не должен быть внешней абстракцией. Другими словами: поток является частью компонента, а компонент является самостоятельным. Это деталь. Конечно, он может быть параметризован и прочим, но компонент должен «просто работать». Люди, пишущие качели, GWT или любой жирный или богатый интерфейсный приложение, не беспокоится с явными абстракциями потока. Почему у моего веб-приложения есть один? Дайте мне схему потока Gmail.

  • (редактирование) flows - процедур. Если вы посмотрите на «богатые» модели, такие как MVC с событиями и все, потоки действительно бледят по сравнению. Вы есть , используя современный и выразительный язык для реализации вашего приложения, верно? Так что вы можете сделать лучше, чем жесткий, то, что сделайте это, то что, и что, и ... «путь со временем, когда Pundcards и ассемблер были в моде.

Примеры рамок, которые способствуют расходу, ориентированному развитию, представляют собой стойки, BTT, Spring WebFlow и JSF. Я также столкнулся с домородованными двигателями потока, построенные на верхней части обычных сервлетов.

Это также интересная статья: http: // чиль .wordpress.com / 2006/07 / 16 / On-Page-навигация /

Вы (все еще) подумайте о потоке, ориентированный подход для (передняя часть) веб-приложения - хорошая идея?

Английский оригинал

Some of my recent web projects that I worked on, use a flow engine as the central abstraction in the presentation and/or (more or less the) business layer. Reflecting on my experiences, I can honestly say that I am not a fan of the flow-centric approach. On the contrary even. I see the same symptoms pop up in projects that use flows as central abstraction.

  • Everything is a flow. You don't just start an application, no, you "enter the main flow" even if it is just to show a menu with a huge dispatcher behind it. I am not against flows as such. Some use cases keep popping up everywhere and need to be included at various points in other use cases (LookupCustomer, ...), but for flow-centric people everything is a flow, even things that are... not flows.

  • Fragmentation. Flow-based applications tend to have many pieces of logic (actions, commands, fragments of code to prepare the view...) dispersed throughout the code. Mapping in and out of these actions adds overhead, is tedious and bloats the code. Although it is easy to follow the abstract flow, actually figuring out what is happening inside these little (or big) chunks of code is another thing. While every style of application allows people to write bad and inconsistent code, flow-centric applications make it particularly easy to do so.

  • Config files. Most applications use some XML format to declare flows and actions that accompany state changes. The language in which the application is written (say Java, C#, Ruby, ...) is probably far more richer and expressive than the XML format ever will be. Why bother?

  • Flows break encapsulation. If you give me a component that has a certain embedded flow logic, then the flow should be part of the component, and should not be an external abstraction. In other words: the flow is part of the component and the component is self-contained. It is a detail. Sure, it can be parameterized and stuff, but a component should "just work". People writing a Swing, GWT, or whatever fat or rich interface application, don't bother with explicit flow abstractions. Why should my web application have one? Give me the flow diagram of GMail.

  • (Edit) Flows are procedural. If you look at "rich" patterns like MVC with events and everything, flows really pale in comparison. You are using an modern and expressive language to implement your application, right? So you can do better than the rigid "do this, then that, and that, and ..." way from the time when punchcards and assembler were in fashion.

Examples of frameworks that promote flow-centric development are Struts, BTT, Spring Webflow, and JSF. I've also come across homegrown flow engines built on top of ordinary servlets.

This is also an interesting article: http://chillenious.wordpress.com/2006/07/16/on-page-navigation/

Do you (still) think a flow-centric approach for (the front-end of) a web-application is a good idea?

</div
  
     
     

Список ответов

8
 
vote
vote
Лучший ответ
 
<Р> В общем, потоках кажется излишне enterprisey подхода к тому, что должна быть относительно простой задачей: мы хотели бы, чтобы пользователи могли принимать одну из нескольких конкретных путей через наше приложение. Более того поучительный и проницательный, чтобы исследовать почему нам нужен этот путь, чтобы произойти. Это потому, что ...
    .
  • ... мы не хотим, чтобы взаимодействовать с нашим приложением, за исключением жестко предопределенным способом? Тогда мы ограничили полезность нашего приложения, и мы делаем наше приложение намного сложнее для изменения и использования.

  • ... мы волновались о способности нашего приложения обрабатывать неожиданный ввод или сделки с государствами, мы не предполагались, если люди отклониться в глуши? Тогда это многое говорит о наших технических решений для рамок проверки.

  • ... мы не можем представить себе сценарий, кроме предопределены те, при которых кто-то будет использовать сайт? Тогда мы неявно предполагая, что только мы знаем, как лучше использовать его; мы ограничиваем возможность пользователю контролировать их взаимодействие.

<Р> Обратите внимание, как каждый из них подчеркивает о проблеме, присущие членам развития и команды приложения, и один, что это не вина пользователя. Поэтому я поддерживаю Ваше общее положение, что поток на основе подходов, как правило, имеют целый ряд вопросов. <Р> Основная проблема заключается в том, что <сильный> потоки излишне увеличивают хрупкость, что уже лучше абстрагируется другими механизмами. Например, для достижения правила, как «вам необходимо заполнить форму заказа, прежде чем подтвердить проверку» , не делают рабочий процесс; лучше <код> CustomerOrder модель, которая знает, когда он не имеет всю информацию, необходимую, чтобы позволить <код> OrderConfirmation . Если вы пытаетесь, чтобы пропустить вперед, ваша модель и контроллер должен позаботиться о отсутствии проверки на следующий <код> POST . <Р> По существу, потоки экстракта из разрозненных фрагментов каждого участвующего контроллера и собрать их в новый «регулятор потока», что это специфичный для каждого потока. Это не обязательно плохая идея, но это говорит о том, что оригинальные контроллеры могут быть принимая на себя слишком много ответственности, чтобы начать с, если что-то путь был так легко определить по отдельности. Например, если ранее был <код> OrderConfirmation , <код> CustomerOrder и <код> OrderCheckout контроллеры, и вы подумываете о <код> Order поток, чтобы связать все три вместе, <сильный>, что вы, вероятно, следует думать о является <код> Order контроллер вместо .
 

In general, flows seem to be an unnecessarily enterprisey approach to what should be a relatively simple problem: we would like to ensure that users take one of several particular paths through our application. What's more instructive and insightful is to examine why we need this path to occur. Is it because...

  • ... we don't want them to interact with our application except in rigidly predefined ways? Then we've limited the utility of our application, and we make our application much harder to change and use.

  • ... we're worried about the ability of our application to handle unexpected input or deal with states we haven't anticipated if people stray off the beaten path? Then that says a lot about our technical choices for a validation framework.

  • ... we can't envision a scenario other than the predefined ones under which someone would use the site? Then we are implicitly assuming that only we know how best to use it; we limit the ability of the user to control their interaction.

Notice how each of these underscores an issue intrinsic to the application's development and team members, and one that's not the fault of a user. So I support your general premise that flow-based approaches tend to have a number of issues.

The primary problem is that flows unnecessarily increase brittleness that is already better abstracted by other mechanisms. For example, to achieve a rule like "you need to fill out your order form before you confirm checkout", don't make a workflow; have a better CustomerOrder model that knows when it doesn't have all the information necessary to allow an OrderConfirmation. If you try to skip ahead, your model and controller should take care of failing validation on the next POST.

Essentially, flows extract out disparate fragments of each participating controller and collect them into a new "flow controller" that's specific to each flow. That's not necessarily a bad idea, but it suggests that the original controllers may have been taking on too much responsibility to begin with if that sort of path was so easy to define separately. For example, if you previously had OrderConfirmation, CustomerOrder, and OrderCheckout controllers, and you're thinking about an Order flow to link all three together, what you should probably be thinking about is an Order controller instead.

</div
 
 
   
   
1
 
vote

Я думаю, что определительные потоки полезны в веб-приложении. В ответ на ваши основные моменты:

Все это поток.

В этом нет ничего неверно, это просто имя, чтобы что-то дать. Поток может быть коротким или длинным - я согласен, что немного странно, что есть «основной» поток, который начинается все, но на самом деле не вызывает никаких проблем на практике.

Фрагментация

У вас есть некоторые действительные моменты, хотя я получаю ощущение, что самый большой вклад в это дизайн DSL. Например, Spring WebFlow V2 представляет собой огромное улучшение по SWF V1 с точки зрения читаемости и понятностью.

Файлы конфигурации

Я настоятельно не согласен с этой точкой. Я чувствую, что XML является лучшим способом выразить этот код. Если вы думаете об этом - управляющие контроллерами, представлениями, изменениями и действиями и действиями на самом деле просто «конфигурация», а не «код». И XML (на мой взгляд) - лучший способ выразить конфигурацию. Просто подумайте о слов «контроллер». Весь контроллер - это прямой и настраивает вещи - вызовы сервисов, возвратные представления и модели и т. Д. Нет необходимости в каком-либо богатстве или выражении Java, чтобы определить, что в основном просто конфигурация вашего веб-приложения.

Инкапсуляция потоков перерыв

Gmail может выразить в серии потоков. Подумайте о количестве шагов, которые необходимо составить и отправить электронную почту. Потоки действительно просто определяют проводку того, как работает приложение - уверена, что вы можете иметь ряд компонентов, которые взаимодействуют друг с другом, но способ, которым вы настраиваете их для работы вместе, по существу, поток, который вы определили в вашем приложении. Делать этот поток явным в отдельном DSL кажется хорошей идеей для меня, так как принципиально он является отдельно.

 

I think defining flows is useful in a web application. In answer to your main points:

Everything is a Flow.

There is nothing intrinsically wrong with that, it's just a name to give something. A flow can be short or long - I agree it's a bit weird that there is a "main" flow that starts everything but it doesn't really cause any problems in practice.

Fragmentation

You have some valid points here, although I get the feeling that the greatest contributor to this is the design of the DSL. For example, Spring WebFlow v2 is a vast improvement over SWF v1 in terms of readability and understandability.

Config files

I strongly disagree with this point. I feel that xml is the best way to express this code. If you think about it - managing controllers, views, state changes and actions is really just "configuration" rather than "code". And xml (in my opinion) is the best way to express configuration. Just think about the word "Controller". All a controller does is direct and configure things - call services, return views and models etc. There is no need for any richness or expressiveness of Java to define what is basically just configuration of your web application.

Flows break encapsulation

GMail could expressed in a series of flows. Think about the number of steps it takes to compose and send an email. Flows really just define the wiring of how the application works - sure you could have a number of components that interact with each other, but the way that you configure them to work together is essentially the flow you have defined in your application. Making this flow explicit in a separate DSL seems like a good idea to me, as fundamentally it is separate.

</div
 
 
1
 
vote

Первый вопрос, на который следует ответить, является ли структура потока лучшим инструментом для вашего конкретного веб-приложения. Я вентилятор весеннего веб-потока, я сам, но я использую его только в том случае, если моего веб-приложения может быть легко сломано в потоках, и если навигация должна быть плотно контролироваться. Если навигация очень свободна, где вы можете добраться до любой страницы с любой другой страницы, то SWF не правильный инструмент для задания.

Как вы упоминаете, есть и другие недостатки для Flowers Framework. Они обычно не спокойны, и, таким образом, не заблокированные. Если это конфликтует с тем, что вы хотите для вашего приложения, то SWF, вероятно, не для вас.

, что сказал, SWF, а некоторые другие рамки потока предлагают некоторые функции, которые немногие другие веб-каркасы доставляют. Это включает в себя полные решения для двойных отправных проблем и Browser Back кнопки и обработки истории. Реализация этих особенностей SWF дает некоторую дополнительную безопасность. Поскольку идентификаторы выполнения потока для каждой измените на каждой странице, поскольку используется приложение, вы получаете невосприимчивость к принудительному просмотру и некоторую защиту от подделки запроса на перекрестную площадку.

Концепция потоков довольно хорошая, на мой взгляд, поскольку потоки, как правило, отражают случаи использования. Навес данных к потоку или разговору удаляет ответственность за ее уборку от разработчика, который, я думаю, это очень хорошая вещь. Это как разница между ручным управлением памятью и сборкой мусора. Он не только делает меньше работать для меня, но это устраняет возможность внедрения ошибок, если я забуду очистить атрибуты. Одна вещь, которую я ненавидил о стойках, заключался в том, что мне нужно было дублировать мой код очистки в несколько действий, чтобы обеспечить правильность. Гораздо проще просто охватывать данные в корпус использования.

Тесты

также представляют контекст для соответствующих действий и просмотров. Если я посмотрю на файл конфигурации STRUTS-CONFIG или FACES-CONFIG, я вижу все виды навигационных правил или сопоставления действий, но для меня не существует немедленного контекста для мысленно группировки связанных предметов. Я должен вручную следить через конфигурацию, и даже тогда я застрял. С стойками мне нужно посмотреть на конкретные веб-страницы, чтобы понять, какие действия могут быть вызваны с вида.

с SWF, я могу четко видеть все действия, представления и модели, связанные с потоком. С плагинами Eclipse я вижу это как диаграмма состояния. Даже если вы не используете Eclipse, очень легко перевести определение потока на диаграмму состояния. Эти диаграммы полезны для себя, моим менеджером проекта, и, в значительной степени любого, кто хочет понять высокий уровень того, как выполняется применение. Короче говоря, связанные с кусочками, связанные с этим вместе обеспечивают более легкое понимание, а мелкая кривая обучения. Вот почему ООП настолько популярна. С веб-приложениями идея курения этих элементов вместе сформировать корпус использования, просто чувствует себя естественным.

 

The first question that should be answered is whether a flow framework is really the best tool for your specific web application. I'm a fan of Spring Web Flow, myself, but I'll only use it if my web app can easily be broken down into flows, and if navigation should be tightly controlled. If the navigation is very loose, where you can get to almost any page from any other page, then SWF isn't the right tool for the job.

As you mention, there are other drawbacks to flow frameworks. They usually aren't RESTful, and thus not bookmarkable. If that conflicts with what you want for your application, then SWF probably isn't for you.

That said, SWF, and some of the other flow frameworks, offer some features that few other web frameworks deliver. This includes complete solutions for double-submit issues and browser back button and history handling. SWF's implementation of these features lends some additional security. Since the flow execution IDs for each page change as the application is used, you get immunity to forced browsing and some protection against cross-site request forgery.

The concept of flows is quite nice, in my opinion, since flows tend to mirror use cases. Scoping data to a flow or a conversation removes the responsibility for its cleanup from the developer, which I think is a very good thing. It's like the difference between manual memory management and garbage collection. Not only does it make less work for me, but it eliminates the possibility of introducing bugs should I forget to cleanup attributes. One thing I hated about Struts was that I needed to duplicate my cleanup code in several actions to ensure correctness. It's much easier just to scope the data to the use case.

Flows also present a context for related actions and views. If I look at a struts-config or faces-config file, I can see all kinds of navigation rules or action mappings, but there is no immediate context for me to mentally group related items together. I have to manually trace through the configuration, and even then sometimes I get stuck. With Struts, I need to look at the specific web pages in order to figure out which actions can be invoked from a view.

With SWF, I can clearly see all the actions, views, and models related to a flow. With Eclipse plugins, I can see this as a state diagram. Even if you're not using eclipse, it's very easy to translate a flow definition to a state diagram. These diagrams are useful for myself, my project manager, and pretty much anyone who wants to understand the high-level of how a use case is performed. In short, chunking related things together allows for easier understanding, and a shallower learning curve. That's one reason why OOP is so popular. With web apps, the idea of chunking these elements together to form a use case just feels natural.

</div
 
 
0
 
vote

Все это поток

Все на самом деле это поток. Компьютерные программы всегда были потоком и всегда будут поток, содержащем у этих процессов:

<Сильный> ввод - & gt; Процесс - & gt; Выход

Узор дизайна MVC на самом деле соответствует этому ..

<сильный> контроллер - & gt; Модель - & gt; Просмотр

Фрагментация

Вы правы. Но я думаю, что эта «проблема» может быть уменьшена добром Support в IDES.

Файлы конфигурации

Нет сомнений, что XML - лучший способ выразить конфигурацию.

Инкапсуляция потоков перерыв

Я бы не согласился с этим. Вы можете сделать черные ящики, используя потоки, а затем использовать эти черные коробки в других потоках.

 

Everything is a flow

Everything really is a flow. Computer programs had always been a flow and will always be a flow containing of theese processes:

input -> process -> output

The MVC design pattern in fact corresponds with this..

controller -> model -> view

Fragmentation

You're right. But I think this "issue" might be reduced by a good suppport in IDEs.

Config files

There's no doubt xml is the best way to express configuration.

Flows break encapsulation

I would disagree with this. You can make black boxes using flows and then use these black boxes in another flows.

</div
 
 
     
     
0
 
vote

imho, веб-приложения лучше всего разрабатываются как независимые модули, а не модули, которые «связаны по потоку».

Поскольку большинство веб-приложений сегодня представляют собой Ajaxy Apps, имеющие независимые модули на странице многое.

Конфигурации могут быть обработаны файлами XML или JSON.

 

IMHO, web apps are best developed as independent modules rather than modules that are "bound by flow".

Since most web apps today are ajaxy apps, having independent modules on the page helps a lot.

Configurations can be handled by XML or JSON files.

</div
 
 
0
 
vote

Web 2.0 представляет серьезную проблему для понятия, что «все это поток». И когда уровень презентации полностью переносится на клиентский слой, мы вернемся к солидному и знакомую (от Guis of roore) земли обработки на основе событий.

 

Web 2.0 presents a serious challenge to the notion that "everything is a flow". And when the presentation tier is fully transposed to the client layer, we'll be back on the solid, and familiar (from GUIs of yore) ground of event based processing.

</div
 
 
0
 
vote
Тесты

возникают из-за несовпадения наследства между традиционным взаимодействием приложений и на самом деле работают веб-приложения. Потека - это просто удобный способ описать, что будет более традиционно моделировать как серию диалогов GUI (думаю, волшебник) таким образом, который совместим с тем, как веб-страницы доставляются и взаимодействуют с. Представьте, что вы будете писать традиционную программу, но каждый раз, когда пользователь управлял программой, которую вы можете отображать только одно диалоговое окно, и когда пользователь нажал «ОК» (или «Отмена» или «Далее», или « Предыдущая «) Ваша программа будет прекращена. В этой ситуации, как бы вы пошли о моделировании ожидаемого поведения программы (для дальнейшего усложнения вопросов, предположим, что многие пользователи управляют программой в разное время)? Я думаю, что вы обнаружите, что вы предпочитаете быстро прибыть на что-то похожее на потоки.

Я думаю, что, возможно, то, что вы действительно спрашиваете, - почему большинство рамок потока так легко злоупотребляют? », Что естественно приводит к следующему вопросу« Что можно сделать, чтобы исправить это? ».

 

Flows arise because of the inherit mismatch between traditional application interaction and the way web applications actually work. Flows are merely a convenient way to describe what would be more traditionally modeled as a series of GUI dialogs (think wizard) in a way that is compatible with the way in which web pages are delivered and interacted with. Imagine if you will that you were writing a traditional program, but every time the user ran the program you could only display a single dialog box, and when the user clicked "Ok" (or "Cancel", or "Next", or "Previous") your program would terminate. In that situation, how would you go about modeling the expected behavior of the program (to further complicate matters, assume many users are running the program at different times)? I think you would find you would rather quickly arrive at something similar to flows.

I think perhaps what you're really asking is, "Why are most flow frameworks so easy to abuse?", which naturally leads to the followup question "What can be done to fix that?".

</div
 
 

Связанный проблема

3  Как я могу извлечь выгоду из первой буквы каждого слова?  ( How can i capitalize the first letter of each word ) 
Мне нужен скрипт на любом языке, чтобы извлечь выгоду из первой буквы каждого слова в файле. Спасибо за все ответы. Stackoverflow Rocks! ...

0  Помощь со скоростью векторов  ( Help with velocity vectors ) 
У меня есть вектор скорости, который является V (233, 188). Это делает объект перемещаться к правой нижней стороне экрана в 300 пикселей в секунду, когда пр...

924  Какова операция IDEMPotent?  ( What is an idempotent operation ) 
Что такое операция idempotent? ...

17  Клиент хочет чрезвычайно плохо спроектированный сайт  ( Client wants extremely badly designed website ) 
Как бы вы справились с клиентом, который хочет, чтобы вы могли реализовать макет веб-сайта, который выглядит ужасно и не так во многих отношениях, когда они а...

9  Тестирование со случайными вкладами лучшие практики  ( Testing with random inputs best practices ) 
<Сильные> Примечание : Я упоминаю следующую пару абзацев в качестве фона. Если вы просто хотите TL; DR, не стесняйтесь пропустить в нумерованные вопросы, поск...

135  Что такое хорошая хеш-функция?  ( What is a good hash function ) 
Что такое хорошая хеш-функция? Я видел много хэш-функций и приложений в моих курсах структур данных в колледже, но в основном я в основном понял, что довольно...

1  Какие важные случаи ребра необходимо рассмотреть при написании алгоритмов синхронизации?  ( What important edge cases need to be considered when writing sync algorithms ) 
Синсинг часто рассматривается как сложный, погрешность, и потребляемое время, чтобы правильно обращаться. Так что для тех из вас, кто написал синхронизацию, к...

973  Странно-языковая особенность  ( Strangest language feature ) 
<в сторону CLASS = "S-NEWACTS S-WELTIVE__info JS-Post-New Imide MB16« Роль = «Статус»> заблокирован . Этот вопрос и его ответы находятся заблокиро...

2  Каковы все наиболее распространенные имена метода / переменной / классов, которые вы используете?  ( What are all the most common method variable class names that you use ) 
Наиболее распространенные имена метода / переменной / классов, которые вы часто используете, и которые объясняют вы, намерены четко и точно. Есть какой-либо ш...

9  «Различие» объекты из реляционной базы данных  ( Diffing objects from a relational database ) 
Наше приложение Win32 собирает объекты из данных в ряде таблиц в реляционной базе данных MySQL. Из такого объекта несколько изменений хранятся в базе данных. ...

33  Кластерирующий алгоритм для бумажных мальчиков  ( Clustering algorithm for paper boys ) 
Мне нужна помощь в выборе или создании алгоритма кластеризации в соответствии с определенными критериями. Представьте, что вы управляете лицами доставки газ...

0  Зачем использовать вектор для представления скорости в игре?  ( Why use a vector to represent velocity in a game ) 
Скорость = длина / время Так почему вектор (x, y, z) используется для его предложений? ...

13  Пример кода для использования камеры MAC в программе?  ( Sample code for using mac camera in a program ) 
Я хотел бы использовать камеру в моем MacBook в программе. Я довольно языковой agnostic - C, Java, Python и т. Д. Все в порядке. Может ли кто-нибудь предложит...

18  Проверка на строковое содержимое? Длина строки против пустой строки  ( Checking for string contents string length vs empty string ) 
Что более эффективно для компилятора и наилучшей практики для проверки ли строки пустой? Проверка ли длина строки == 0 Проверка ли строка пуста (strvar =...

3  Какой самый эффективный способ найти длину самого длинного предмета в списке?  ( Whats the most efficient way to find the length of the longest item in a list ) 
Учитывая список разных слов длины, какой лучший способ найти максимальную длину любых слов? Например, следующее должно вернуть 6 <код> findMaxLen("a,set,o...

Связанный проблема

3  Как я могу извлечь выгоду из первой буквы каждого слова? 
0  Помощь со скоростью векторов 
924  Какова операция IDEMPotent? 
17  Клиент хочет чрезвычайно плохо спроектированный сайт 
9  Тестирование со случайными вкладами лучшие практики 
135  Что такое хорошая хеш-функция? 
1  Какие важные случаи ребра необходимо рассмотреть при написании алгоритмов синхронизации? 
973  Странно-языковая особенность 
2  Каковы все наиболее распространенные имена метода / переменной / классов, которые вы используете? 
9  «Различие» объекты из реляционной базы данных 
33  Кластерирующий алгоритм для бумажных мальчиков 
0  Зачем использовать вектор для представления скорости в игре? 
13  Пример кода для использования камеры MAC в программе? 
18  Проверка на строковое содержимое? Длина строки против пустой строки 
3  Какой самый эффективный способ найти длину самого длинного предмета в списке? 



© 2021 www.qaru.top All Rights Reserved. Q&A House все права защищены


Licensed under cc by-sa 3.0 with attribution required.