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

куда проще вспомнить наоборот :) ну, ZeroC ICE весьма удачный (особенно по сравнению со, скажем, TAO)

Спасибо, посмотрим.

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

Вроде, в 1991-м не было ещё никаких обвальных подорожаний техники. Я себе в 1992-м покупал МК-85 за 270 руб, когда в советские времена он 150руб (кажется) стоил. Ещё летом 1991-го покупал МК-52 по советским 110 руб.

> Ты не можешь учесть всё. Просто пойми это, смирись и

не загромождай программу кодом, который не нужен.

я щетаю, overdesign даже хуже чем premature optimization.

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

хрен там. похоже, обоими болезнями надо просто переболеть.

но некоторые не выздоравливают.

> внетри getReport уже нет необходимости заворачивать доступ к country в отдельную функцию (разве что локальную - для удобства). внутри getReport - любая, абсолютно произвольная реализация.

Ты не уловил. Этих getReport'ов, использующих country, может быть более (а иногда и много более) одного.

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

Вопрос, который обсуждается в этой теме на настоящий момент (ну, кроме инфляции) - как оптимально обращаться _во многих местах кода_ к одной и той же сущности.

> Вроде, в 1991-м не было ещё никаких обвальных подорожаний техники.

Моя память услужливо напоминает мне о гиперинфляции, а википедия приводит цифру в 301,5 % за этот год:

http://ru.wikipedia.org/wiki/Шоковая_терапия_(экономика)

Зимой 90/91 гг. на моей памяти исчезли все товары в магазинах, а с весны цены пошли в разнос. Почему я и уточнил - такое постоянство на 91-ый года меня сильно удивило. )))

>Моя память услужливо напоминает мне о гиперинфляции, а википедия приводит цифру в 301,5 % за этот год:


читая википедию, СССР кончился в 26.12.91.
http://ru.wikipedia.org/wiki/%D0%A1%D0%BE%D1%8E%D0%B7_%D0%A1%D0%BE%D0%B2%D0%B...

Зимой 90/91 гг. на моей памяти исчезли все товары в магазинах, а с весны цены пошли в разнос.

Радикальная либерализация потребительских цен была осуществлена 2 января 1992 г. в соответствии с Указом Президента РСФСР от 03.12.1991 N 297 «О мерах по либерализации цен», http://ru.wikipedia.org/wiki/%D0%9B%D0%B8%D0%B1%D0%B5%D1%80%D0%B0%D0%BB%D0%B8...

Так-то!

И вот

http://ru.wikipedia.org/wiki/%D0%AD%D0%BA%D0%BE%D0%BD%D0%BE%D0%BC%D0%B8%D1%87...

Вот для таких ситуаций Гвидо нам придумал property :)

> > Ты не можешь учесть всё. Просто пойми это, смирись и

> не загромождай программу кодом, который не нужен.

я щетаю, overdesign даже хуже чем premature optimization.

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

хрен там. похоже, обоими болезнями надо просто переболеть.

В точку.

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

потому шо D

труп, ибо пишут его фанатики от программизма в де руки - и никому кроме таких же фанатиков он ненужен

>труп, ибо пишут его фанатики от программизма в де руки

Питон или ЛИСП также писались :) Или даже Си++.

>Питон или ЛИСП также писались :) Или даже Си++.

Ну и где они, эти римляне теперь?

> Ну и где они, эти римляне теперь?

С++ и питон популярны и массово используются, лисп судя по ЛОРу также набирает обороты

Судя по лору

шизофрения и онанизм набирают обороты, а не лисп и d

те какбе открыты, а у d щас даже вменяемой открыторй реализации немае

>Ну и где они, эти римляне теперь?

Ты толст. Впрочем, можно и с конкретными цифрам.
http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html

Навскидку [место, язык, вид разработки]
1 Java корпоративная
2 C индивидуальная
3 PHP индивидуальная
4 C++ индивидуальная
5 (Visual) Basic корпоративная
6 C# корпоративная
7 Python индивидуальная
8 Perl индивидуальная
9 JavaScript корпоративная
10 Ruby индивидуальная
11 Delphi корпоративная на основе индивидуальной
12 Objective-C корпоративная
13 Go корпоративная
14 SAS ?
15 PL/SQL ?
16 ABAP ?
17 Pascal индивидуальная
18 Lisp/Scheme индивидуальная
19 ActionScript корпоративная
20 MATLAB корпоративная

ась?

>те какбе открыты, а у d

