LINUX.ORG.RU

Повторное использование кода

 , ,


1

2

Как определяется, в какую сторону должно быть обобщение?

То есть, при решении конкретной задачи как определить, что должно быть параметром, а что — неизменяемой частью.

Например, есть задача «получить сумму от 1 до 100».

Самым быстрым решением будет

class Sum1_100
{
  int run() { return 5050; }
}

но в этом случае программист поработал за компьютер. Тривиальное решение с расчётом компьютером

class Sum1_100
{
  int run() 
  { 
    int res = 0; 
    for(int i=1; i<=100; i++) res+=i; 
    return res; 
  }
}

Но получив такую задачу, почти всегда решение выглядит примерно так:

class Sum1_n
{
  int n;
  Sum1_n(int _n = 100) { n = _n; };
  int run() 
  { 
    int res = 0; 
    for(int i=1; i<=n; i++) res+=i; 
    return res; 
  }
}

на случай, если потребуется не до 100, а до какого-то другого числа.

И вот здесь у меня вопрос: почему в «получить сумму от 1 до 100» большинство параметризуют именно 100? Посему не «сумму» (тогда параметром будет операция от 100 элементов) или не «от 1 до 100» (тогда параметром будет некая последовательность). Или вообще не всё сразу? С вызовом типа

  auto_ptr<Op> op = new GenOp(operator+, 100);
  auto_ptr<Seq> seq = new Seq(1, 100);
  auto_ptr<Apply> = new GenApply(op, seq);
  result = Main->run();

Как для произвольного алгоритма определяется, что является параметром, а что неизменяемой частью?

★★★★★

Последнее исправление: monk (всего исправлений: 2)

Ответ на: комментарий от ugoday

попытка разговаривать с финнами на суахили (а суахили много проще финского) скорее всего провалится

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

no-such-file ★★★★★
()
Последнее исправление: no-such-file (всего исправлений: 2)
Ответ на: комментарий от no-such-file

И что конкретно нужно изменить?

Перед while(true) из len получить необходимое количество повторений ch в строке дополнения.

Перед return pad + str обрезать pad до нужной длины слева или справа.

monk ★★★★★
() автор топика
Ответ на: комментарий от no-such-file

Я рад что такой умный и хороший человек как вы почтили нас своим присутствием.

ugoday ★★★★★
()
Ответ на: комментарий от monk

Для языков есть ответ: «эсперанто».

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

а если «какой язык в среднем самый простой и понятный для случайно встретившегося жителя Земли?», то английский.

Я думаю в таком случае ответ на исходный вопрос будет таким: делайте как принято в сообществе программистов на java.

ugoday ★★★★★
()
Ответ на: комментарий от no-such-file

То что в разных сообществах приняты разные методы решения задач не означает, что нет универсального метода

Что-то вроде чайника Рассела?

ugoday ★★★★★
()
Ответ на: комментарий от monk

https://github.com/jonschlinkert/pad-left не говнокод?

тот который лежит в пакете: https://github.com/stevemao/left-pad/blob/master/index.js.

ЯННП. А причём тут код который лежит в stevemao/left-pad если мы обсуждали (с твоей же подачи) jonschlinkert/pad-left. Решил переобуться в воздухе?

Впрочем jonschlinkert/pad-left ещё ужаснее.

no-such-file ★★★★★
()
Ответ на: комментарий от monk

Если мы согласились, что критерием качества является понятность для массового программиста, то да, именно так. Эстеты, конечно, будут страдать, но сами посудите, если с одной стороны элегантность и красота кода, а с другой — возможность спасти итерацию просто добавив в проект пару-тройку бродячих программистов, что выберет бизнес?

ugoday ★★★★★
()
Ответ на: комментарий от no-such-file

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

ugoday ★★★★★
()
Ответ на: комментарий от no-such-file

А причём тут код который лежит в stevemao/left-pad

Ты писал «Алгоритм чего становится другим? Вообще-то код функции leftPad при этом никак не меняется.»

