Re[22]: Огни разработки
От: IT Россия linq2db.com
Дата: 20.07.09 13:53
Оценка:
Здравствуйте, DarkGray, Вы писали:

IT>>Для яблок и квартир есть функция, через которую их можно привести к одной величине — деньгам.


DG>т.е. ты утверждаешь, что эта функция не зависит от контекста, т.е. для всех людей для всех ситуаций она одна и та же?


У неё много параметров. Она зависит от времени, от места, от состояния рынка и пр. Но главное, что эта функция есть. Я же тебя прошу показать мне такую функцию, продемонстрировать её существование, для твоих тёплого и мягкого.
Если нам не помогут, то мы тоже никого не пощадим.
Re[33]: Огни разработки
От: Silver_s Ниоткуда  
Дата: 30.07.09 19:35
Оценка:
Здравствуйте, SergH, Вы писали:
SH>Здравствуйте, DarkGray, Вы писали:
DG>>сложность изучения инкапсуляции выше, чем сложность использования 10 кейзов — потому что сложность изучения инкапсуляции — 6-8 + 3-10*6-8 = 32-80, что явно больше, чем 10

SH>сорри... Откуда эти числа и эта формула (a + b * c)?

SH>Мне, вообще, кажется, что численные оценки тут невозможны и потому неуместны, но раз ты их даёшь -- возможно ты видишь то, чего не вижу я.

Насколько сложно изучать инкапсуляцию не знаю ... открыл словарь прочитал определение и готово ...
Численные оценки инкапсуляции все же возможны(в принципе) в предельных случаях,некоторые аспкты инкапсуляции. С большей адекватностью результата чем 6-8 + 3-10*6-8 = 32-80.

Но ниже пытаюсь дать определение такому варианту инкапсуляции как условно говоря концептуальная инкапсуляция. Связь человека, понятия о решаемой проблеме, и кода (не знаю как точнее сформулировать).
Например выдергиваем кусок реального кода из проекта. Первая группа программистов(каждый по отдельности) получает задание описать этот кусок словами, наиболее кратко, но чтобы ничего не потерять. Вторая группа программистов реализует только по этому описанию новый программный код. Третья группа программистов тестирует насколько написанный код соответствует описанию.
Затем новый код(прошедший через "испорченый телефон") втыкается в проект, если ничего не сломается при замене кода, значит получилось, засчитывается.
Затем делится число букв кода на число букв словестного описания. Получается число,которым можно пользоваться.
Но при подсчете строк надо проводить статистическую обработку, чтобы выявить случаи минимального словестного описания, и соответствующие миниимальные объемы кода. И для среднестатистических случаев когда все группы программистов не знакомы заранее с кодом, имеют средние проф. навыки, и мотивированы(не дурачатся и не вредительствуют).

Примеры предельных случаев: Задача написать функцию. На входе картинка .bmp, на выходе текстовая строка написанная на картинке. Необходимо чтобы функция в 90% правильно распознавала картинки, такие как в Web на сайтах где пишут введите тект на картинке(подтвердите что человек а не робот). Заранее не известно на каком сайте будут проверять.

Вот сколько букв в описании, этого наверно достаточно. Инкапсуляция будет 1000...100000, и неизвестно получится ли вобще.

Другой случай 50 строк кода. Но нужно 200 строк текста. Придумать не трудно. Инкапсуляция меньше 1.

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

Если еще десяток трактовок инкапсуляций будет ... то тяжко прийдется. Потом на основе них какой-то объединенный коэфицент вычислять?
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.