Помогите кто сможет ;)

вам не понравилось ООП в си

в С++. да, мне не нравится ООП в C++, это чистая правда

считаете, что инкапсуляция не нужна

нет, я так не считаю

>нет, я так не считаю


А почему когда сказал где-то там про инкапсуляцию - вы ответили, что у меня ООП головного мозга?

А почему когда сказал где-то там про инкапсуляцию - вы ответили, что у меня ООП головного мозга?

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

> наличие квалификаторов доступа не обеспечивает инкапсуляции неким волшебным образом


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

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

то, что ты назвал - это проверка предусловий функций; если ещё проверка постусловий, и валидация состояния объекта. всё это - элементы design by contract, и все они имеют крайне опосредованное отношение к инкапсуляции

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

ещё раз: гдя я «заявлял ненужность» инкапсуляции?

>ещё раз: гдя я «заявлял ненужность» инкапсуляции?


Ну, не очень хорошо о ней отзывались.

Ну, не очень хорошо о ней отзывались.

я давеча нехорошо отзывался о геттерах, например, потому что они нарушают инкапсуляцию - это помню; нехорошо отзывался о пригодности плюсового ООП для GUI - это тоже помню; но вот чтобы прям плохо отзывался об инкапсуляции - вот такого в упор вспомнить не могу

может поделишься линком?

>может поделишься линком?


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

Да, там про сеттеры и геттеры.

Да, там про сеттеры и геттеры.

ну и где я там плохо отзываюсь об инкапсуляции?

Вы там ответили ТС. А сеттер с ней уже связан (если верить книге по плюсам и моей логике), ведь это сокрытие с целью ограничения доступа.

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

не связан. геттеры/сеттеры нарушают инкапсуляцию, а не обеспечивают её

ограничение доступа тоже никакого отношения к инкапсуляции не имеет

Не верь книгам по плюсам, нормальному ООП они тебя не научат :)

И, да, своим заблуждениям тоже не верь

>Не верь книгам по плюсам, нормальному ООП они тебя не научат :)

+1

«Я придумал термин «объектно-ориентированный», и вот что я вам скажу, я не имел ввиду С++.» (с) Алан Кей

>MyStar starN = new MyStar(50, 40, 30, 20, 10..);

starN.paint();

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

>отзывался о геттерах, например, потому что они нарушают инкапсуляцию

опять 25! Предлагаю сразиться на шпагах:)))

>не связан. геттеры/сеттеры нарушают инкапсуляцию, а не обеспечивают её

ограничение доступа тоже никакого отношения к инкапсуляции не имеет

ты неизлечим:)

> геттеры/сеттеры нарушают инкапсуляцию

Ееееееее!!!

Let's the mortal combat begin, khe-khe-khe...

>или какого-нибудь CLOS

(with-bore-mode ()
в CLOS дженерики/методы вообще не являются частью класса)

Можно ваше определение инкапсуляции? и что вы подрузомеваете под геттерами и сеттерами?

>Не верь книгам по плюсам, нормальному ООП они тебя не научат :)

Чему же верить?

Тред не читал. Может кто-то и посоветовал норм. Если повторюсь, сорри.

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

Делаешь класс фабрику StarFactory. В ней готовишь все, что можно вычислить заранее. Любые массивы, данные, тригонометрию. Потом делаешь класс Star, которые умеет рисовать звезду не основе подготовленных данных, которые получает через конструктор. В StarFactory делаешь метод createStar, который передает данные, создает новую звезду, и возвращает ее.

Чистый метод, когда надо разделить данные, которые считаются один раз, и которые уникальны для каждого обьекта.

http://mitpress.mit.edu/sicp/full-text/book/book-Z-H-19.html#%_chap_3

>http://mitpress.mit.edu/sicp/full-text/book/book-Z-H-19.html#%_chap_3



Оно вроде про лисп, который ненужен, не?

Нормальное ООП вообще выдуманное понятие. Будут тысячи разных мнений.

С++ ООП не всегда нравится OOP-nazi из-за примитивных типов (не обьектов), C-legacy и еще некоторых вещей.

Я не волнуюсь по этому поводу. У С++ есть похуже вещи, чем его мнимая не ООП-шность.

Хотите мощный ООП, go Scala.

def While (p: => boolean) (s: => unit): unit =
  if (p) { s ; While(p)(s) }

В Scala есть while, но тут мы его сами написали. Потом

While (i<10)
{
    ...
}

Пример не совсем понятен почему ООП, просто внутри это все обьекты, и можно вытворять покруче вещи чем на С++

1. Оно не про лисп и даже не про схему, а про программирование вообще.
2. Твой говёный С++ не нужен в большей степени, чем святой Лисп.
3. Хочешь узнать, что такое настоящее ООП? Тогда тебе надо будет написать стоящее на Smalltalk. Не из разряда приветмиров, да.

Очень интересно. А насколько Scala нужна? (в плане вакансий и практического применения.)