Можно подумать, что у Си++ вменяемая реализация родилась сразу :D

Иными словами мы _уже_ имеем некую абстракцию, выраженную через country

и чем она семантически отличается от самих инкапсулированных данных?

> те какбе открыты, а у d щас даже вменяемой открыторй реализации немае

ВНЕЗАПНО все реализации D открыты.

Но та из них, которая вменяемая - несвободна.

> чем она семантически отличается от самих инкапсулированных данных?

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

Какое это имеет отношение к теме?

Какое это имеет отношение к теме?

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

> «абстракция доступа к данным» у нас намертво привязана к конкретному полю данных, а потому абстракцией, в общем-то, не является.

Формально, у нас любая переменная является абстракцией чего-то. Но откажемся пока от формальной логики. Что является абстракцией или что не является, т.е. каков критерий абстракции по-твоему?

с тем же успехом можно было сделать

Можно. И что?

непосредственное.

Показывай. )))

Можно. И что?

то, что это деталь реализации

Дубль 2: и что?

Какую мысль ты хочешь донести, надевши фуражку и стоя в мундире с капитанскими погонами?

Какую мысль ты хочешь донести

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

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

Так, я понял. Отдавай сюда фуражку и погоны. Мундир можешь пока оставить.

Ты, видимо, не допетрил до такой тривиальной вещи, что реализация может быть разной и скрывать её => получать профит. Объясняю на пальцах.

Некоему программисту, назовем его условно вымышленним именем Крон73, надо налобать веб проект. Нашему Крону73 в первую очередь надо создать рабочий прототип. Для работы проекта нужно несколько строковых ресурсов. Крон73 не тратит время на возню с ними, а вшивает их прямо в код, но поскольку наш Крон73 не школота и не студент, он _знает_, что этот механизм будет изменен, и заведомо оборачивает доступ к ним в набор методов, а все строки хранит в одном куске кода. Прототип готов, проекту дают зеленый свет. Проект разрабатывается дальше. В какой-то момент число ресурсов возрастает, редактировать их начинает админ Норк37, который не петрит в коде и вечно забывает ставить в нужных местах точки с запятой. Крон73 быстренько выкидвает строки из кода во внешний ini-файл, до боли знакомый Норку37, и меняет реализацию их загрузки в проект.
Внимание! *** мигает красная лампочка ****
Ни Крон73, ни его коллеги не меняют остальной код проекта ради этой задачи.
Наконец, проект готов, оттестирован, пора его полировать и сдавать в утиль^W продакшн. Маркетинговый отдел, похмелившись и проведя ряд соц. опросов целевой аудитори, и изучив предложения конкурентов, понял, что конечные потребители проекта не умеют работать с ini-файлами из-за их через чур сложного синтаксиса. Зато очень хорошо умеют заполнять веб-формы.
Наш Крон73 делает веб-формочку для ввода данных, результат выгружает во внешнее хранилище и в третий раз меняет систему загрузки этих ресурсов.
Внимание! *** мигает красная лампочка ****
Ни Крон73, ни его коллеги не занимались полным коде-ревью проекта ради этой фичи.

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

Держи фуражку и погоны.
Вопрос - где облажался Крон73, использовав сеттеры и геттеры?
Я тебя внимательно слушаю.

> Внимание! *** мигает красная лампочка ****

Ни Крон73, ни его коллеги не занимались полным коде-ревью проекта ради этой фичи.

А теперь внимание! *** мигает красная лампочка ***

Так как ни Крон73, ни его коллеги не озаботились коде-ревью и написанием тестов после кардинального изменения способа хранения данных, выясняется, что вместо 2к запросов в секунду проект способен обработать только 750, периодически вставая колом и отвечая 502.

Вопрос - какой лубрикант надо будет использовать Крон73 и его коллегам, чтобы минимизировать последствия визита клиента в обнимку с маркетинговым отделом?

Контроль доступа к данным в мультитреде. У вас будет в 100500 раз больше кода, если вы каждое обращение к полю вместо геттера/сеттера оборачивать под соотв. случай. Ну или когда из одних данных можно разом вывернуть несколько сущностей, типа ip_hdr, tcp_hdr, ипр.

Заканчиваем _ТУПО_ троллить. Либо умно, либо никак.

>не озаботились ... написанием тестов

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

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

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

> Вопрос - где облажался Крон73, использовав сеттеры и геттеры?

Вопрос из зала - а нафига здесь вообще геттеры и сеттеры? Нужна функция «загрузить объекты ХЗ откуда».

Это и называется геттером.

