а так - тупо класс для координации действий. У меня трабл был в том что лично мне было непонятно к какому слою оно относится. выходил слишком тупой слой приложения

Везде идет как слой аппликейшена же

Везде идет как слой аппликейшена же

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

Ещё одно обьяснение ооп, кому интересно https://youtu.be/J4OIo4T7I_E?t=42m2s

ну ок неплохо про information hiding рассказал но причем тут ООП? это можно было и до ООП мутить

ну ок неплохо про information hiding рассказал но причем тут ООП? это можно было и до ООП мутить

Это как бы часть ооп, как там в википедии "инкапсуляция, наследование полиморфизм" вот это как раз и инкапсуляции, вместо "гетеры сетеры"

инкапсуляция != information hiding

инкапсуюяция это возможность объявить "внутри и снаружи".

information hiding это сокрытие любой информации от того что снаружи о том что внутри

information hiding это сокрытие любой информации от того что снаружи о том что внутри

ну так это и есть инкапсуляция)

ну так это и есть инкапсуляция)

нет же

инкапсуляция это когда у тебя просто есть "снаружи" и "внутри". Возможность провести границу

а уже как взаимодействовать через эту границу - это information hiding

это как смешивать вместе инкапсуляцию данных и поведения

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

хотя это никак не соотносится с open/close (тот же information hiding)

не будешь же ты говорить что OCP = инкапсуляция. ~= - соглашусь)

инкапсуляция это когда у тебя просто есть "снаружи" и "внутри". Возможность провести границу

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

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

На вики (инглиш) как раз второй пункт про инкапсуляцию, сейчас прочитаю

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

http://wiki.c2.com/?EncapsulationDefinition

http://wiki.c2.com/?EncapsulationIsNotInformationHiding

http://wiki.c2.com/?EncapsulationDefinition

https://en.wikipedia.org/wiki/Information_hiding Обычную вики, потом посмотрю что в с2 Вот из обычной цитата "The term encapsulation is often used interchangeably with information hiding. Not all agree on the distinctions between the two though"

ну вот мы и не согласны)

хотя на самом деле пофиг)

всеравно IH мало кто понимает и применяет(

Статья интересная, только один говорит и доказывает свою точку зрения которая вроде бы правильна, другой другую. хз в общем единственное с чем можно согласится полностью In the same way that if a developer believed that using classes and objects is OOP, he will likely also believe that by virtue of using classes their program also gains the benefits of OOP "for free"? The problem here is incompetent/ignorant developers, a clear definitions of the terms won't help. After all, you can writing Fortran using any language.

В общем когда имеют в виду правильную инкапсуляцию то имеют в виду и IH и инкапсуляцию (вот теперь я уже немного склоняюсь в сторону что это не совсем то же самое) т.е. когда сделали приватное поле и доступ к нему через геттеры и сеттеры это не инкапсуляция, нужно сделать это поле деталью реализации чтобы клиенты этого класса ничего о нём не знали. Допустим класс Human у него есть поле hunger можно брать значение этого поля и сетить новое значение но это не инкапсуляция, т.к. вроде бы прямого доступа к полю нет, но ничего бы не изменилось если бы это поле стало паблик, так же происходит доступ клиентского кода внутрь класса и к детали реализации, вместо этого нужно инкапсулировать поле hunger убрав гетеры и сетеры, и сделав метод public void eatSomething(Food food) и boolean isHunger() тогда это уже будет нормальный обьект "сущность"

Вот определение которое мне больше нравиться чем остальные, более практичное что ли "Effective Java™ Second Edition by Joshua Bloch, p. 67: "The single most important factor that distinguishes a well-designed module from a poorly designed one is the degree to which the module hides its internal data and other implementation details from other modules. A well-designed module hides all of its implementation details, cleanly separating its API from its implementation. Modules then communicate only through their APIs and are oblivious to each others' inner workings. This concept, known as information hiding or encapsulation, is one of the fundamental tenets of software design." "

Вот определение которое мне больше нравиться чем остальные, более практичное что ли "Effective Java™ Second Edition by Joshua Bloch, p. 67: "The single most important factor that distinguishes a well-designed module from a poorly designed one is the degree to which the module hides its internal data and other implementation details from other modules. A well-designed module hides all of its implementation details, cleanly separating its API from its implementation. Modules then communicate only through their APIs and are oblivious to each others' inner workings. This concept, known as information hiding or encapsulation, is one of the fundamental tenets of software design." "

т.е. это касается не только отдельного обьекта, но и пакета ( в котором классы могут быть скрыты так же как и поля в классе, а открыты для внешнего мира лишь необходимые которые определяют интерфейс пакета) так же модули которые как совокупности пакетов могут экспортировать только необходимые и скрывать остальные ( оставляя их деталью реализации) и т.д. для больших систем. Если какая то система собрана с правильным пониманием этих правил то её можно быстро расцепить на части (модули = класс,пакет,модуль, ???) и использовать в других системах. Могут попадатся редкие исключения которые имели смысл только в этой системе (Pure Fabrication) но этих компонетнов должно быть как можно меньше. Например автомобиль можно разобрать на двигатель, колёса, кресла, руль, аудиосистема и т.д. и применить в другом проекте. Т.к. они не знают что они часть автомобиля.

У Benjamin Eberlei пару мыслей в тему: https://beberlei.de/2012/08/22/building_an_object_model__no_setters_allowed.html

У Benjamin Eberlei пару мыслей в тему: https://beberlei.de/2012/08/22/building_an_object_model__no_setters_allowed.html

Мне эта статья больше нравится https://www.javaworld.com/article/2073723/core-java/why-getter-and-setter-methods-are-evil.html на неё ссылка была из этой, написана ещё в 2003 году.

геттеры это нарушение принципа "Tell, don't ask" вместо того чтобы сказать обьекту что то сделать, мы вытаскиваем из него данные и делаем это сами. По другому это называестя information expert.

геттеры это нарушение принципа "Tell, don't ask" вместо того чтобы сказать обьекту что то сделать, мы вытаскиваем из него данные и делаем это сами. По другому это называестя information expert.

из этой же статьи: By designing carefully and focusing on what you must do rather than how you'll do it, you eliminate the vast majority of getter/setter methods in your program. Don't ask for the information you need to do the work; ask the object that has the information to do the work for you.

геттеры это нарушение принципа "Tell, don't ask" вместо того чтобы сказать обьекту что то сделать, мы вытаскиваем из него данные и делаем это сами. По другому это называестя information expert.

стоит разделять "геттеры" и query-методы

в целом весь вопрос в именовании)

