Это не список, и не массив, это гибрид, потому что в пределах блока мы все же имеем возможность произвольного доступа за O(1) — это означает, например, что мы можем производить поиск разбиением пополам внутри блока так же быстро, как на массиве.
This is a classical example:
public int max(int a, int b) {
if (a > b) {
return a;
}
return b;
}
И пример «хорошего подхода»:
This is the code in a pure object-oriented world:
public int max(int a, int b) {
return new If(
new GreaterThan(a, b),
a, b
);
}
What do you think now?
Ай финк нау, что это воняет за километр и двухметровой палкой это трогать нельзя. Нельзя гордиться тем, что ты навернул 4 абстракции вместо одной стандартной конструкции. Это технопорно вида «смотри, как я умею» — интересно, но непрактично и нечитаемо. Судя по всему, остальные предложения такие же гениальные.
Логично было бы иметь универсальное data = book.serialize; и database.saveserialized(data, booktype); Или сразу наследовать объект от serializable и передавать его базе. Действительно, нафига козе баян объекту что-то вообще знать о базе данных?
А теперь вместо одного символа на очередной уровень отступа там этих символов несколько.
Я понимаю, когда при диске в 5 мегабайт писали архиваторы, чтобы сжимать пустое место и ключевые слова в исходниках. Но сегодня считать доводом «тут 2-4-8 символов, а не 1»?
Да не быстрее. Один отступ — ладно, а лесенку на 4-5 отступов тоже дятлом стучать? Табуляция применяется нередко, например при переключении приложений, при переходе по вкладкам IDE и в браузере, при сдвиге влево/вправо блока кода, а не строки.
А кто говорит про произвольный доступ? Разумеется, доступ дорогой — O(n). У разных контейнеров свои задачи, плюсы и минусы. Здесь конкретно дешевый проход насквозь, удаление и вставка. Поиск дихотомией чуть дороже чем в массиве, потому что надо сначала отобрать блок, потом делать поиск внутри массива в блоке, а количество блоков зависит не только от n, но и от самих данных, количества вставок и удалений. Т.е. под какие-то задачи — вполне себе компромисс.
Кому должен? Комикс в трех актах точно так же может быть индивидуальным.
И ещё по закорючке нельзя определить, чья это подпись
И с какой стати это должно быть необходимым? Вот договор, вот графа «Иванов:____» и прописью «Иванов» — и откуда вы знаете, эта подпись Иванову принадлежит, или это Петров написал «Иванов»? Все равно придется сличать. А уж закорючку или ФИО — без разницы.
Затем, что если вы просто напишете любую бумажку, она не будет иметь силу;
В каких-то странах, вероятно, так. Но я не о законе, а о степени защищенности: вас посадят и при подделке подписи. Но подделать подпись намного сложнее, чем сделать печать. Смысл в печати, как защите, если она изготавливается за 5 минут? Раньше был хоть смысл в написании способом оттиска названия организации и/или отдела, теперь-то элементарно впечатывается при составлении документа.
Вариант со связанными блоками (см. https://habrahabr.ru/post/308818/#comment_9779616) — если поддерживать заполненность блоков на уровне меньше 1, то сдвиг будет не более половины размера блока, который фиксирован. Или выделение новой страницы и связка ее. Поиск методом дихотомии все равно на ранних стадиях будет скакать по памяти, будть то список блоков или единый массив.
Ок, пусть в процедурном API будет в качестве примера не llgfe(abc), а ll_gfe(abc).
«abc» инкапсулировано в «LL»
Это разумеется, но там выше спор об именах был и о том-де, что сложно вспомнить, как функция называется в процедурной парадигме. К чему я и привел пример — если мы говорим о заведомо плохих именах, то никакое ООП не спасет.
ЭЦП — очень удобная вещь. У нас ЭЦП зашивается в карту-элекронный паспорт, при помощи которой можно через интернет отправить документы в органы власти, открыть-закрыть фирму, заключать сделки, иметь отношения с банками, голосовать на выборах, в конце концов.
Печать — чушь времен палеолита, зачем она вообще нужна в наше время? За 3 копейки любую стандартную печать сделают в ближайшем подвале.
Да ну? Жалко, мне этого не сказали. В детстве заморачивался на тему — а что такое подпись, зачем взрослым такая непонятная кракозябра? Надо и мне тоже придумать. Что бы такого сделать? Ну ладно, сейчас вот нарисую закорючку, и будет это моя подпись.
Вот с тех пор, с 7 лет, такая подпись и есть — закорючка.
Из тех людей, что я знаю, только у одного единственного подпись — это читаемая«собственноручно написанная фамилия, возможно, с именем или инициалами», у многих — абсолютно нерасшифровываемая муть, особенно у тех, кто с деньгами дело имеет.
Для поиска по имени нужно либо это имя помнить, либо иметь префикс (который есть далеко не у всех функций)
А с ООП не так? Имя класса и метода не надо помнить?
так же в процессе этого придется отбрасывать n-oe количество методов, которые имеют похожие имена, но к задаче не относятся
Это зависит от разбиения на модули, в общем — частность.
Так же процедурный код не предоставляет удобного способа хранения\инкапсуляции внутреннего состояния, что дополнительно нагружает разработчика и загрязняет код.
Мы говорим об интерфейсе, изначально в разрезе примера доступа к файлу и т.п. но все равно во множестве случаев внутреннее состояние в процедурном подходе точно так же инкапсулируется. Например, вы открываете файл, получаете handle, все внутренние данные скрыты за ним.
Подсказками IDE пользуюсь, всегда.
Тогда непонятно, в чем проблема поиска имени — открываем модуль, ответственный за класс функций X и смотрим список процедур. Это ничем особым не отличается от подсказки при вводе имени экземпляра класса.
Все сводится к правильному разбиению на модули и хорошим именам процедур. Если мы предполагаем, что имена могут быть плохими, не отражающими суть действия, то мы можем равно предполагать, что в ООП вместо LinkedList.First() мы будем иметь LL.f(), что ничем не лучше, чем какой-нибудь llgfe(abc)
Бегать за мамонтом — это одно. В таком движении есть практический смысл. В отличие от бега по беговой дорожке.
Нет, смысл есть — это правильные пропорции тела (меньшая нагрузка на суставы и т.п.), хорошая работа сердца и как следствие более долгие года жизни без проблем, просто в силу того, что тело заточено под мамонтов, и без них работает хуже и хуже. Так что нужна симуляция. Естественны физические нагрузки.
В данном случае «неочевидность» == «неестественность». Для человека неестественно думать неочевидным образом.
Вообще не факт. Очевидность и неочевидность может зависеть от интересов, которые у всех разные. Если человеку А что-либо очевидно, в силу того, что он интересовался вопросом, это никак не означает, что эта вещь естественна. И наоборот.
Ведь нерационально...
Еще как рационально. Было бы нерационально «при прочих равных», если бы мы сравнивали только потребление ресурсов. В то время, как в общественном транспорте у вас, например, выше риск заболеть ОРЗ в «сезон», поэтому поехать на автомобиле — рациональнее.
Точно так же и со спортом — по аналогии с вашими рассуждениями об автомобиле можно сказать, что заниматься спортом нерационально, потому это потребление энергии «впустую», тогда как я веду речь о последствиях, о рациональном использовании времени (для продления жизни, уменьшения риска специфичных заболеваний, которые отнимут большее время на лечение, сократят время жизни, особенно продуктивной и т.д.).
И пример «хорошего подхода»:
Ай финк нау, что это воняет за километр и двухметровой палкой это трогать нельзя. Нельзя гордиться тем, что ты навернул 4 абстракции вместо одной стандартной конструкции. Это технопорно вида «смотри, как я умею» — интересно, но непрактично и нечитаемо. Судя по всему, остальные предложения такие же гениальные.
козе баянобъекту что-то вообще знать о базе данных?Я понимаю, когда при диске в 5 мегабайт писали архиваторы, чтобы сжимать пустое место и ключевые слова в исходниках. Но сегодня считать доводом «тут 2-4-8 символов, а не 1»?
Тут уж как в золотом законе механики.
Верно, но при последовательном просмотре у нас все так же элементы попадают в кэш — раз, меньше выгрузки-загрузки страниц памяти — два.
Размер блока можно задать, это не вопрос.
Так-то человека можно подпоить или пригрозить оружием, это все сценарии, когда систему «пересиливают».
И с какой стати это должно быть необходимым? Вот договор, вот графа «Иванов:____» и прописью «Иванов» — и откуда вы знаете, эта подпись Иванову принадлежит, или это Петров написал «Иванов»? Все равно придется сличать. А уж закорючку или ФИО — без разницы.
В каких-то странах, вероятно, так. Но я не о законе, а о степени защищенности: вас посадят и при подделке подписи. Но подделать подпись намного сложнее, чем сделать печать. Смысл в печати, как защите, если она изготавливается за 5 минут? Раньше был хоть смысл в написании способом оттиска названия организации и/или отдела, теперь-то элементарно впечатывается при составлении документа.
Сложите эти функции по 30 модулям с префиксами — то же самое по части имен.
Ок, пусть в процедурном API будет в качестве примера не llgfe(abc), а ll_gfe(abc).
Это разумеется, но там выше спор об именах был и о том-де, что сложно вспомнить, как функция называется в процедурной парадигме. К чему я и привел пример — если мы говорим о заведомо плохих именах, то никакое ООП не спасет.
Печать — чушь времен палеолита, зачем она вообще нужна в наше время? За 3 копейки любую стандартную печать сделают в ближайшем подвале.
Вот с тех пор, с 7 лет, такая подпись и есть — закорючка.
Из тех людей, что я знаю, только у одного единственного подпись — это читаемая «собственноручно написанная фамилия, возможно, с именем или инициалами», у многих — абсолютно нерасшифровываемая муть, особенно у тех, кто с деньгами дело имеет.
Именно, ведь об этом и идет речь в статье.
Да, но если говорить о последовательном переборе, то… «жизненные реалии». Плюс дешевая вставка.
А с ООП не так? Имя класса и метода не надо помнить?
Это зависит от разбиения на модули, в общем — частность.
Мы говорим об интерфейсе, изначально в разрезе примера доступа к файлу и т.п. но все равно во множестве случаев внутреннее состояние в процедурном подходе точно так же инкапсулируется. Например, вы открываете файл, получаете handle, все внутренние данные скрыты за ним.
Тогда непонятно, в чем проблема поиска имени — открываем модуль, ответственный за класс функций X и смотрим список процедур. Это ничем особым не отличается от подсказки при вводе имени экземпляра класса.
Все сводится к правильному разбиению на модули и хорошим именам процедур. Если мы предполагаем, что имена могут быть плохими, не отражающими суть действия, то мы можем равно предполагать, что в ООП вместо LinkedList.First() мы будем иметь LL.f(), что ничем не лучше, чем какой-нибудь llgfe(abc)
Нет, смысл есть — это правильные пропорции тела (меньшая нагрузка на суставы и т.п.), хорошая работа сердца и как следствие более долгие года жизни без проблем, просто в силу того, что тело заточено под мамонтов, и без них работает хуже и хуже. Так что нужна симуляция. Естественны физические нагрузки.
Вообще не факт. Очевидность и неочевидность может зависеть от интересов, которые у всех разные. Если человеку А что-либо очевидно, в силу того, что он интересовался вопросом, это никак не означает, что эта вещь естественна. И наоборот.
Еще как рационально. Было бы нерационально «при прочих равных», если бы мы сравнивали только потребление ресурсов. В то время, как в общественном транспорте у вас, например, выше риск заболеть ОРЗ в «сезон», поэтому поехать на автомобиле — рациональнее.
Точно так же и со спортом — по аналогии с вашими рассуждениями об автомобиле можно сказать, что заниматься спортом нерационально, потому это потребление энергии «впустую», тогда как я веду речь о последствиях, о рациональном использовании времени (для продления жизни, уменьшения риска специфичных заболеваний, которые отнимут большее время на лечение, сократят время жизни, особенно продуктивной и т.д.).