Почему?

Поэтому и говорю, что не буду говорить то, что ты всё равно воспримешь в штыки, пока не проверишь сам

Поэтому и говорю, что не буду говорить то, что ты всё равно воспримешь в штыки, пока не проверишь сам

Нет. Я скажу, что не знаю что это.

Потому что считаешь ui на джаве идеальным

Потому что считаешь ui на джаве идеальным

Где я это говорил?

Я сказал, что он для меня удобен.

Сворачиваю демагогию, моё дело сказать, твоё — с гневом отрицать объективные факты

Для меня это идеальный интерфейс.

Ок.

Я дико извиняюсь

насчет JB скажу только что Rider пока сильно хуже чем студия. Им там еще догонять и догонять.

насчет JB скажу только что Rider пока сильно хуже чем студия. Им там еще догонять и догонять.

Зависит от сферы. В вебе/cli я полностью перешёл на райдер. Для остального студия + райдер попеременно.

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

Зависит от сферы. В вебе/cli я полностью перешёл на райдер. Для остального студия + райдер попеременно.

а что в остальном там такого?

то есть в твоем виденьи нет никакой разницы между ООП и не ООП на уровне рантайма и вся разница выражается только в коде. Ни тебе повсеместного late binding, ни тебе децентрализации (потому что всегда есть main рутина)

В моём видении объект – это что-то, что живёт своей жизнью, что-то в себе делает и как-то с окружением взаимодействует. Для меня это глобальный термин, применимый на любом уровне абстракции: Парень нажал кнопочку на сайте, кнопочка дёрнула контроллер, контроллер дёрнул юзкейс, юзкейс обратился к доменному сервису, он обратился к сайту знакомств, сайт выплюнул капчу, сервис обратился к веб-сервису AntiGate, API дёрнуло свой юзкейс, он отправил уведомление смартфону свободных индусов, смартфоны запустили приложение, приложение скачало капчу, индус разгадал капчу, смартфон отправил код обратно на сервер, сервер вписал вознаграждение индусу, сервер ответил нашему сайту, сайт отправил разгаданный код сайту знакомств, он вернул список девушек, сервис запросил микросервис с нейронкой на поиск соответствия, он вернул результат сайту, сайт отобразил парню список кандидаток. Это всё – большая система, состоящая из частей, выполняющих свою работу и общающихся друг с другом по определённым контрактам. Сайты написаны на PHP или Ruby, приложения на Java или ObjC, нейронка на Python, вебсокет висит на NodeJS, маршрутизаторы на C, индус вообще живой, а не спрограммированный. Это всё – объекты. И мне вообще не важно, классы это или микросхемы, клетки или компьютеры, сидит ли там живые индусы или их уже заменили на нейронку. И код я пишу также, именно моделируя объекты товаров, складов, контексты бухгалтерии и всего такого прочего. И с такой философией я с недоумением отношусь к низкоуровневым техническим определениям вроде тех, что "ООП это обязательно классы" и подобным.

а что в остальном там такого?

Многочисленные платформы от майков, которые райдер не поддерживает нормально. Типа WPF и UWP

Многочисленные платформы от майков, которые райдер не поддерживает нормально. Типа WPF и UWP

а. точн :)

В моём видении объект – это что-то, что живёт своей жизнью, что-то в себе делает и как-то с окружением взаимодействует. Для меня это глобальный термин, применимый на любом уровне абстракции: Парень нажал кнопочку на сайте, кнопочка дёрнула контроллер, контроллер дёрнул юзкейс, юзкейс обратился к доменному сервису, он обратился к сайту знакомств, сайт выплюнул капчу, сервис обратился к веб-сервису AntiGate, API дёрнуло свой юзкейс, он отправил уведомление смартфону свободных индусов, смартфоны запустили приложение, приложение скачало капчу, индус разгадал капчу, смартфон отправил код обратно на сервер, сервер вписал вознаграждение индусу, сервер ответил нашему сайту, сайт отправил разгаданный код сайту знакомств, он вернул список девушек, сервис запросил микросервис с нейронкой на поиск соответствия, он вернул результат сайту, сайт отобразил парню список кандидаток. Это всё – большая система, состоящая из частей, выполняющих свою работу и общающихся друг с другом по определённым контрактам. Сайты написаны на PHP или Ruby, приложения на Java или ObjC, нейронка на Python, вебсокет висит на NodeJS, маршрутизаторы на C, индус вообще живой, а не спрограммированный. Это всё – объекты. И мне вообще не важно, классы это или микросхемы, клетки или компьютеры, сидит ли там живые индусы или их уже заменили на нейронку. И код я пишу также, именно моделируя объекты товаров, складов, контексты бухгалтерии и всего такого прочего. И с такой философией я с недоумением отношусь к низкоуровневым техническим определениям вроде тех, что "ООП это обязательно классы" и подобным.

