информационная безопасность
без паники и всерьез
 подробно о проектеRambler's Top100
Все любят медSpanning Tree Protocol: недокументированное применениеЗа кого нас держат?
BugTraq.Ru
Русский BugTraq
 Анализ криптографических сетевых... 
 Модель надежности двухузлового... 
 Специальные марковские модели надежности... 
 Doom на газонокосилках 
 Умер Никлаус Вирт 
 С наступающим 
главная обзор RSN блог библиотека закон бред форум dnet о проекте
bugtraq.ru / форум / miscellaneous
Имя Пароль
ФОРУМ
все доски
FAQ
IRC
новые сообщения
site updates
guestbook
beginners
sysadmin
programming
operating systems
theory
web building
software
hardware
networking
law
hacking
gadgets
job
dnet
humor
miscellaneous
scrap
регистрация





Легенда:
  новое сообщение
  закрытая нитка
  новое сообщение
  в закрытой нитке
  старое сообщение
  • Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
  • Новичкам также крайне полезно ознакомиться с данным документом.
Я понял что они означают :-) 25.10.05 13:38  Число просмотров: 1200
Автор: amirul <Serge> Статус: The Elderman
Отредактировано 25.10.05 13:42  Количество правок: 1
<"чистая" ссылка> <обсуждение закрыто>
> 1. Первая строчка - импорт класса, вторая - вызов
> конструктора. И то и другое имеет непосредственное
> отношение к ООП. Ну да не суть важно. Первый пример кода

В том же C++ хедер можно подключить и в командной строке, и мейкфайле, и в настройках проекта для IDE. Это относится к реализации. А конструктор в том же C++ можно вызвать и неявно, простым объявлением переменной нужного типа. И это опять таки связано именно с реализацией, а не с парадигмой.

> будет работать ЗНАЧИТЕЛЬНО медленнее, чем второй, так как,
> во-первых, нам надо подключить класс (по сути считать всю
> библиотеку CGI), а во-вторых мы вызываем конструктор, на

Во первых по сравнению с расходами на САМ перл, эти расходы уже не очень значительны и опять таки они никак не связаны с ООП. В C++ информация о классах ПОЛНОСТЬЮ теряется на этапе компиляции (кроме динамического полиморфизма и RTTI, но это другая история). В конце концов код получается совершенно идентичным. Вызов метода - просто вызов функции (ей еще помимо явных аргументов передается неявный this, но это тоже особенности реализации).

> что опять же совершаются действия, да и сам вызов метода
> объекта содержит в себе много лишнего (переход по ссылке,
> определение, к какому классу пренадлежит объект и как
> завершение вызов функции, в которой единственное что
> выполняется, это return "Content-type: $_[0]", при этом
> прежде чем это будет сделано будет еще куча проверок на
> количество аргументов). Конечно, в других языках такие
> проблемы, как полная загрузка библиотеки и проверка
> количества аргументов избегаются, но потерь всё равно не
> избежать. Ты же вроде совсем недавно спорил, что писать
> нужно все максимально эффективно? ;)

Так зачем писать на перле? :-)

> 2. Насчет самокомментируемости не согласен. Прочитаю
> по-русски второй вариант:
> Вывести строку "Тип-содержимого: текст/хтмыл".
> Что непонятного? Теперь попробуй мне так же кратко описать
> на русском языке действие первого варианта. Я пытался - не

Вывести CGI хедер с типом text/html
Теперь скажи мне, что точнее отражает СУЩНОСТЬ происходящего?

> получилось. Да и потом, всегда ведь можно написать простой
> комментарий - кто мешает?

Никто не мешает, но попробуй доказать, что код который НЕ НАДО комментировать (самокомментирующийся) чем то хуже того, который надо. Сама возможность писать без комментариев говорит о том, что такой код ПОНЯТНЕЕ.

> 3. В идеале, обектная модель человеческому мышлению может
> быть и ближе. Однако она сама по себе _на много_ сложнее.
> Функцию можно определить в двух словах как "программа,
> которая может принимать параметры, возвращающая некий
> результат". Функциональный подход, если я не путаю, изучают
> еще в школе по математике классе эдак в шестом. Таким

Опять двадцать пять. Объектный подход ближе к МЫШЛЕНИЮ человека и не имеет никакого отношения к школе вообще. Да и функциональное программирование настолько же далеко от процедурного, как и объектно-ориентированное.

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

Кстати, очень хочу как нибудь выкроить время и ознакомиться с haskel, lisp, ml (ocaml). Для расширения кругозора

> рассматриваем абстрактные примеры. В программировании же не
> совсем очевидно, что консоль может быть объектом, который
> является членом какого-то непонятного класса.

Объектная декомпозиция не сложнее процедурной.

> 4. Насчет строк, массивов и переменных. Кто-то из философов
> сказал: "Не надо плодить сущности без надобности". Чтобы

Это Оккам был

> работать со всем перечисленным, надо в любом случае
> понимать, что это такое на уровне структур данных.

ЖЕЛАТЕЛЬНО. Но не обязательно. Беггинеру и вовсе не нужно

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

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

А ООП - всего лишь способ структурирования информации и уменьшения количества взаимосвязей во все возрастающих программах

> 5. В любом случае, используя объектно-ориентированный
> подход, ты не убежишь от того, что придется рано или поздно
> создавать собственные классы и методы. А это есть ни что
> иное как написание тех же функций. В случае функций ты,
> конечно, тоже к объектам придешь, но зато уже с изначальным
> умением писать собственные классы и методы. Если же знать
> ООП, но не уметь писать функции, то это уже умственный

Поговорим о сферических людях в вакууме.

> инвалид получается (кстати, если возвращаться к тому коду
> на Perl, что я привел выше, то основная масса людей
> использует именно первый способ, а не простой print, именно
> потому, что по-другому они не умеют - а из-за этого
> огромные потери и падение эффективности).

Ну насчет огромных ты погорячился. Перл все таки умеет прекомпилировать и "огромная" потеря выйдет только после первого раза. Кроме того, если в твоем случае так важна эффективность советую писать на C/C++. Выводить на stdout они умеют не хуже перла, библиотек регекспов до фига, а скорость вырастет в разы (если не на порядки).
<miscellaneous> Поиск 






Rambler's Top100
Рейтинг@Mail.ru


  Copyright © 2001-2024 Dmitry Leonov   Page build time: 0 s   Design: Vadim Derkach