если мы обсуждали (с твоей же подачи) jonschlinkert/pad-left

Ну тогда изменить строку return repeat(ch, num - str.length) + str; на правильную, которая учитывает, что количество вхождение заполнителя ch может быть не равно количеству необходимых символов.

monk ★★★★★
() автор топика

Каждый в силу своих травм опыта параметризует.

anonymous
()
Ответ на: комментарий от ugoday

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

Этот выбор надо вынести в отдельный параметр. Или класс?.. )))

Скорее - в параметр компилятора как зеркальное отражение -O

yyk ★★★★★
()
Последнее исправление: yyk (всего исправлений: 1)
Ответ на: комментарий от ugoday

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

Меня больше не бизнес, а OpenSource интересует.

monk ★★★★★
() автор топика
Ответ на: комментарий от monk

тогда изменить строку return repeat(ch, num - str.length) + str; на правильную, которая учитывает

Она и так правильная и ничего в ней менять не надо. Надо просто дать другой repeat, который будет корректно работать для ch любой длины.

no-such-file ★★★★★
()
Ответ на: комментарий от ugoday

слушать что пытаются донести окружающие

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

no-such-file ★★★★★
()
Ответ на: комментарий от no-such-file

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

https://ru.wikipedia.org/wiki/Чайник_Рассела

То что в разных сообществах приняты разные методы решения задач не означает, что нет универсального метода

Разжёвываю: никакое опровержение утверждения об отсутствии «универсального метода» не заменит доказательство его существования. Сентенция «'универсальный метод' всё равно существует, просто его никто не знает/не пользуется» ничем принципиально не отличается от «далеко в космосе болтается очень маленький фарфоровый чайник».

ugoday ★★★★★
()
Ответ на: комментарий от ugoday

Разжёвываю

Уже лучше. Я не владею телепатией, чтобы понимать, что ты думал, когда брякнул про чайник Рассела. Но всё равно плохо. Наверное ты хотел попросить предъявить какой-нибудь «универсальный метод»? Так ты же сам привёл один такой метод - формулу расчёта суммы прогрессии. Да ещё записал «универсальным способом» который понятен хоть фину, хоть индусу. А что касается программирования, то да, такой «универсальный метод» это ООП в широком смысле (со всеми своими SOLID, паттернами и т.п.).

no-such-file ★★★★★
()
Ответ на: комментарий от no-such-file

Так ты же сам привёл один такой метод - формулу расчёта суммы прогрессии.

Этот примитивный трюк вообще не имеет отношения к теме обсуждения.

А что касается программирования, то да, такой «универсальный метод» это ООП в широком смысле (со всеми своими SOLID, паттернами и т.п.).

Автор темы сомневается в этом и не он один.

ugoday ★★★★★
()
Ответ на: комментарий от monk

Это всегда будет - волков бояться - в лес не ходить. «небыдлокод» рождается в командах > 10 человек, с формальными процессами. И то можно всегда много чего улучшить.

slapin ★★★★★
()
Ответ на: комментарий от no-such-file

Надо просто дать другой repeat, который будет корректно работать для ch любой длины.

Он как раз корректно работает. Повторяет любую строку указанное число раз. А использовать вместо него (пока несуществующую) функцию, которая создаёт строку заданной длины заполняя её переданной строкой = изменить алгоритм.

А если переопределять значение слов, чтобы «алгоритм не менялся», то можно далеко зайти... Например, до того, что Библия полностью соответствует современной научной картине мира. Достаточно слова в Библии переопределить, чтобы они значили не то, что значат всегда. Как говорят трактователи «метафорически».

monk ★★★★★
() автор топика

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

Это я так обращаю внимание, что ОП вопрос - про навык, не зависящий даже от парадигмы. Распихать параметры и подзадачи по классам/интерфейсам (иначе к чему тег ооп?) - уже техническая задача и вопрос отдельный.

Если ты всё это понимал, и хотел просто обмена мнениями, то только угадывание, т.е. опыт.

anonymous
()
Ответ на: комментарий от anonymous

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