ты не ответил на вопрос - можно ли говорить о ООП когдау тебя в системе один объект.

Но ведь тогда он и является системой ?

ты не ответил на вопрос - можно ли говорить о ООП когдау тебя в системе один объект.

Тогда это не "система" :)

объект есть - системы нет?

Парадокс

системы объектов нет - это да. Но в моем понимании это именно то что делает ООП ООПой

когда у тебя децентализованная система объектов

а все остальное - нюансы

Вообще вопрос про один объект — это провокация изначально)) В математике из-за такой фигни понятие множества пришлось делать заново

"Включает ли множество всех объектов само себя"

объект есть - системы нет?

Вопрос из разряда "Являешься ли ты участником финансовой, социальной, и политической систем, когда ты один на необитаемом острове?" Так то ты также гражданин, но только государство кончилось :)

Я есть государство как не говорил людовик

системы объектов нет - это да. Но в моем понимании это именно то что делает ООП ООПой

Ну программирование само по себе есть создание динамических алгоритмов, моделирование процессов. Просто императивно объявить: begin var a end без каких-то других процессов можно, но есть ли от такой программы смысл...

Ну программирование само по себе есть создание динамических алгоритмов, моделирование процессов. Просто императивно объявить: begin var a end без каких-то других процессов можно, но есть ли от такой программы смысл...

Я привел пример где есть смысл

Ping-сервер, который никто не дёргает. Объект? Объект. Стоит объект Ваз-2101 у кого-то под окном пятнадцать лет и только ржавеет. Кроме химических больше ни в каких взаимодействиях не участвует. Объект? Объект. Объект есть, но самой программы нет.

Ping-сервер, который никто не дёргает. Объект? Объект. Стоит объект Ваз-2101 у кого-то под окном пятнадцать лет и только ржавеет. Кроме химических больше ни в каких взаимодействиях не участвует. Объект? Объект. Объект есть, но самой программы нет.

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

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

Програ́мма (от греч. προ — пред, греч. γράμμα — запись) — термин, в переводе означающий «предписание», то есть предварительное описание предстоящих событий или действий. Данное понятие непосредственно связано с понятием алгоритм. Отсутствие внешних процессов (отсутствие программы) уже не делает такое ООП или любое П вообще П-ой.

Можно поgробовать рассказать про абстракции и что никаких объектов не существует, это лишь слой поверх битов и байтов поверх дремучей архитектуры процессоров, в которые интел запихнула даже minix

Ping-сервер, который никто не дёргает. Объект? Объект. Стоит объект Ваз-2101 у кого-то под окном пятнадцать лет и только ржавеет. Кроме химических больше ни в каких взаимодействиях не участвует. Объект? Объект. Объект есть, но самой программы нет.

Программный код есть, объектов, как и деда мороза — нет ?

Можно поgробовать рассказать про абстракции и что никаких объектов не существует, это лишь слой поверх битов и байтов поверх дремучей архитектуры процессоров, в которые интел запихнула даже minix

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

Программный код есть, объектов, как и деда мороза — нет ?

Те же "абстрактные типы данных" – это как раз про придумывание своих типов вместо стандартных int и string.

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

Но далеко не единственная и уж тем более не настолько универсальная чтобы упрощать всё до объектов

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

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

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

я не вижу в ООП парадигмы, я рассматриваю ООП исключительно как модель вычислений. А как парадигма ООП ничем не отличается от старого доброго структурного программирования

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

скорее InvalidArgumentException

InvalidArgumentType)

я не вижу в ООП парадигмы, я рассматриваю ООП исключительно как модель вычислений. А как парадигма ООП ничем не отличается от старого доброго структурного программирования

Полиморфизм

ну то есть лоджик, спс)

Полиморфизм

Я в последней книжке дяди боба вычитал что основное свойства ооп, которое отличает от всех остальных, это инвресия зависимостей

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

полиморфизм и утиной типизацией... без проблем

ну то есть лоджик, спс)

Да разницы нет, если ты нашел ее только в момент выполнения, то это рантайм. Называть так эксепшн тупо, потому что все твои эксепшены рантайм

Я в последней книжке дяди боба вычитал что основное свойства ооп, которое отличает от всех остальных, это инвресия зависимостей

книжка с пчелкой?)

Я в последней книжке дяди боба вычитал что основное свойства ооп, которое отличает от всех остальных, это инвресия зависимостей

