[ООП] Интерфейсы

ну во первых public поля делаются в последнюю очередь для переменных, так как если уж пишем на плюсах,то надо писать именно на них а не на чем то еще. сами классы предполагают инкапсуляцию данных,тоесть сокрытие его реализации от пользователя. сетеры и гетеры(тоесть set и get функции) позволяют как минимум избавиться от проблем при отладке, если вдруг меняем обработку переменной то только в описании реализации функции и не бегаем по коду и не исправляем нововведения тупым копипастом.плюс если все делать паблик то при использовании наследования могут возникнуть трудности с одноименными данными а это тоже не есть хорошо, приходится изворачиваться и применять всякие операции вроде ::. а потом если сделать все паблик то где вероятность того что тот кто будет использовать класс не изменит запрещенные ему для модификации данные?а это очень как хочется сделать при использовании чужой библиотеки и потом заявить начальнику что это не моя программа косячит а косяк предоставленной мне библиотеки,за что потом ее разработчик получит новые проблемы и головную боль,а таким может когда то стать любой

необходим интерфейс(тоесть как минимум сетеры и гетеры)

Лол. Сетеры и геттеры — это в большинстве случаев противоречивое состояние объекта или валидационная лапша.

а так без них по это не по а свалка сплошная

Лол. См. выше.

возьмите в пример кьюти

Вообще мега лол. Неосиляторы крестов даже свой язык придумали от большого ума.

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

Я б сказал, в основе разработки ПО лежит принцип оптимизации трёх переменных: стоимости, сроков и качества. Всё остальное — лишь следствия.

говорит о том, что этот объект класса ничего кроме данных о своём состоянии и методов изменения полей не несёт и подобен record в Паскале.

У меня во всех мануалах написано, что POJO не предполагает отсутствия логики - оно лишь предполагает отсутствие требований по имплементации интерфейсов, строго определенных методов, всякую там xml-конфигурацию и т.п. А то, о чем ты пишешь - это anemic domain model.

Вот ты говоришь некие общие положение, которые известны любому первокурснику. А я говорю о том, что на практике в 9 случаях из 10 имеешь дело с исключением из правила. Вот к пример:

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

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

трудности с одноименными данными

Поля не полиморфны, есть такое. Ниразу не видел перекрытия имен в иерархии наследования. Увидел бы, сделал гетеры/сетеры.

В общем все эти псевдоправила сродни проектам по постройке пушек для защиты от инопланетян.

Да не читайте вы эти глупые мануалы :)

Есть такой фундаментальный принцип разумной деятельности — бритва Оккама. В программировании его часто обозначают аббревиатурой KISS. В соответствии с этим принципом, плодить бестолковые интерфейсные обертки — смертный грех.

> бритва Оккама

KISS

Какой-либо связи между ними, очевидно, нет.

>> бритва Оккама

KISS

Какой-либо связи между ними, очевидно, нет.

Как это нет? Бритва Оккама - интерфейс, принцип KISS - реализация.

Тролить здесь

> Бритва Оккама - интерфейс, принцип KISS - реализация.

Извините, что?

Лучше не обманывать себя и не городить лишние, только мешающие слои абстракций и сделать public-поля.

Это будет полный П, а не ООП.

Я предлагал отказываться от геттеров и сеттеров (методов-мутаторов) и совсем не предлагая делать публичными поля.

Наоборот, «наружу» должны выставляться только хорошо спроектированные и увязанные с объектом и между собой методы, представляющие собой публичный интерфейс для правильного управления этим объектом извне. Простые методы-мутаторы этим свойством не обладают и тем самым нарушают инкапсуляцию данных в объекте: дёрнуть метод-мутатор может любой залётный клиент, и не факт, что после этого состояние объекта будет внутренне согласованным. Прямой доступ к опубликованным полям — ещё большая ересь.

Вот не надо мне перескахывать учебник по ООП :) Я их еще в 8 классе читал. Ты опять говоришь общие слова без привязки к конкретным задачам и требованиям. Если ты можешь инкапсулировать состояние, не выворачивая состояние объекта наизнанку public полями или геттерами/сеттерами, то так следует сделать. Ну вот к примеру есть сущность «Денежный счет». Глупо было бы поле «баланс» вытаскивать наружу с помощью public или геттеров/сетеров. А если у сущности нету никакой логики? Например сущность «Письмо» или сущность «Регистрационная кароточка пользователя». Единственная обязанность таких сущностей скорее всего просто хранить состояние. Не обязательно, конечно, но «тупые» объекты лично мне попадаются чаще, чем «умные». Набор публик полей в этом случае самое то. Еще пример: DTO-шки. Такие объекты по определению не имею логики. Я их делаю набором public final полей.

Мой хинт: корректная реализация зависит от свойств самих доменных объектов, нельзя сказать что вот публик поля зло/добро или, что все объекты должны содержать логику/не должны. Ответы на эти вопросы нужно искать в сущностях, а не в книжках.

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

а были бы интерфейсы то их хотябы легко найти....

Ну у вас, в С++, там с этим тяжко, да. А я избалован хорошей инструментальной поддержкой в Java, так что мне это не помогает. И да, наверняка тебе дали какой-нибудь гавнокод. С аккуратно написанным процедурным кодом не так уж и сложно справляться.

ты когда нибудь писал класс стринг?

Писал (в качестве лабы в университете), там нельзя делать указатель на память и длину строки паблик, а как раз инкапсулировать. Это же практически книжный пример.

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

ну так я и говорю тебе,что не везде паблик нужен

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

и ни разу не имел проблем с защищенными или с закрытыми переменными

А я и не говорю что это плохо. Вообще корнем зда я считаю писать код, который не нужен. Вот, скинули ссылку на принцип YAGNI. Оказывается мои взгляды имеют какое-то красивое название :)

то использовать ее по максимуму а не писать на плюсах как на си.

Часто пишу на Java, «как на Си», хотя ближе к haskell наверное все же.

За примерно 8 лет программирования на С++ ни разу не использовал public поля и никогда не использовать геттеры/сеттеры. Наверное те самые книжки по ООП произвели на меня большое впечатление ) Или может просто разные читали?

Разные задачи, разные домены и так далее. Если посмотреть на сообщество Java, то 90% кода написано на геттерах/сеттерах. Когда-то это оправдано, когда-то нет, но по большей части оправдано.

> Когда-то это оправдано, когда-то нет, но по большей части оправдано.

Я не знаю как проводилась оценка оправданности, но по мне это просто признак плохой декомпозиции.

Зря ты так не глядя на задачу выносишь вердикт. У меня очень сильная градация «толстоты» объектов от проекта к проекту.

> Зря ты так не глядя на задачу выносишь вердикт.

Не, я вердикт не выношу. Это просто дефолтовая позиция ) Так, если не доказано иначе.