Есть ли какое-то общеупотребимое название функции, добавляющей новый элемент в начало списка / динамического массива?
Пока в голову приходит только push_front, по аналогии с std::deque из стандартной библиотеки C++. Может, это как-то одним словом можно элегантно обозвать?
Здравствуйте, b0r3d0m, Вы писали:
B>Есть ли какое-то общеупотребимое название функции, добавляющей новый элемент в начало списка / динамического массива?
Здравствуйте, b0r3d0m, Вы писали:
B>Есть ли какое-то общеупотребимое название функции, добавляющей новый элемент в начало списка / динамического массива?
B>Пока в голову приходит только push_front, по аналогии с std::deque из стандартной библиотеки C++. Может, это как-то одним словом можно элегантно обозвать?
Здравствуйте, b0r3d0m, Вы писали:
B>Есть ли какое-то общеупотребимое название функции, добавляющей новый элемент в начало списка / динамического массива?
B>Пока в голову приходит только push_front, по аналогии с std::deque из стандартной библиотеки C++. Может, это как-то одним словом можно элегантно обозвать?
L>P.S. push_front вполне нормален, если речь про плюсы. Другие возможные варианты: add_front, insert_front.
Конкретно сейчас речь про Lua, но я спрашиваю про общий случай.
Здравствуйте, b0r3d0m, Вы писали:
B>Есть ли какое-то общеупотребимое название функции, добавляющей новый элемент в начало списка / динамического массива?
B>Пока в голову приходит только push_front, по аналогии с std::deque из стандартной библиотеки C++. Может, это как-то одним словом можно элегантно обозвать?
Сперва нужно определение "списка" и "динамического массива". Потом посмотрев на определения, придумать "адаптер" (паттерн проектирования). Посмотреть на методы "адаптера" и дать им удобные названия.
А "список" должен быть списком, "динамический массив" — динамическим массивом. И не надо думать при их проектировании о существовании других контейнеров и какие у них есть методы.
Здравствуйте, b0r3d0m, Вы писали:
_>>И не надо думать при их проектировании о существовании других контейнеров и какие у них есть методы.
B>С чего бы?
Если по определению список никак не зависит от динамического массива, зачем при проектировании списка знать о существовании динамического массива?
А вот когда пишешь "типа обобщенный" код, которому можно подсунуть и список и динамический массив, то пишешь нужные адаптеры под эти контейнеры. И вот для этого адаптера и придумывай красивые названия для метода "вставки в начало".
Здравствуйте, fin_81, Вы писали:
_>Сперва нужно определение "списка" и "динамического массива". Потом посмотрев на определения, придумать "адаптер" (паттерн проектирования). Посмотреть на методы "адаптера" и дать им удобные названия.
Существует мнение, что начинать надо с абстрактной фабрики.
Здравствуйте, Don Reba, Вы писали:
DR>Здравствуйте, fin_81, Вы писали:
_>>Сперва нужно определение "списка" и "динамического массива". Потом посмотрев на определения, придумать "адаптер" (паттерн проектирования). Посмотреть на методы "адаптера" и дать им удобные названия.
DR>Существует мнение, что начинать надо с абстрактной фабрики.
Пора Sinix'а в тред звать. Он вам быстро объяснит, что начинать нужно со сценариев использования. И под них придумывать интерфейсы и реализацию, а не лепить сначала нечто абстрактное, а потом делать из него что-то реально полезное всякими фасадами.
Здравствуйте, Lexey, Вы писали:
L>Пора Sinix'а в тред звать. Он вам быстро объяснит, что начинать нужно со сценариев использования. И под них придумывать интерфейсы и реализацию, а не лепить сначала нечто абстрактное, а потом делать из него что-то реально полезное всякими фасадами.
Сценарии использования чего? Списка и массива в одном коде? Мне каждется здесь сам сценарий кривоват, так как для меня это слабопересекающиеся термины.
Сам по себе паттерн фассад — это попытка из бесполезного/плохого/божественного объекта сделать что-то полезное. То есть присутствие фасада — это признак плохого кода. Для данного конкретного случая, скорее всего, адаптер превратится в фасад.
Здравствуйте, fin_81, Вы писали:
_>Сценарии использования чего? Списка и массива в одном коде?
Списка и динамического массива.
_>Мне каждется здесь сам сценарий кривоват, так как для меня это слабопересекающиеся термины.
ТС свои сценарии не приводил, а что ты там себя нафантазировал, никто не знает.
ArrayList (динамический массив) и LinkedList (список) в жабе, например, реализуют один и тот же интерфейс List. И никого это сильно не смущает.
_>Сам по себе паттерн фассад — это попытка из бесполезного/плохого/божественного объекта сделать что-то полезное.
* make a software library easier to use, understand and test, since the facade has convenient methods for common tasks;
* make the library more readable, for the same reason;
* reduce dependencies of outside code on the inner workings of a library, since most code uses the facade, thus allowing more flexibility in developing the system
Где тут про бесполезное/плохое/божественное?
_>То есть присутствие фасада — это признак плохого кода. Для данного конкретного случая, скорее всего, адаптер превратится в фасад.
Признак плохого кода — это впихивание паттернов везде, где только можно.
А создание простого API (фасада) поверх сложного — это стандартный прием для серьезных библиотек, позволяющий без дублирования кода предоставлять как простой API для базовых задач, так и расширенный для продвинутых.
Вообще, я не вижу никакого смысла разделять термины "фасад" и "адаптер". Это лишь частные случаи врапера.
Остальные вряд ли поймут.