Инверсия зависимостей возможность которую дает полиморфизм

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

и то и другое и логично было бы назвать TypeError/TypeException

Инверсия зависимостей возможность которую дает полиморфизм

Там приводтися пример, что полиморфизм есть в том же С, например мы можем читать что то через STDIN и похуй кто туда пишет, т.е можем работать полиморфно с разными источниками...Ну это к тому что полиморфизм может быть а инферсии зависимостей нет

и то и другое и логично было бы назвать TypeError/TypeException

+

книжка с пчелкой?)

она самая

Да разницы нет, если ты нашел ее только в момент выполнения, то это рантайм. Называть так эксепшн тупо, потому что все твои эксепшены рантайм

так если я на пыхе пишу, у меня что, всё рантаймом объявлять??

так если я на пыхе пишу, у меня что, всё рантаймом объявлять??

зачем

Там приводтися пример, что полиморфизм есть в том же С, например мы можем читать что то через STDIN и похуй кто туда пишет, т.е можем работать полиморфно с разными источниками...Ну это к тому что полиморфизм может быть а инферсии зависимостей нет

Говоря про полиморфизм, имеем ввиду возможность в языке передавать разные подпрограммы подпрограммам

Полиморфизм

полиморфизм это не отличительная черта ООП

так если я на пыхе пишу, у меня что, всё рантаймом объявлять??

все эксепшены - рантайм, называть хоть какой-то так глупо

полиморфизм это не отличительная черта ООП

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

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

благодаря наследованию?)

ERROR: S client not available

Говоря про полиморфизм, имеем ввиду возможность в языке передавать разные подпрограммы подпрограммам

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

все эксепшены - рантайм, называть хоть какой-то так глупо

Ну вот я выкидываю runtime когда произошла какая то непонятная фигня, от меня не зависящая обычно. Типо база непонятно почм отвалилась

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

late binding? это уже ближе к теме

я с late binding знаком только в контексте self vs static так что не могу ниче скзаать)

Ну вот я выкидываю runtime когда произошла какая то непонятная фигня, от меня не зависящая обычно. Типо база непонятно почм отвалилась

UnknownDatabaseException, правда красивее можно представить например в свифте через DatabaseError.unknown

UnknownDatabaseException, правда красивее можно представить например в свифте через DatabaseError.unknown

Я еще называю именно Runtime такие штуки так как рантайм исключение не относятся к контракту класса, и я не обязан как то особенно их обрабатывать и описывать во всех сигнатурах методов, использующих мой

Я еще называю именно Runtime такие штуки так как рантайм исключение не относятся к контракту класса, и я не обязан как то особенно их обрабатывать и описывать во всех сигнатурах методов, использующих мой

в php если назвать Runtime то этого не нужно делать что ли?

в пхп в принципе исключения не являются частью контракта метода))))

ну тогда лучше дать значимое название

но разрабы в док блоках прописывают

ты путаешь контракт и сигнатуру

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

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

...

ты путаешь контракт и сигнатуру

сигнатура же часть контракта?

Хотя да, я путаю

благодаря наследованию?)

Тем что стало возможно передавать методы в объектах

...

шо? даже шторм не подсвечивает и не требует его описывать во @throws

Тем что стало возможно передавать методы в объектах

?

?

Раньше передать функцию было прям очень неудобно стремно и ваще атата, передавая объекты мы передаем еще и поведение

Неизбежно передаем

это что-то сродни тому, чтобы сделать функцию first-class citizen короч

Раньше передать функцию было прям очень неудобно стремно и ваще атата, передавая объекты мы передаем еще и поведение

типа жахнуть указатель на функцию было сложно раньше?

да

не ну в целом да

но в линуксе до сих пор так скажем и все довольны)

таблички указателей на функции)

да вопросов нет, у них задачи скажем так чуть другие)

как DHH сказал “мы не коллеги с Торвальдсом"

Как вы относитесь к названию функции, где фигурирует 'By'? Например allOrdersByUser(User $user) У нас нету строго правила по этому поводу и люди просто иногда пишут by, а иногда не пишут. Мне кажется странным дублировать User и в названии, и во входных параметрах. То есть и так понятно, что по юзеру.

Как вы относитесь к названию функции, где фигурирует 'By'? Например allOrdersByUser(User $user) У нас нету строго правила по этому поводу и люди просто иногда пишут by, а иногда не пишут. Мне кажется странным дублировать User и в названии, и во входных параметрах. То есть и так понятно, что по юзеру.

allOrdersByUser(int $userId) - уже не так понятно

getAllUserOrders - как вариант