Смотря на каком лиспе.

На Common Lisp'е действительно параметризовал всё что можно. Так как язык поощряет такое: вместо констант динамические переменные-параметры, вместо функций методы CLOS, на любую ошибку достаточно описать все возможные рестарты, выберет пользователь.

На Racket внутренняя идеология YAGNI и принципы доказательности кода. То есть, если я опираюсь на какое-то свойство функции, то я не имею права позволять эту функцию переопределять произвольным образом. Если я опираюсь на то, что в переменной согласованные данные, то обязан закрыть эту переменную от возможности прямого изменения не через мои функции. Поэтому в параметры выношу только то, что действительно хочу запрашивать у пользователя и проверяю содержимое полученных параметров (через контракты).

Если ты всё это понимал, и хотел просто обмена мнениями, то только угадывание, т.е. опыт.

Я так и думал. Но предположил, что возможно я просто не прочитал какой-нибудь основополагающий курс. Ведь, например, для самоучки-программиста умение писать быстрые программы — тоже выглядит как только угадывание/опыт. Но есть теория оптимизации и О-нотация.

monk ★★★★★
() автор топика

тред не читал но....

вот мои пять копеек учитывая притянутость задачи за уши.

Например, есть задача «получить сумму от 1 до 100».
Самым быстрым решением будет

константа

но в этом случае программист поработал за компьютер. Тривиальное решение с расчётом компьютером

уволить, есть константы

Но получив такую задачу, почти всегда решение выглядит примерно так:

дать по голове, если в рамках предметной области нужна константа, если же каждый раз надо искать разную сумму от 1 до n то похвалить.

почему в «получить сумму от 1 до 100» большинство параметризуют именно 100?

потому что надо дать по голове, пусть использует константу или уберет умолчание (так как оно не очевидно)

Как для произвольного алгоритма определяется, что является параметром, а что неизменяемой частью?

исходя из удобства использования интерфейса для решения бизнесс задачи. Задача определяет форму решения, кривизна этой формы определяется кривизной рук программиста.

Noob_Linux ★★★★
()
Ответ на: тред не читал но.... от Noob_Linux

уволить, есть константы

При компиляции всё равно будет константа.

Задача определяет форму решения, кривизна этой формы определяется кривизной рук программиста.

Вот про это и тред. И про то, что кроме решения задачи, от решения ожидают гибкости и расширяемости. По крайней мере так говорят апологеты ООП. «ООП дает возможность создавать расширяемые системы (extensible systems). Это одно из самых значительных достоинств ООП и именно оно отличает данный подход от традиционных методов программирования.» (с) Ханспетер Мессенбок

monk ★★★★★
() автор топика
Ответ на: комментарий от monk

При компиляции всё равно будет константа.

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

И про то, что кроме решения задачи, от решения ожидают гибкости и расширяемости.

Гибкость и расширяемость в ООП делается через сервисный слой и DI с интерфейсами и другие бест практис. От каждого объекта в ООП решающего какую либо бизнес задачу ожидается лишь одно - то что его с легкостью можно будет заменить на другой без find and replace. Отсюда вытекает проблема интерфейса, насколько его гибким делать, а это определяется только целесообразностью (субъективной и зависящей от конкретной бизнес задачи), внутренне же устройство сервиса это дело десятое. Собственно главный вопрос:

Как для произвольного алгоритма определяется, что является параметром, а что неизменяемой частью?

бессмысленен, так как для произвольного алгоритма параметры могут быть произвольны. Предметная область первична и она определяет переменные (они же параметры) системы. А уже из этого вытекает как будет организована архитектура.

Noob_Linux ★★★★
()
Ответ на: комментарий от Noob_Linux

есть и другие языки, в том числе и интерпретируемые.

Если взят интерпретируемый язык, то производительность уже абсолютно не важна и нужно писать как понятнее, а не неочевидной константой

Отсюда вытекает проблема интерфейса, насколько его гибким делать, а это определяется только целесообразностью (субъективной и зависящей от конкретной бизнес задачи)

