Delphi vs C++ vs C# , ну и Java немножко, где-то ближе к старшему байту номеров страниц

Цитата KILLER @ 23.01.11, 11:36

А зачем тебе реализация? Чтобы посмотреть в каком порядке вызываются конструкторы классов, дабы не выхватить AV при использовании? Реализация хранится в *.с/*.сpp файлах, реализация шаблонов - часто располагается в *.h файлах.

Я про то, что по .h файлам тяжело находить .с/.сpp.

Цитата KILLER @ 23.01.11, 11:36

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

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

Цитата DesweR @ 23.01.11, 11:51

Я про то, что по .h файлам тяжело находить .с/.сpp.

В смысле? обычно различие заключается в расширении...

Цитата DesweR @ 23.01.11, 11:51

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

Нисколько, столько же сколько ты будешь писать initialization/finalization, а на самом деле, я на своей практике написал только 1 такую обертку, и то использовалась она не глобально(не в ваших секциях initialization/finalization) а локально в методах класса, да и писать ее пришлось в качестве костыля, потому как времени практически не оставалось, и рефакторить уже смысла небыло... А вот в делфи как я погляжу глобальные переменые практически в каждом модуле присутствуют... И после этого вы еще что то спорите об ООП ????

Добавлено 23.01.11, 12:03
А если уходить от глобальных переменных, то число написание таких оберток будет стремится к нулю
У нас на работе например, за необоснованное использование глобальных переменных отрывают руки по самые яйца... Поэтому только в очень редких случаях, и в качестве костылей, мы их все же используем... Возможно это и плохая практика, но я по этому поводу с ними полностью согласен... Потому как отлаживать код с глобальными переменными, особенно с внешними, это геморой первой степени

Сообщение отредактировано: KILLER - 23.01.11, 12:06

Цитата korvin @ 23.01.11, 05:46

Цитата D_KEY @ 22.01.11, 22:59

Зачем? Я имел в виду поменять один объект на другой.

так а при чем тут тогда модули? менять значения переменных они не мешают

Я не говорю, что они мешают. Я утверждаю, что они не нужны при ОО-декомпозиции.
Вот есть у нас объект, который реализован через GDI+, а есть который позволяет делать тоже самое, через что-то еще. При ОО-проектировании мы можем учесть этот факт и принять такое проектное решение, которое позволит гибко менять одно на другое. Как это делать в условиях модулей?
Модули необходимы при функциональной декомпозиции и структурном проектировании.

Цитата

Цитата D_KEY @ 22.01.11, 22:59

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

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

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

my_obj["some_method"](пар-ры);

Сделать можно, но смысла не вижу.

Цитата

Цитата Qraizer @ 23.01.11, 05:39

Если я правильно понял, то замена одной реализации на другую в ран-тайм поддержана наличием позднего связывания. Не поверю ,что ты о ней не слышал. Значит я тебя неправильно понял. А как правильно?

чтобы поменять класс в рантайме, нужно чтобы классы были объектами первого класса

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

Добавлено 23.01.11, 12:47

Цитата DesweR @ 23.01.11, 11:02

Цитата D_KEY @ 22.01.11, 21:52

Да, можно. Только я здесь не модули ругаю, а утверждаю, что при ОО-проектировании, это все делают классы. И делают они это лучше.

А что они делают? Что?

Все, что сможет обеспечить модуль, может обеспечить класс или объект (в зависимости от задачи).

Добавлено 23.01.11, 12:49

Цитата DesweR @ 23.01.11, 11:02

Цитата Qraizer @ 23.01.11, 05:39

У нас - можно, если оставить .h.
Впрочем, я, конечно, придираюсь. .h - это только публикация интерфейсов, эдакий справочник.

К слову, что не нравится в .h - хрен найдёшь саму реализацию (хотя может быть я не умею правильно искать).

Во-первых, файл с реализацией называется также, как и заголовочный.
Во-вторых, файла с реализацией может уже не быть - реализация уже в библиотеке.

Цитата D_KEY @ 23.01.11, 12:45

Я не говорю, что они мешают. Я утверждаю, что они не нужны при ОО-декомпозиции.
Вот есть у нас объект, который реализован через GDI+, а есть который позволяет делать тоже самое, через что-то еще. При ОО-проектировании мы можем учесть этот факт и принять такое проектное решение, которое позволит гибко менять одно на другое. Как это делать в условиях модулей?

точно так же

Цитата D_KEY @ 23.01.11, 12:45

Модули необходимы при функциональной декомпозиции и структурном проектировании.

модули не зависят от способа декомпозиции

Добавлено 23.01.11, 15:30

Цитата D_KEY @ 23.01.11, 12:45

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

несколько голословные утверждения

Добавлено 23.01.11, 15:31

Цитата D_KEY @ 23.01.11, 12:45

Все, что сможет обеспечить модуль, может обеспечить класс или объект (в зависимости от задачи).

Все, что сможет обеспечить класс или объект, может обеспечить модуль (в зависимости от задачи).

причем без привязки к парадигме программирования

Сообщение отредактировано: korvin - 23.01.11, 15:31

Цитата korvin @ 23.01.11, 15:27

Цитата D_KEY @ 23.01.11, 12:45

Я не говорю, что они мешают. Я утверждаю, что они не нужны при ОО-декомпозиции.
Вот есть у нас объект, который реализован через GDI+, а есть который позволяет делать тоже самое, через что-то еще. При ОО-проектировании мы можем учесть этот факт и принять такое проектное решение, которое позволит гибко менять одно на другое. Как это делать в условиях модулей?

точно так же

Каким образом? Если у тебя есть модуль для работы с GDI+, который все используют, то как ты поменяешь его? А вот в случае, если у тебя есть объект абстрактного класса для работы с графическим контекстом, то ты его легко можешь заменить на другой.

Цитата

Цитата D_KEY @ 23.01.11, 12:45

Модули необходимы при функциональной декомпозиции и структурном проектировании.

модули не зависят от способа декомпозиции

В случае ОО-декомпозиции они не нужны. Достаточно пространств имен на уровне логики и файлов и единиц трансляции на уровне физики.
Какие задачи по-твоему стоят перед модулем в условиях ОО-декомпозиции?

Цитата

Цитата D_KEY @ 23.01.11, 12:45

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

несколько голословные утверждения

Что именно требует пояснений?

Цитата

Цитата D_KEY @ 23.01.11, 12:45

Все, что сможет обеспечить модуль, может обеспечить класс или объект (в зависимости от задачи).

Все, что сможет обеспечить класс или объект, может обеспечить модуль (в зависимости от задачи).

Нет.
Кстати, интересны твои источники информации по ОО-проектированию, не назовешь?

Сообщение отредактировано: D_KEY - 23.01.11, 17:44

Цитата D_KEY @ 23.01.11, 17:31

Каким образом? Если у тебя есть модуль для работы с GDI+, который все используют, то как ты поменяешь его? А вот в случае, если у тебя есть объект абстрактного класса для работы с графическим контекстом, то ты его легко можешь заменить на другой.

зачем мне для этого менять модуль? под фразой "точно так же", я имел в виду "так же воспользуюсь системой типов"

Добавлено 23.01.11, 18:09

Цитата D_KEY @ 23.01.11, 17:31

В случае ОО-декомпозиции они не нужны. Достаточно пространств имен на уровне логики и файлов и единиц трансляции на уровне физики.

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

Добавлено 23.01.11, 18:13

Цитата D_KEY @ 23.01.11, 17:31

Что именно требует пояснений?

чем вот это вот понятней смены класса

Добавлено 23.01.11, 18:19

Цитата D_KEY @ 23.01.11, 17:31

Нет.

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

Сообщение отредактировано: korvin - 23.01.11, 18:20

Цитата korvin @ 23.01.11, 18:06

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

Загрузок чего? Стражи включения используются для соблюдения ODR.

Цитата MyNameIsIgor @ 23.01.11, 18:28

Загрузок чего? Стражи включения используются для соблюдения ODR.

компилятор не справляется? =) почему классы для этого не используют?

Цитата korvin @ 23.01.11, 18:34

компилятор не справляется? =)

С чем?

Цитата korvin @ 23.01.11, 18:34

почему классы для этого не используют?

Эммм... Не понимаю ваш вопрос? Для чего не используют классы, для недопущения повторения одного и того же текста в одной единице трансляции? Как классы могут помешать мне написать это?

class A {};
class A {};

ODR не имеет отношения к инициализации/финализации, как некоторые ошибочно полагают.

Цитата korvin @ 23.01.11, 18:06

Цитата D_KEY @ 23.01.11, 17:31

Каким образом? Если у тебя есть модуль для работы с GDI+, который все используют, то как ты поменяешь его? А вот в случае, если у тебя есть объект абстрактного класса для работы с графическим контекстом, то ты его легко можешь заменить на другой.

зачем мне для этого менять модуль? под фразой "точно так же", я имел в виду "так же воспользуюсь системой типов"

Какие тогда задачи у модуля?

Цитата

Цитата D_KEY @ 23.01.11, 17:31

В случае ОО-декомпозиции они не нужны. Достаточно пространств имен на уровне логики и файлов и единиц трансляции на уровне физики.

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

Потому, что препроцессора достаточно. #include тоже препроцессор, если что.

Цитата

Цитата D_KEY @ 23.01.11, 17:31

Что именно требует пояснений?

чем вот это вот понятней смены класса

Тем, что видно, кто, когда и зачем это делает. Кроме того, это внутренние детали класса.

Цитата

Цитата D_KEY @ 23.01.11, 17:31

Нет.

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

Причем тут Racket? И причем тут разные языки? Я тебе говорю о расширяемости модуля и повторном использовании. В случае классов у нас есть виртуальные методы и наследование.

Добавлено 23.01.11, 18:43

Цитата korvin @ 23.01.11, 18:34

Цитата MyNameIsIgor @ 23.01.11, 18:28

Загрузок чего? Стражи включения используются для соблюдения ODR.

компилятор не справляется? =) почему классы для этого не используют?

Ты путаешь физику и логику. ИМХО.

Цитата MyNameIsIgor @ 23.01.11, 18:42

С чем?

с соблюдением ODR. раз препроцессор юзают, значит компилятор не справляется

Цитата MyNameIsIgor @ 23.01.11, 18:42

Эммм... Не понимаю ваш вопрос? Для чего не используют классы, для недопущения повторения одного и того же текста в одной единице трансляции? Как классы могут помешать мне написать это?

class A {};
class A {};

не знаю, они ж полностью заменяют модули по словам D_KEY'а или я его не так понял? =/
а препроцессор как мешает?

Цитата MyNameIsIgor @ 23.01.11, 18:42

ODR не имеет отношения к инициализации/финализации, как некоторые ошибочно полагают.

равно как и мой, который Вы комментируете

korvin, еще раз прошу объяснить мне, что дает нам модуль на уровне логики при ОО-декомпозиции?

Добавлено 23.01.11, 18:52

Цитата korvin @ 23.01.11, 18:49

Цитата MyNameIsIgor @ 23.01.11, 18:42

Эммм... Не понимаю ваш вопрос? Для чего не используют классы, для недопущения повторения одного и того же текста в одной единице трансляции? Как классы могут помешать мне написать это?

class A {};
class A {};

не знаю, они ж полностью заменяют модули по словам D_KEY'а или я его не так понял? =/

На уровне логики полностью заменяют. Ты же говоришь о физическом размещении текста программы.

Цитата korvin @ 23.01.11, 18:49

с соблюдением ODR. раз препроцессор юзают, значит компилятор не справляется

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

Цитата korvin @ 23.01.11, 18:49

не знаю, они ж полностью заменяют модули по словам D_KEY'а или я его не так понял? =/

А вот как мне модули то помешают это написать?

Цитата korvin @ 23.01.11, 18:49

а препроцессор как мешает?

При помощи стражей включения не включает уже включённые в данной единице трансляции заголовочные файлы.

Цитата MyNameIsIgor @ 23.01.11, 18:55

А вот как мне модули то помешают это написать?

они и не помешают, только class A, объявленный в модуле M будет иметь полное имя M.A, а класс A объявленный в модуле N -- N.A соответственно.

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

Добавлено 23.01.11, 19:10

Цитата MyNameIsIgor @ 23.01.11, 18:55

При помощи стражей включения не включает уже включённые в данной единице трансляции заголовочные файлы.

т.е. мне в моем заголовочном файле нужно думать, как бы чья программа, юзающая мой хидер не подключила чей-то хидер раньше моего со схожим определением? т.е. "#pragma once" же вроде не стандартизировано, а как делают в Qt через "#ifndef ..." могут и одинаковые "метки" оказаться?

Цитата korvin @ 23.01.11, 19:05

они и не помешают, только class A, объявленный в модуле M будет иметь полное имя M.A, а класс A объявленный в модуле N -- N.A соответственно.

Ну, дык, namespace же. Не имеющие к стражам включения никакого отношения. Вернее, это стражи включения не имеют к пространствам имён никакого отношения, они просто на разных уровнях. Вы что-то попутали.

Цитата korvin @ 23.01.11, 19:05

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

Ну, можно, конечно, начать ломать копья по поводу надо ли изжить глобальное пространство имён, но результат этой дискуссии не повлияет на стражи включения Они просто действуют на уровне единиц трансляции, а вам следует с ними разобраться.