скажем метод rename(string name) вполне себе не сеттер а метод name(): string вполне себе не геттер)

а вообще была неплохая штука - "Объектная гимнастика" - там как раз таки в рамках упражнения предлагают полностью отказаться от геттеров и сеттеров.

что бы у людей появлялись вопросы "а как делать"

мне в свое время очень даже помогло

делаешь себе упражнение - запилить заказ товара без единого геттера

и уже появляются классы Customer у которого есть метод order в который передается продукт у которого есть метод reserve который возвращает VO....

сетеры это нарушение инкапсуляции и доступ внутрь обьекта невалидным способом с семантической точки зрения. Допустим есть класс Human у него есть геттеры сеттеры setHunger(int value); int getHunger() и метод eat(Food). Так вот допустим человек поел что нибудь, а кто то ему насетил значение голода. Или вообще сбросил его, таким образом поведение этого класса находится непонятно где, извне, если даже у гетторов сеттеров будут проверки чтобы не насетить что то невалидное, вместо них должен быть метод isHunger() например

$customer->order(...$products);

сетеры это нарушение инкапсуляции и доступ внутрь обьекта невалидным способом с семантической точки зрения. Допустим есть класс Human у него есть геттеры сеттеры setHunger(int value); int getHunger() и метод eat(Food). Так вот допустим человек поел что нибудь, а кто то ему насетил значение голода. Или вообще сбросил его, таким образом поведение этого класса находится непонятно где, извне, если даже у гетторов сеттеров будут проверки чтобы не насетить что то невалидное, вместо них должен быть метод isHunger() например

а еще сеттеры способствуют temporal coupling

вызвал в не том порядке - уже не правильно. Забыл что-то вызвать - уже не правильно. А это нарушение KISS

и потом влечет за собой дублирование

стоит разделять "геттеры" и query-методы

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

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

хороший пример

Пример отличный. Схоронил в копилку объяснений TDNA

скажем метод rename(string name) вполне себе не сеттер а метод name(): string вполне себе не геттер)

да, это верно. Только я бы ещё более выражения добавил к именам вроде changeNameTo(String newName) так как будто это говорится не обьекту, а человеку

Вообще ооп создавалось для того чтобы моделировать проблему которую нужно решить в реальном мире, путём переноса всех обьектов проблемы в модель, допустим автоматизировать магазин у нас есть Товар, Корзина, Склад например. Берём обьекты реального мира и переносим их в модель. При чём взаимодействие между этими обьектами будет только в рамках того процесса что мы моделируем. В реальности корзину можно надеть кому нибудь на голову, а склад может сгореть и т.д. но такого поведения этих обьектов в нашей модели не будет. Будет только добавить товар для корзины или узнать цену товара. В каком нибудь игре вроде GTA если она будет написана в ооп стиле могут быть такие же самые сущности но там будет поведение которое уже необходимо для моделерования других процессов.

Вообще ооп создавалось для того чтобы моделировать проблему которую нужно решить в реальном мире, путём переноса всех обьектов проблемы в модель, допустим автоматизировать магазин у нас есть Товар, Корзина, Склад например. Берём обьекты реального мира и переносим их в модель. При чём взаимодействие между этими обьектами будет только в рамках того процесса что мы моделируем. В реальности корзину можно надеть кому нибудь на голову, а склад может сгореть и т.д. но такого поведения этих обьектов в нашей модели не будет. Будет только добавить товар для корзины или узнать цену товара. В каком нибудь игре вроде GTA если она будет написана в ооп стиле могут быть такие же самые сущности но там будет поведение которое уже необходимо для моделерования других процессов.