Так здесь вопрос и есть в интерфейсе. Интерфейс вернуть_5050() или посчитать_сумму_от_1_до_100() или посчитать_сумму_арифметической_последовательности(1,100) или посчитать_сумму(арифметическая_последовательность(1,100)) или посчитать_результат(сумма(), арифметическая_последовательность(1,100))?

monk ★★★★★
() автор топика
Последнее исправление: monk (всего исправлений: 1)
Ответ на: комментарий от monk

Если взят интерпретируемый язык, то производительность уже абсолютно не важна и нужно писать как понятнее, а не неочевидной константой

если это не питон или рубби - важна(там быстро просто не бывает) и нет ничего более очевидного чем правильно названная константа.

Так здесь вопрос и есть в интерфейсе.

так бизнес задача какая? какой интерфейс для неё будет удобнее?

Noob_Linux ★★★★
()
Последнее исправление: Noob_Linux (всего исправлений: 2)
Ответ на: комментарий от Noob_Linux

если это не питон или рубби - важна(там быстро просто не бывает)

Какой существует интерпретируемый язык, который быстрее питона и руби?

так бизнес задача какая?

Звучит как «получить сумму от 1 до 100».

какой интерфейс для неё будет удобнее?

В этом и есть вопрос треда. Варианты в предыдущем сообщении я тебе перечислил.

monk ★★★★★
() автор топика
Ответ на: комментарий от monk

Какой существует интерпретируемый язык, который быстрее питона и руби?

Если питон и руби интерпретируемые языки, то racket тоже. И есть утверждения что он быстрее питона и тем более руби.

ЗЫ
Какой интересный тред попался на лоре.

habamax ★★★
()
Ответ на: комментарий от monk

Какой существует интерпретируемый язык, который быстрее питона и руби?

любой популярный - php, js, lua

так бизнес задача какая?

Звучит как «получить сумму от 1 до 100».

это не бизнес задача, это константа. У тебя здесь проблема.

Noob_Linux ★★★★
()
Ответ на: комментарий от monk

И про то, что кроме решения задачи, от решения ожидают гибкости и расширяемости. По крайней мере так говорят апологеты ООП.

Как это говорят только апологеты. Декомпозиция, black box, abstractions with data, вот это всё.

aedeph_ ★★
()
Ответ на: комментарий от Noob_Linux

это не бизнес задача, это константа. У тебя здесь проблема.

То есть, если тебе дадут задание, например, рассчитать среднюю зарплату по предприятию за 2017 год, то ты просто ответишь руководителю «это не задача, это константа». Так?

monk ★★★★★
() автор топика
Ответ на: комментарий от aedeph_

Декомпозиция, black box, abstractions with data, вот это всё.

Всегда ли нужна максимально возможная декомпозиция и абстракция? Если нет, то есть ли объективный критерий её нужности?

monk ★★★★★
() автор топика
Ответ на: комментарий от monk

нет. это уже бизнес задача. Есть входные данные, сотрудники и их зп. Это вещи не константные. Но из можно свести к константе(не в терминах языка) рассчитав отчет единожды.

Noob_Linux ★★★★
()
Последнее исправление: Noob_Linux (всего исправлений: 1)
Ответ на: комментарий от aedeph_

Колмогоровской сложности

Это длины архивированного кода программы без комментариев?

monk ★★★★★
() автор топика
Ответ на: комментарий от monk

Такого рода принципы (назовём их так) разбросаны по куче книжек, DRY, KISS, SOLID, YAGNI. И существуют в виде стандартов, принятых или не принятых в тех или иных местах. Может и есть какая-нибудь книжка, собирающая в себе рекомендации, когда что применять, но в моё поле зрения такая не попадала. И чтобы прямо готовый курс - тоже не видел, но и не искал. Просто не так всё гладко с методологией разработки как с алгоритмами: новые языки и паттерны появляются, а новые алгоритмы сортировки - нет (если не брать академическую тусовку, мы всё же об индустрии).

