Структура vs класс

> Какой Смолток на практике на PC в 1992-м? :)

Какие на фиг PC в 92м? Они ж тогда совсем убогие были. Не надо было с PC связываться, когда было полно более приличных рабочих станций.

>Какие на фиг PC в 92м?

Обычные. От институских «Мазовий» до домашних «Поисков» :) Не говоря уже про всевозможные ЕС-1840/41/42.

Они ж тогда совсем убогие были.

Ну, всяко куда мощнее, чем БК-0010, Радио-86РК или Микроша :) А на хотя бы СМ-4 далеко не все даже избранные доступ имели.

Не надо было с PC связываться, когда было полно более приличных рабочих станций.

Примеры доступных рабочих станций, превосходящих PC в 1992-м году с MSK в студию!

...

Тьфу, блин, это же опять тот фееричный блатной анонимус? :)

> Ты явно уже пытаешься придраться ну хоть к чему-нибудь.

Я, вообще-то, в первый раз ответил...

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

Фигасе не относится. Т.е. проблемы всё равно вылезут, были геттеры/сеттеры или нет, всё равно придётся весь код перепахивать — так зачем было писать эти геттеры/сеттеры, которые ничего не делали? Чтобы замаскировать ошибки в будущем?

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

Ты прочитал, что я писал? Тебе в любом случае придётся тестировать тонны кода. Заменить обращение к члену класса на вызов геттера/сеттера займёт ничтожное, в сравнении с тестированием, время, но зато компилятор не даст пропустить ни одно место, где требуется замена, и, если тебя ещё не подсадили на иглу «мощных IDE с рефакторингом», ты в большинстве сможешь сразу увидеть лажу в логике работы с новым способом получения данных и на месте исправить.

Видимо с разным кодом работаем. Для меня сделать геттер вместо вызова свойства - дело двух минут. В коде с которым я работал, 99.9% геттеров-сеттеров - однострочные и раздувают код в несколько раз. 99.9% от них никогда не переписывались и не будут переписываться. Никакого профита я никогда не видел от того, что добавлял бы лишний код. В динамически-типизируемых языках ситуация, наверное, отличается.

> Примеры доступных рабочих станций, превосходящих PC в 1992-м году

http://en.wikipedia.org/wiki/SPARCstation_10

>Я, вообще-то, в первый раз ответил...

Ну, сорри :) Попутал :)

Т.е. проблемы всё равно вылезут, были геттеры/сеттеры или нет

Именно.

всё равно придётся весь код перепахивать

Почему - весь? Только код геттера/сеттера. Их использование - не изменится.

Тебе в любом случае придётся тестировать тонны кода.

Почему? Остальная часть кода не меняется.

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

Замена требуется только в методе геттера/сеттера. Всё.

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

Откуда вылезет эта лажа, если логика работы не менялась?

>В динамически-типизируемых языках ситуация, наверное, отличается.

Выше я это несколько раз отмечал.

Спарк, доступный простым смертным в Москве 1992-м? Ты фееричен, как анонимус :)

Еще индигу первую и вторую забыл. Только вопрос был про MSK.

Дело в том, что его целесообразно сделать классом, хотя бы для того, чтоб иметь возможность переопределить + для него. Это очевидный случай, когда может потребоваться изменение реализации класса, даже такого простого.

Ваще если в структуре в начале добавить «private:», то от класса она отличаться перестанет. :)

Лень на всё отвечать, потому что:

Откуда вылезет эта лажа, если логика работы не менялась?

Ты прочитал, что я писал в первом комментарии? Мы берём данные из совсем другого места (был член класса, стала даза банных ХЗ где) с кардинально отличающимися свойствами. Всё, это требует хотя бы диагонального просмотра всех мест, где мы эти данные использовали и тонны тестов в любом случае. Самый тупой пример: мы в цикле брали значение. Пока значение было в памяти, всё отлично, как стало в базе — всё.

>Блин, ну это же очевидно всё.

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

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

Вопрос в том насколько сильно:)

>а всякие правила и паттерны это дело десятое

Умный учится на чужих ошибках, а дурак на своих. И это не исключает пользование головой:)

Хотя амиги и макинтоши тут в начале 90-х продавали. Для них реализации smalltalk были, хотя и труднодоступные в условиях отсуствия интернета.