>1. Оно не про лисп и даже не про схему, а про программирование вообще.


Понятно, изучу.

2. Твой говёный С++ не нужен в большей степени, чем святой Лисп.

Не мой, а Страуструпа)

3. Хочешь узнать, что такое настоящее ООП? Тогда тебе надо будет написать стоящее на Smalltalk. Не из разряда приветмиров, да.

Приветмиры давно не пишу.

Хотите скаже главную прелесть?

Она совместима с Java. Пишете программу на Java, потом вам попадается код с ВырвиМозг-ной логикой, полной сложного жонглирования с данными и сложными выборками. Пишете класс на Scala. Вызываете второй из первого. Только jarы для Scala не забудьте. Разница производительности Java и Scala, как С и С++, тоесть почти никакой.

Чистый ООП с функциональным программированием по желанию. Очень элегантные решения. Например что там наваяли с перегрузкой операторов в С++?

В Scala сделали вещи.

Первая: альтернативный вызов методов по выбору. Тоесть a.plus(b) эквивалентно a plus b.

Вторая: разрешили называть методы не только как в других языках. Хотите метод «+». Пожалуйтса.

Так что Scala не надо завоевывать рынок, его уже завоевала Java. Хотите, можете использовать некоторые классы в ваших Java проектах

Заинтриговало, спасибо.

Первая: альтернативный вызов методов по выбору. Тоесть a.plus(b) эквивалентно a plus b.

Не догнал разницу (кроме синтаксиса)

>Первая: альтернативный вызов методов по выбору. Тоесть a.plus(b) эквивалентно a plus b.

Вот это не совсем понял. Можно и так, и так писать? Или вообще что?

Вторая: разрешили называть методы не только как в других языках. Хотите метод «+». Пожалуйтса

Давным давно есть в Smalltalk.

А так да, занятная вещь получается. Надо будет как нибудь заняться Скалой :)

Не догнал разницу (кроме синтаксиса)

Ну вы же не хотите потом писать a.+(b)

Тэг code для кого придумали?

> Вот это не совсем понял. Можно и так, и так писать? Или вообще что?

Или так, или так. Как будет эстетичнее в тот момент.

Просто анонимную функцию можно описать как { }, как в примере с While. если бы не было такой альтернативной записи, то было бы

While (i<10, { ... })

что не красиво

Спасибо, теперь понял. Выразительно, а чо =)

// yoghurt

опять 25! Предлагаю сразиться на шпагах:)))

лет триста назад за такие слова я пригласил бы Вас на прогулку за город, где отряхнул бы Вам пыль с ушей, и проткнул насквозь (с)

ты неизлечим:)

ты ожидал что моя позиция изменится от одного треда на ЛОРе? :)

Let's the mortal combat begin, khe-khe-khe...

всё что я имел сказать, я уже сказал, хватит с вас

Можно ваше определение инкапсуляции?

разделение интерфейса и реализации. чем меньше зависимости между ними - тем лучше инкапсуляция

и что вы подрузомеваете под геттерами и сеттерами?

class A
{
public:
    int getX() const { return X; }
    void setX(const int x) { x_ = x; }
private:
    int x_;
};

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

> всё что я имел сказать, я уже сказал

Choose your destiny.

Можно ваше определение инкапсуляции?

разделение интерфейса и реализации

Flawless victory!

чем меньше зависимости между ними - тем лучше инкапсуляция

Epic fail!

Интерфейс и реализация - ортогональные друг другу вещи. Делать вывод о чем-либо на основе их взаимоотношения - фейл. Эпик фейл.

Делать вывод о чем-либо на основе их взаимоотношения - фейл

да пожалуйста, не делай, я не настаиваю. повторять тот тред у меня желания уж точно нет

>да пожалуйста, не делай, я не настаиваю. повторять тот тред у меня желания уж точно нет

да. надо придумать новую тему для флейма...:)

надо придумать новую тему для флейма

в соседнем треде обсуждают наиболее кошерное определение ФП, если что

А мы держим руку на пульсе. :3

Уже обсудили и решили. Scala )

Обьект класс A инкапсулирует данные в виде свойства x_ и предоставляет открытый интерфейс в виде методов setX и getX, я прав? Или вы чтото дугое имели ввиду?

Или вы чтото дугое имели ввиду?

не инкапсулирует. убрать из реализации переменную типа int (или любую сущность, семантически ей эквивалентную) при неизменном интерфейсе уже нельзя

Что то я вообще не понимаю о чем идет спор...

> суть не меняется - интерфейс уже оказался зависим от реализации

O_o Где????

>логика на них может навешиватся и куда более сложная, но суть не меняется - интерфейс уже оказался зависим от реализации
Допустим есть класс «курсор». В предметной области есть понятие «позиция» и нужно сделать интерфейс для получения и установки этой позиции. setX и getX нельзя? Что тогда можно?

Что то я вообще не понимаю о чем идет спор

по-моему, кому-то просто делать нечего