Измерять эффективность разработки сложнее, чем эффективность сортировки хотя бы чисто комбинаторно. Такое традиционно трудно формализовать (хотя, наверно, легче чем какую-нибудь историю).

Все низко висящие плоды уже сорвали: бритву Оккама придумали давно и по сути только крутят её так и сяк (DRY|KISS|...).

anonymous
()
Ответ на: комментарий от anonymous

Такого рода принципы (назовём их так) разбросаны по куче книжек,

...и воспринимаются как «101 способ похудеть».

DRY

https://habrahabr.ru/post/311014/

KISS

http://dreamsongs.com/RiseOfWorseIsBetter.html и Undefined Behaviour в дизайне Си

SOLID

https://sohabr.net/habr/post/308218/ http://russian.joelonsoftware.com/Articles/LeakyAbstractions.html

YAGNI

Тут я за, но по сути это отказ от требований к дизайну программы.

Да, ещё есть BDD, DDD, TDD, CQRS, ... но нигде нет измеримого результата. Только хайп как у очередной диеты.

Измерять эффективность разработки сложнее, чем эффективность сортировки хотя бы чисто комбинаторно. Такое традиционно трудно формализовать (хотя, наверно, легче чем какую-нибудь историю).

Вообще-то было.

  • Производительность разработки - Единицы функциональности, разрабатываемые за единицу времени. Функциональность можно измерить в единицах оценки (Functional points, Use case points) или в модифицированных логических строках кода (одно довольно точно переводится в другое).
  • Качество продукта - Плотность дефектов, т.е. количество дефектов (поведений продукта не по требованиям, как правило, после передачи заказчику) в единице функциональности.

Поломали при внедрении Agile. https://aftershock.news/?q=node/594674

бритву Оккама придумали давно

Важно помнить, что бритва Оккама не аксиома, а презумпция, то есть она не запрещает более сложные объяснения в принципе, а лишь рекомендует порядок рассмотрения гипотез, который в большинстве случаев является наилучшим.

monk ★★★★★
() автор топика
Ответ на: комментарий от monk

https://sohabr.net/habr/post/308218/

Так себе статья, ИМХО.

Про LSP:

1) Требования по ресурсам притянуто за уши. Да, для некоторого класса систем (реального времени и прочих) они являются критичными и строго заданными, т.е. входят в f(x), но для остальных — они весьма варьируемы даже в рамках одного типа. Возможно я ошибаюсь, но, по-моему, этот принцип про корректность (без включения технических требований по производительности/ресурсопотреблению/итп).

2) «Данный принцип не выполним никогда, простая замена Int32 на Int64 уже делает его не выполнимым. Надеюсь обратная замена Int64 на Int32 не вызывает ни у кого сомнений его нарушения.» Но Int64 не является подтипом Int32, равно как и наоборот, т.е. LSP тут вообще не при чём.

3) Можно было бы предположить, что популярные ООП языки строго исповедуют этот принцип и не позволяют его нарушать/обходить, т.е., если бы Java, например, строго следовала этим принципам, то там не было бы интерфейсов, методы нельзя бы было переопределять, а поля были бы только приватными. Т.е. подкласс мог бы только дополнять родительский класс новыми полями и методами, но не изменять поведение существующих. Но как тогда позволить (пере)реализовать метод в субклассе отличным от родительского способом, не нарушающим контракт? Банальная мемоизация, например, корректоность (и LSP, соответственно) не нарушает, но в этом случае не могла бы быть реализована в рамках субтипирования.

Про OCP:

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

2) «Зачем далеко ходить: C => C++ => (Java =>) C# и Java => Scala => Kotlin попытки избежать эту проблему, а не решить. Вынужденные придерживаясь это принципа Вы рано или поздно сядете и перепишите всё, если, конечно, к тому времени Ваш проект уже не протух настолько, что его закопали.» — Но ведь совершенно прямо ложиться на так любимую автором «природу», эволюцию: старые, неконкурентные виды вымирают, появляются новые с новыми, актуальными признаками. Всё «по природе».