> Заканчиваем _ТУПО_ троллить. Либо умно, либо никак.

Ваше мнение ОЧЕНЬ ценно для нас!

Ты, видимо, не допетрил до такой тривиальной вещи

ну да, в этом всё и дело. куда уж мне

> Каким образом ревью заменяет профайлинг и нагрузочное тестирование?

Не заменяет. Равно как и нагрузочное тестирование не заменяет ревью.

Вопрос из зала - а нафига здесь вообще геттеры и сеттеры?

чтобы школьники младших и средних классов радовались знакомым словам, вероятно

Ну а для нас _ОЧЕНЬ ЦЕННЫ_ замечания индивидуума, предполагающего, что программист не догадывается о последствиях изменения кода еще до правки, и меняет реализацию в состоянии глубокой комы, хотя выше было ясно написано - «не студент и не школота».

:3

Отвечай на мой ответ. )))

>> Нужна функция «загрузить объекты ХЗ откуда».

Это и называется геттером

petrosyan.svgz

Отвечай на мой ответ

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

> Ну а для нас _ОЧЕНЬ ЦЕННЫ_ замечания индивидуума, предполагающего, что программист не догадывается о последствиях изменения кода еще до правки, и меняет реализацию в состоянии глубокой комы, хотя выше было ясно написано - «не студент и не школота».

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

> или ты критикуешь по существу,

Что критикую? Ты так и не ответил на вопросы:
1. Почему геттер-сеттер «не абстракция»?
2. Что должен был сделать Крон73 в приведеном кейсе?

> держать его целиком в уме

Тяжелый случай. Чтобы оценить последствия замены File.new.each_line на DB.Connect.Request тебе необходимо засунуть в голову _весь_ проект? Сочувствую.

Ты так и не ответил на вопросы

ты читать умеешь вообще?

1. Почему геттер-сеттер «не абстракция»?

http://www.linux.org.ru/jump-message.jsp?msgid=4464779&cid=4472101

2. Что должен был сделать Крон73 в приведеном кейсе?

http://www.linux.org.ru/jump-message.jsp?msgid=4464779&cid=4469137

Что критикую?

вот и я пытаюсь понять

http://www.codeinstructions.com/2008/08/getters-and-setters-are-evil.html

At a first glance, getters and setters seem to promote encapsulation. After all, they seem to 'hide' the attributes of the class. In reality, accessor methods are just a more convoluted way to expose your attributes. That's why I think getters and setters are Evil: they give you the illusion of encapsulation, without actually providing it.

In an ideal object oriented system, you shouldn't have to get the data from an object and then perform some operation with that data. The right thing to do would be to ask the object who owns the data to perform the operation itself. This is object orientation at its finest. Then you would have real encapsulation: you have no idea, and you don't care, about the data contained in an object. All you know is that an object can provide you a service specified by a method.

In real life, things are trickier and you can't always do that. Sometimes it complicates the model unnecessarily. But whenever you find yourself calling myVariable = myObject.getSomeAttribute() in order to perform some operation with that variable think if it wouldn't be better if you place that operation inside myObject's class. Only expose the strictly necessary. You will find your model will be much cleaner and maintainable.

> Тяжелый случай

Именно. Признайся наконец, что ты никогда не видел проектов, написанных не двумя программистами максимум, размером в сотни тысяч и миллионы LOC, с далеко ненулевым количеством legacy и костылей в целях сохранения совместимости?

Да, вменяемый программист сообразит, что «последствия замены File.new.each_line на DB.Connect.Request (кто все эти люди, кстати?!)» *могут* вылиться в регрессии и тормоза. И да, он сделает code review в момент изменения, прикинь? А не будет тупо менять геттер, как ты тут радостно рассуждал.

> вот и я пытаюсь понять

Я как бы капитаню, и намекаю тебе, что

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

неверное определение. Знание того, что объект в своем интерфейсе предоставляет доступ к country не равно знанию о внтуренней структуре объекта. А более строго - прямо наоборот. О _внутренней_ структуре объекта знания гарантированно нет.

И еще я пытаюсь увидеть докозательство этого постулата:

если у пользователя объекта возникает необходмость в знании того факта, что object работает с country ... то они принадлежат одному уровню абстракции, и разделять их смысла нет.

Поскольку этот забавный постулат можно расширить вплоть до функции main(). )))

Было бы очень забавно посмотреть на пример кода на яве/руби/чихпыхе/сипп, где бы объекты не знали о методах и свойствах других объектов. ;))