мне кажется что перед тем как соваться в ООП надо изучить actor model

бо это дело можно и без ООП мутить, ну и оно неплохо подготовит к нему

- структурное программирование - основы функциональщины - actor model - ООП

вот я бы так составлял план обучения

вот я бы так составлял план обучения

Нуу не много ли, лучше сразу ооп может быть?) я js смотрел чтобы понять лучше функции в java 8

Нуу не много ли, лучше сразу ооп может быть?) я js смотрел чтобы понять лучше функции в java 8

как по мне - не много.

сразу ООП - это значит смешать все эти пункты в один

результат мы и так видим

каша

а так кому-то может зайти экторов на хаскеле писать

и вертел он твое ооп

а так кому-то может зайти экторов на хаскеле писать

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

Я вот начинаю думать, что при изучении надо первым делом научить людей строить модели. Я ни разу не видел новичка, чтобы он при работе думал моделями(доменом). думают строчками в базах данных, input-ами в HTML. Это некое наследие кривой обучения, в которой дают только то, как обеспечить инфраструктуру а не построить модель.

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

ну что бы нормальный код писать ты должен понимать что ООП существует на весьма большом масштабе а внутри объекта у тебя или структурное или уже функциональное программирование

Я вот начинаю думать, что при изучении надо первым делом научить людей строить модели. Я ни разу не видел новичка, чтобы он при работе думал моделями(доменом). думают строчками в базах данных, input-ами в HTML. Это некое наследие кривой обучения, в которой дают только то, как обеспечить инфраструктуру а не построить модель.

за это мы должны благодарить десятилетия рекламы Oracle которые умудрились вбить в головы людям что "модель это база данных"

ну я утрирую конечно, еще процесс обучения в ВУЗах так построен

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

1-ый 2-ой курс - алгоритмы и базы данных, 3-ий курс ты уже работаешь и как бы пофиг что там дают

у нас в ВУЗе моделирование систем было.... но это было чуть больше про теорвер

чуть другие модели

каша

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

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

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

на самом деле не думают. Обезъянка видит - обезъянка делает

это уже потом они начинают натыкаться на статьи в духе "utils не хорошо" и часть начинают задаваться вопросами

а часть сформировав привычку начинает яростно атаковать источник "угрозы" мировозрению

так и религия работает)

на самом деле не думают. Обезъянка видит - обезъянка делает

первый пример кода который видит начинающий это как раз эти утил классы и прочее легаси которое в стандартной библиотеке, откуда он узнает что хорошо, а что плохо. Синдром утёнка в чистом виде.

а часть сформировав привычку начинает яростно атаковать источник "угрозы" мировозрению

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

примеры привычек смысла которой не понимают и просто принимают на веру: - венгерская нотация. Проблема которую она решала ни разу не актуальна но.... - суффиксы/префиксы (Exception, Interface, ISomething, Manager, Maker, Factory....) - геттеры и сеттеры (потому что пришли в ооп а думаем процедурами, про это есть немало историй как так вышло и что это для "упрощения адаптации людей", гребаный маркетинг) - отсутствие понимания простейших критериев грамотной декомпозиции

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

маленький геноцид плохих разработчиков?)

маленький геноцид плохих разработчиков?)

скорее причину по которой такой код появляется путём просвещения)

скорее причину по которой такой код появляется путём просвещения)

именно по этому я предложил свой "план" обучения людей

последовательность

вот с суффиксами и префиксами интересно. Interface, Contract и т.д. очевидно. А вот Exception... тут моя религия против. почему?

Repository - тоже?

вот с суффиксами и префиксами интересно. Interface, Contract и т.д. очевидно. А вот Exception... тут моя религия против. почему?

вопрос сохраняется ли семантика. Этот суффикс часто добавляют по дефолту. Хотя ошибки в духе InvalidTransaction вполне себе описыватю что это такое.

Repository - тоже?

что лучше - ProductRepository или Catalog?

примеры привычек смысла которой не понимают и просто принимают на веру: - венгерская нотация. Проблема которую она решала ни разу не актуальна но.... - суффиксы/префиксы (Exception, Interface, ISomething, Manager, Maker, Factory....) - геттеры и сеттеры (потому что пришли в ооп а думаем процедурами, про это есть немало историй как так вышло и что это для "упрощения адаптации людей", гребаный маркетинг) - отсутствие понимания простейших критериев грамотной декомпозиции

Венгерсая нотация https://msdn.microsoft.com/ru-ru/library/system.collections.ilist(v=vs.110).aspx 90% после того как посмотрят на этот пример будут заводить такие же интерфейсы с префиксом I. Там же не написано что это плохо. Я бы вообще ввёл какую нибудь аннотацию (не знаю есть ли в c#) но в java чисто для документации что то вроде BadDesign

GuestRepository или GuestBook?)

что лучше - ProductRepository или Catalog?

ProductRepository )

мм. лучше репозиторий. так ясно понятно, что это инфраструктура. А каталог и бук - это можно и за сущности принять..