3) «Данный принцип ставит окончательный и жирный крест на Вашем проекте в самом его начале. Используя его Вы создаете Франкенштейна, в надежде что никто не заметит трупный запах.» — Могу только пожелать автору всё время работать с проектами, которые используют инструменты, которые постоянно меняют свои интерфейсы, свой API, постоянно переписывать собственный код под эти изменения вместо расширения функциональности, вместо развития. И не забывать убеждать пользователей, что так и надо, что еженедельные обновления с постоянными изменениями UI и UX — это правильно, это «без трупного запаха».

korvin_ ★★★★★
()
Ответ на: комментарий от monk

Обобщение операций относится скорее к ФП а не Ооп. Функции типа map, reduce, функторы пришли из лиспа. Далее, нет идеальных и оптимальных для всех алгоритмов и кода. Для оптимизации прежде всего нужно определиться с тем, что оптимизируем-время выполнения, память, размер кода, деньги и время на разработку и поддержку ПО. Как правило, в реальном мире время и бюджет ограничены и кроме программиста есть аналитики, менеджеры, тимлиды и заказчики с собственными представлениями о том, какие задачи и какие сроки нужно делать. Для получения приемлемого результата придумываются всякие методологии. Бесконечное вылизывание кода возможно только в собственном 'домашнем' проекте. Но по выше указанным причинам ничто не помешает другим программистам или просто троллям объявить его говнокодом.

anonymous
()
Ответ на: комментарий от habamax

Luajit, javascript v8 самые быстрые из скриптовых. Ещё Julia c jit на llvm, некоторые реализации scheme и fort.

anonymous
()
Ответ на: комментарий от korvin_

Про LSP:

Это всё верно. Но почему же тогда в Go и Rust его выкинули (вместе с наследованием)?

Дело в том, что LSP выводит контракт-интерфейс из реализации. А значит любое расширение должно влезать в прокрустово ложе «наблюдаемого поведения». Например GtkSpinButton нарушает этот принцип, так как в его родителя GtkEntry можно ввести произвольную строку, а в GtkSpinButton только число.

Могу только пожелать автору всё время работать с проектами, которые используют инструменты, которые постоянно меняют свои интерфейсы, свой API

Вполне успешный MacOS, сменивший весь API несколько раз. Linux. И даже Microsoft после Windows XP перестала поддерживать полную совместимость API.

Из более прикладных — 1С:Предприятие. За последние 10 лет API менялось полностью трижды, а по мелочи каждый год. Но это позволило полностью перейти от прямого доступа к DBF файлам к нормальной трёхзвённой архитектуре и независимости отображения (толстый клиент, тонкий клиент, Web) от кода работающего с объектами БД.

Ну и GTK c Qt. Можешь попробовать сейчас запустить программу, написанную на первых версиях этих библиотек. Даже glibc: в qmail пришлось вносить патч, так как errno перестал быть настоящей переменной.

monk ★★★★★
() автор топика
Ответ на: комментарий от anonymous

Обобщение операций относится скорее к ФП а не Ооп.

Указатели на функции были и в Си. Упаковка функций в объекты — в Smalltalk.

Для оптимизации прежде всего нужно определиться с тем, что оптимизируем-время выполнения, память, размер кода, деньги и время на разработку и поддержку ПО

Для «хорошего кода» традиционно оптимизируем время на разработку и поддержку ПО. Иначе обобщённый код почти гарантированно проигрывает (если очень умный компилятор всё не заинлайнит).

Для получения приемлемого результата придумываются всякие методологии.

Тема про то, существует ли единая теория на этот счёт. Судя по комментариям, ответ отрицательный.

monk ★★★★★
() автор топика
Ответ на: комментарий от monk

Тема про то, существует ли единая теория на этот счёт. Судя по комментариям, ответ отрицательный.

вообще-то, Leo Brodie написал шикарную Thinking Forth в 1984г., существует русский перевод 1993г. этой замечательной книги

anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.