>Мы берём данные из совсем другого места (был член класса, стала даза банных ХЗ где) с кардинально отличающимися свойствами.

Да. Но это забота метода, а не того, кто его вызывает.

Самый тупой пример: мы в цикле брали значение

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

> Спарк, доступный простым смертным в Москве 1992-м?

в журнале Радио реклама была - значит достать было несложно, насчет «простым смертным» - а кто говорил про них, вы б еще про школьников написали

Ты фееричен, как анонимус :)

изволите троллить? ;)

> Очевидно то, что при грамотной архитектуре, где все данные скрыты

Это у нас нынче критерий «грамотной архитектуры»? Бгг.

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

Вопрос в том насколько сильно:)

Добавление геттеров/сеттеров - это просто смешно по сравнению с доработками для, например, добавления хранения данных в БД.

>насчет «простым смертным» - а кто говорил про них

Ну и кто из нас троллит?

>Добавление геттеров/сеттеров - это просто смешно по сравнению с доработками для, например, добавления хранения данных в БД.

Угу. Изменение десятков/сотен строк по всему коду - это, конечно, смешно по сравнению с изменением одной строки в одном месте.

> Да. Но это забота метода, а не того, кто его вызывает.

Нет.

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

Да ладно, у меня там цикл пять раз выполняется максимум, что мне накладные расходы на вызов метода, который к тому же заинлайнится? (c)

Во-вторых, очевидно, что кеширование объектов в системе такого уровня подразумевается.

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

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

Мною - подразумевается. Заметь, если ты упустил начало дискуссии, я попытку глобального обобщения (геттеры/сеттеры не нужны) опровергаю частным случаем (в моей ситуации - просто необходимы). Я не делаю глобальных выводов, более того, выше несколько раз прямо на это ссылался.

Да ладно, у меня там цикл пять раз выполняется максимум, что мне накладные расходы на вызов метода, который к тому же заинлайнится? (c)

В моих языках нет инлайн-оптимизации :)

> Ну и кто из нас троллит?

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

Опять на бедность ссылаешься и на жалость давишь? Не жалко тебя.

>В динамически-типизируемых языках ситуация, наверное, отличается.

Да, отличается, например в GNU Smalltalk можно расширить определения классов метаинструкциями, которые сами генерируют сеттеры/геттеры для переменных объекта.

Наверное, иногда это действительно нужно...

необходимость проводить такую отладку уже говорит о том, что что-то не так выше по дереву вызовов. для того, чтобы оценить эффект - достаточно и watchpoint'а на одном объекте. для того, чтобы найти причину, потребуются breakpoint'ы в более других местах

>ну так без наличия определенной суммы и PC нельзя было купить

PC в 1991-м можно было купить за 1000 рублей. SPARC, боюсь, меньше, чем за сотню-другую тысяч купить было нереально. Если не прав - поправь меня.

В начале 90х в России были даже конторы, которые предоставляли различные решения на Smalltalk =)

А вообще, основной причиной «отхода» языка с мейнстримовой сцены стала как раз таки высокая цена рабочих мест и лицензий на VM (тобишь идиотизм менеджеров)

Ты глуп и толст.

А ты нищ и бродяч.

Пересобери libastral. А то он у тебя берёт данные из /dev/urandom

> Мною - подразумевается.

Я рад за тебя!

Заметь, если ты упустил начало дискуссии

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

В моих языках нет инлайн-оптимизации :)

А-а-а-а-а!!! Ужас-ужас-ужас! 8))

> PC в 1991-м можно было купить за 1000 рублей

это XT по знакомству, да? потому-что нормальные PC стоили в тысячах зеленых

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

я сейчас сам цену не помню - но так как и вы не знаете, то может нам кто-то подскажет

>Это у нас нынче критерий «грамотной архитектуры»?

это у нас её неотемлемая часть.

почемуто нет Pi и его «Хватит!» :)

>>Это у нас нынче критерий «грамотной архитектуры»?

это у нас её неотемлемая часть.

Почему? )

>это XT по знакомству, да?

Нет, это розничная цена «Поиска». Правда, без обвесок, понятно :)

я сейчас сам цену не помню - но так как и вы не знаете, то может нам кто-то подскажет

Может быть. Но, учитывая, что накрутка при ввозе в те времена достигала трёхкратной, и что цена в Штатах на Спарки того времени вряд ли сотнями долларов измерялась, те два порядка разницы с доступными XT и набегут :)

почемуто нет Pi и его «Хватит!»

ну обсуждение-то в принципе конструктивное. это ж не очередное CL vs C++, в конце-то концов

> вместо этого можно было бы написать что-то вроде our_object.getReport(), который инкапсулировал бы

?

get_country() (или как оно там) используется в этом самом getReport()

Ты просто предлагаешь ограничиться инкапсуляцией на уровень выше. Не годиться.

> те два порядка разницы с доступными XT и набегут :)

ну сравнивать с допотопным даже на то время XT - это несерьезно, я полагал, что под PC понималось более современное железо

и что цена в Штатах на Спарки того времени вряд ли сотнями долларов измерялась, те два порядка разницы с доступными XT и набегут :)

вот интересная статистика + цены за 1991:

http://www.islandnet.com/~kpolsson/workstat/work1991.htm

>>> Очевидно то, что при грамотной архитектуре, где все данные скрыты

Это у нас нынче критерий «грамотной архитектуры»?

это у нас её неотемлемая часть.

Мде. Это теперь называется «архитектурой». Тогда вопросов нет.

> C в 1991-м можно было купить за 1000 рублей.

Видимо в январе? ;)

Ты просто предлагаешь ограничиться инкапсуляцией на уровень выше

нет. вернее, не совсем. я настаиваю на том, что инкапсуляция должна повышать уровень абстракции. если у пользователя объекта возникает необходмость в знании того факта, что object работает с country (с некоторым контрактами на тип country),- т.е. иметь представление о внутренней структуре объекта,- то они принадлежат одному уровню абстракции, и разделять их смысла нет. это будет bloated code и множение сущностей

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

get_country() (или как оно там) используется в этом самом getReport()

внетри getReport уже нет необходимости заворачивать доступ к country в отдельную функцию (разве что локальную - для удобства). внутри getReport - любая, абсолютно произвольная реализация. детали которой надёжно спрятаны. так, в частности, у нашего объекта может вообще пропасть поле country (в связи с изменениями ТЗ). логика передачи и обработки данных от этого измениться не должна

>внетри getReport уже нет необходимости

Давай иначе. Что, по-твоему, должен возвращать этот getReport()?

>Почему? )

мы слишком обчитались всяких паттернов:))

Что, по-твоему, должен возвращать этот getReport()?

ну это же твоя система, а не моя :) объект, инкапсулирующий действия, которые ты дальше выполняешь с полями вроде country

>ну это же твоя система, а не моя :)

результат country_name() напрямую используется в шаблоне.

Ты предлагаешь мне шаблон (а также всю соответствующую кухню) в класс засунуть? :) MVC - это тоже жупел, хуже, чем ООП? :D

Jtootf, приведи пожалуйста пример какого-нибудь на твой взгляд хорошо спроектированного ООП опен сорса на С++ или Java.

Вот описание того, что разрешалось поставлять в CCCP: http://www.kommersant.ru/doc-rss.aspx?DocsID=1368

IPC стоил в США от $12000, SLC - от $5000.

В принципе, даже если покупать баксы 1 к 3 (я уже не помню, сколько они стоили в 1991 г.), получается все равно слишком много. Ну и накрутки...

>В принципе, даже если покупать баксы 1 к 3 (я уже не помню, сколько они стоили в 1991 г.), получается все равно слишком много. Ну и накрутки...

Вот и выходят те сотни тысяч, про которые я примерно прикидывал...

...

Просто у меня знакомый участвовал, в самом конце 1980-х гг. в закупке какой-то из AT, что ко КОКОМу не проходила. Где-то за 150 тыс. рублей вышло. Десяток-другой московских квартир за один комп... :)

Нет, один к трем - это я сильно подзагнул. Доллар уже вовсю торговался, поэтому - http://currency.narod.ru/usd/1991.html. 1 к 100-110 на ноябрь 1991 года, когда как раз и стали продавать спарки тут. Ну да, самое то, для простого человека.