Часто замечал что в разных sdk (например AWS) локальные переменные обьявляются final. Имеет ли это хоть какой-то эффект на перформанс в рантайм / ускоряет ли компайл тайм, или это просто тыкание?
@@rubik6169 Это скорее показывает, что переменная не меняется в процессе и сразу видно, что это константа. Легче не запутаться в процессе "понимания чужого кода"
@@rubik6169, слышал мнение от авторитетного источника (не в видео Немчинского, но так же это был программист с большим опытом), что final обеспечивает гарантированно тот факт, что значение поля не будет изменено в процессе выполнения программы. Все. Ни на какую производительность оно не влияет.
Статические методы удобно использовать в утилитарных классах, чтобы не создавать экземпляр и вызывать явно. Уже не говоря о всяких фабриках. А статические поля в многопотоке еще та попоболь, бывало, что три потока стучалось в одно статическое поле. Только потом додумался завернуть в synchronized, но можно и использовать Atomic, для придания операциям атомарности. Но все равно не покидает ощущение, что сделал какой-то лютый костыль, но по-другому никак не могу сделать
Коротко: "static"- поля/методы одни для всех экземпляров данного класса, плюс можно использовать без экземпляра, а прямо с класса, "public" - если вызывается из другого класса, "private" - если вызывается только из данного класса. Вот и всё :) Полезно, кстати, смотреть на нативные классы из JDK.
Не знаю, было ли такое видео или нет (по крайней мере я его не нашел), но не могли бы вы рассказать как в целом собирается интерпрайс проект с джавой? Т.е. весь процесс от начала до конца, заранее, спасибо :)
Интересная тема, только уточните, пожалуйста что имеется в виду - как происходит старт проекта с точки зрения маркетинг-продажа-разработка и тд. или с точки зрения CI/CD или с точки зрения что делает разработчик с новым проектом?
Не понимаю почему нельзя использовать классы утилиты(со статик методами). Ведь всякие типа Collections, Arrays существуют же. Создааать например какой-то парсер или что-то есть же смысл? Или лучше создать экземпляр такого класса и в многопоточности его защитить через ThreadLocal ?
Смотря какая задача. Если вся работа с парсером - это вызов одного метода с параметром - ну можно и в статик засунуть. Тогда при массовом использовании не придётся каждый раз создавать объект на каждый его вызов. Если же это парсер какой-то большой сложной структуры, у которого есть состояние, к которому нужно много обращений (и не дай б-г коллбэки), то статику лучше не использовать, получится многопоточность на ровном месте, в то время когда её можно было бы избежать, используя обычный класс.
Очень мутное описание статических методов. То, как вы описывали в начале про статические методы, больше подходит под описание полей и методов в абстрактных классах или просто в супер классах (вроде они так называются). Мне кажется, что статические методы и поля чаще всего используются для каких-нибудь вспомогательных классах, которые выполняют роль библиотек (например, Math)
+1, я понимаю как они все работают, но мне кажется у меня будет проблема что бы обьяснить собеседующему меня человеку про полиморфизм и абстракцию, я понимаю как и где оно используется, но слов подобрать не получается как мне кажется
Везде, где речь заходит про инкапсуляцию, про неё говорят только то что это не сокрытие. Это говорят настолько часто, что наоборот инкапсуляция стойко ассоциируется с сокрытием.
@@СергейПресняков-о4р Инкапсуляция помогает навести порядок в коде, чтоб меньше было путанец. Тут лучше пояснение зачем нужна Инкапсуляция : ruclips.net/video/j-zS42qRv88/видео.html - пока лучшего пояснения не встречал и это сокрытие тоже :)
Здравствуйте, Сергей. учусь программировать около 5 месяцев. Начал за собой замечать, что чрезмерно использую гугл, для решения какой-либо задачи. К примеру, мне нужно в потоке загрузить данные с сервера через AsyncTask. Я знаю что мне нужно именно AsyncTask и какие методы в нем, но я не знаю, что именно писать в этих методах. Я гуглю и смотрю как люди реализовывали похожую задачу, и меняю их код на свой лад. Очень бы хотелось услышать, что вы думаете на это счет, думаю очень полезно будет для новичков)
Добро пожаловать в профессию :))) цель программиста решать задачи, а не зубрить справочники и весь синтаксис. Вы должны знать ряд принципов работы, методологию, какие основные компоненты есть и с чем их едят, придерживаться стандартов и знать примерно что найти и главное где искать. Уметь анализировать и применять на практике полученную информацию. ОК ГУГЛ, это фактически ежедневный рабочий инструмент любого разработчика. Как говорится, всё знает только идиот или шизофреник. Чем чаще вы пользуетесь теми или иными методами и компонентами, тем реже вы заглядываете в справку по ним. Но даже зная их досконально, не используя в работе годик другой, вы потом опять полезете в справку и примеры реализации, это норма.
Это норма. Е.Малышева. Хотя с опытом у тебя наберется свой "набор решений" по базовым и не очень задачам. И применять этот набор будет быстрее и предсказуемее чем гуглить. Но при этом привычка гуглить может оказаться полезной что бы держать руку на пульсе - получать иные решения и пересматривать решения из "своего набора"
Инкапсуляция и сокрытие данных это РАЗНЫЕ ВЕЩИ, Про красные машины (статические методы): экземпляр класса - объект. Класс - чертеж, по которому этот объект строится. Static метод/поле принадлежит чертежу. Остальные методы принадлежат объектам. У статических полей/методов нет проблем с многопоточностью. АБСОЛЮТНО. Это фича статических полей/методов в java...если они финальные
Зашита от дурака, упрощающая и усложняющая. Все равно, что сказать: "Вася, ты не имеешь права управлять самолетом!". А Вася никогда не хотел. и не захочет, и возможности у него такой не будет.
Про статик методы ошибочное утверждение - проблемы с многопоточностью не метод создает, а небезопасный доступ к данным. То что разные потоки обращаются к статическому методу не создаст проблем если в методе не происходит работа с общими данными. Метод это просто код и этот код может быть вызван множеством потоков одновременно. Но если внутри метода, без какой либо защиты, будет модифицироваться общая для всех переменная, то результат будет не предсказуемым. static int sum(int a, int b) { return a + b; } - прекрасно будет работать в многопотоке.
почему в java нету модификатора доступа "только чтение", очень удобная штука, как по мне в большинстве случаев подходит, я бы это слелал по умолчанию. В c# кстати есть readonly. А то часто приходится делать переменные private, а потом прописывать гетеры. А еще вопрос, почему в коде на java часто можно заменить как переменную обьявляют private, а потом прописывать и геттеры и сеттеры, не проще сделать ее паблик?
Вообще вопрос ни хрена ни новичковый, связи иль агрегация. А вот хотелось бы услышать с точки зрения архитектуры мож в каких областях предпочтительней агрегировать, есть ли какие то эвристики или професс опыт на эту тему
Лично у меня сильно другой подход к private vs public(методам): Инкапсуляция инкапсуляцией, но приватные методы - это далеко не всегда тот механизм, который её обеспечивает. В неопытных руках это гораздо чаще приводит к ухудшению качества кода. Появилось желание написать приватный метод -> подумайте, а правильно ли вы моделируете свой домен, может всё-таки лучше выделить абстракцию, уточнить апи текущего класса... и только тогда уже private. Именно тогда, я могу хоть как то быть уверен, что private используется для сокрытия реализации... 1 Наличие большого кол-ва приватных методов, говорит о вероятном нарушении SRP, а значит в классе поселился "чужой". Другими словами, класс взял на себя слишком много ответственности и стоит задуматься над вынесением этой логики в отдельную абстракцию/абстракции. 2 Приватные методы напрямую не протестируешь! И вы очень азартны, если хотите оставлять большие куски такой логики без проверок.... 3 Код приватного метода естественно непригоден к повторному использованию вне класса. Имхо. И да, инкапсуляция - это в первую очередь, сокрытие от пользователя не только реализации класса, но и возможностей по переводу объекта в неконсистентное состояние, плюс предоставление корректного апи по использованию объекта. Когда я вспоминаю об инкапсуляции, я переживаю именно об этом, а не о том, что нужно срочно по закрывать все лишние открытые методы. Успеем закрыть, кончено пабликами не стоит злоупотреблять, и уж тем более не надо просто так клепать. Но бяка не здесь.... А вот отсутствие продуманного интерфейса(api) и наличие большого кол-ва private методов - вот настоящее зло. Код не тестируемые, тяжело поддерживаемый. Ну и в конце концов, клиент сам виноват, что при наличии официального контракта(интерфейса) завязался на паблик методы, которые автор класса и поддерживать не обязан.
Просто тестировать нужно АПИ, а не приватные методы, если мы говорим о CI/CD. Если тестируешь локально, то просто на время тестирования делаешь их пабликом. Нарушения SRP никакого не вижу, если в приватных методах ты создаешь нужные объекты и вызываешь их методы. АПИ классы несут в себе много логики под капотом и разбивать их, чтобы соблюсти идеальный SRP, будет неудобно для пользователя.
@@augustjoyce3504 1 *_"Просто тестировать нужно АПИ"_* - естественно. Только в реалиях, api - это айсберг, а тупое следование принципу прикопать под ковер приводит к тому, что 70% логики в итоге в приватных методах. Да даже хоть 20%, вы думаете это не надо тестировать? Если вы будете тестить это через апи - у вас будет комбинаторный взрыв входных данных. И я всёравно уверен, что куча приватных if'ов так и останутся не покрытыми тестами. 2 *_"если мы говорим о CI/CD. "_* - вообще не понял при чём здесь это сейчас. 3 *_"Если тестируешь локально, то просто на время тестирования делаешь их пабликом."_* - даже комментировать не хочется. 4 *_"АПИ классы несут в себе много логики под капотом и разбивать их, чтобы соблюсти идеальный SRP, будет неудобно для пользователя."_* - SRP, сам по себе, это не самоцель. А вот легко поддерживаемый и тестируемый код - да!
@@gordonfreeman1842, я, конечно не эксперт в ООП, но вроде он нужен в такой ситуации: в компании о разработке сайта надо обработать из базы данных какую-то информацию, есть 2 группы программистов, одна должна написать класс, где будут средства, для того чтобы вытаскивать по-особому данные из БД, а вторая будет их обрабатывать. Но поскольку работа идет параллельно, то вторая не может работать, пока не закончит работу первая. И тут в дело вступают абстрактные классы и интерфейсы. Вторая группа создает абстрактный класс, где описывает поля и методы, с которыми они будут работать. И теперь они использует эти методы в своем проекте, и когда они завершат работу над своей часть уже будет готова остальная
Как бы ты не пытался скрыть поля в Java, как не крути ты все равно можешь до них достучаться, потому что Java работает на JVM, а через JVM можно легко получить нужный класс и его поля используя рефлексию:) Увы это не С++ или C#, хотя в C# тоже есть вроде как рефлексия.
есть public метод A, который вызывает приватные методы B,C. В тесте мне нужно доказать что в нужном мне случае вызвался B, и не вызвался C и наоборот. Можно сделать mock, на нем считать количество вызовов. Но вся беда в приватности методов.
Вопрос: что ты хочешь протестировать - интерфейс или алгоритм/код? Если интерфейс, то зачем пытаться как-то тестирова приватные методы? Если код/алгоритм, то да, надо выносить в отдельный класс
@@SecretRUclipsAgent это я к тому что между ними разницы особой нету, без наследования. Да, с протектед можно зафакапить код, но это так же легко как и с привате. Как по мне это отголосок той далекой эпохи когда все умудрялшись вкладывать в 40 килобайт програму, костыли для програмы и еще и пасхалку с сейлормун засунуть. Что то уровня "названия полей и методов должны быть короткими". Щас даже бюджетные процессоры могут работать с переменными с километровым названием. А если язык компилируемый то тут вообще не важно как ты переменную назоввешь, компилятор название выбросит все равно.
Я так понял, что статик используют когда нужна самая обычная функция. Та самая из функционального прокграммирования. Но вера и/или язык не позволяют просто создать функцию. Приходится городить объект со статик методом :)
@@katerinak5997 я бы и с радостью, но банк говорит что нужно выплатить кредит сначала ) а вообще уже начал учить Котлин. Начал писать своё приложение. UI мне уже сделали в подарок на ДН. Дело за малым )
В своё время тоже были проблемы с пониманием использования static, для себя вывел такую аналогию, что есть класс "свинарник", внутри него есть поле "кормушка" которое является статическим и доступно для каждой свиньи в свинарнике
Рефакторинг и исправление ошибок. Бахнули вы класс Person, с полем age у которого интовое значение и данные которого сохраняются в базе данных. В результате в 2018 Анне 18 лет. Вопрос, сколько ей будет в 2019 и 2020м? Верно, все так же 18, т.к. хранить надо было дату рождения. И вот вы модифицировали базу и класс персон, теперь есть поле дата рождения и для родительского класса всё ок, чего не скажешь о наследниках, особенно сделанных не вами, а другими разрабами на своих проектах (Students, Customers, Employees и т.п.). Работая через методы у вас есть возможность решить проблему заменой алгоритма гетторов и сетеров в родительском классе, получить дату рождения расчетным путем и возраст (исходя из текущей даты). Сделав поле возраст публичным и призвав прописывать алгоритмы присвоения назначения в наследуемых классах вы вырыли себе и другим яму. Понятно что пример несколько упрощен с математической точки зрения, но общая суть необходимости сетеров и гетеров думаю ясна.
Сергей, просьба поделиться вашими соображениями, чем классы принципиально отличаются от структур в процедурном программировании, для работы с которыми определены функции
Я, конечно, не Сергей, но могу сказать, что классы - это следующая ступень эволюции структур. Отличие в том, что структура рассматривается в первую очередь как набор данных, а функции играют лишь вспомогательную роль. Класс же рассматривается как представление объекта предметной области с его поведением, а данные, содержащиеся в нём, уходят на второй план. В целом эти вещи довольно близки с точки зрения кода (в С++ структуры вообще реализованы на базе классов), но различаются по смыслу и предназначению.
Есть ли смысл для бизнес логики использовать partial class? Где каждый файл = модуль приложения. В виде одного класса большого (partial). Например: game.character.cs, game.war.cs, game.trade.cs и т.д.
пишу на пхп, но тема про ооп прям ок идёт ) вот бы такими же простыми словами о том, как быстро настраивать томкат поверх апача с поддержкой нескольких доменов и чтобы все на 80 порту были и не конфликтовали 😂 (не спрашивайте зачем, - у каждого свои извращения)
Стараюсь всегда ООП использовать, но на маленьких 1-2 месячных промо-проектах обычно нет смысла разворачивать большие системы, поэтому чаще всего всё сводится к использованию микро-фреймворка, MVC, обработчиков ajax-запросов, и парочки своих классов для частых задач с возможностью быстрых правок. Поэтому иногда залезаю сделать что-нибудь на джаве и ловлю себя на мысли, что на пхп использую ООП не полностью. )
Потому что, в геттерах/сеттерах кроме гета/сета можно добавить дополнительную логику, плюс запрет на изменение того, что изменяться не должно по логике работы класса, внутренние переменные какие-нибудь или что-то вроде того
Когда ваш класс станет родительским и не факт что вы делали наследника,а вы решите поменять тип такого параметра, то ой как не проще будет. Чуть выше я приводила пример при замене поля возраст на дата рождения. Можно еще пример с весом, сделали вы класс товар где вес в кг. И поле веса паблик. А дальше вам говорят что нам еще для учета нужны граммы. А у вас уже наследников куча и в каждый теперь еще плюс одно поле засунуть придется. Или же весь учет на граммы перестроить и впихать в каждый наследник формулу перевода граммов в кг и обратно.
В подавляющем большинстве случаев это просто общепринятый бойлерплейт. Но лучше делать так (благо это несложно и генерируется любой ИДЕ), чтобы, если что, было легче поменять логику присвоения/получения или закрыть к чертям некоторые поля. Но вообще, джава - самый консервативный язык. Нигде вы не найдете столько бойлерплейта, как в джава коде.
@@SergeyNemchinskiy ну я думаю многим было бы полезно узнать что это и как работает и для чего нужно и что спринг работает на рефлексии, особенно если объясняют простыми словами. Если снимете было бы неплохо, но как вы посчитаете нужным
@@nephritered4466 если более конкретнее задать вопрос то нужны ли глубокие знания в математике чтобы освоить например Java для написания приложений под Андроид или JS под web разработку или например Python. Дело в том, что опыта в программировании я не имею. Занимаюсь пока что только с HTML и CSS и хотелось бы углубиться. Выучить какой нибудь ЯП а лучше несколько. И найти работу в этой сфере. И я задался вопросом насколько в программировании роляет знания математики при написании различных алгоритмов и т.д.
@@spllit9212 Что джава в Андроиде, что джс во фронт-энде не требуют познаний математики от слова совсем. Писать алгоритмы в обоих этих областях не приходится практически никогда. Математика нужна для разработки игр, дата сайенса, низкоуровнего программирования и всего такого. Для веба нужно знать фреймворки.
Спасибо за видео. Хотелось бы услышать о private package, редко вижу, но идеешка настоятельно рекомендуем его использовать. Плюс интересна тема полиморфизма
статик можно изменить, это не константа. статик определает время жизни объекта - по факту он созадется при старте программы и разрушается при завершении. это скорее всего одинаково во всех языках.
Спасибо за понятное обьяснение) я как раз работаю с синглтоном)) есть плюсы в нём,а есть и минусы) 😝 Интересно про ООП, инкапсуляцию и вообще SOLID - в студию))) 😎😁😜
Немчинский не начал с Адама и Евы? Ты кто такой и что ты сделал с Немчинским?
В продолжение темы: когда следует использовать final?
или protected))
Часто замечал что в разных sdk (например AWS) локальные переменные обьявляются final. Имеет ли это хоть какой-то эффект на перформанс в рантайм / ускоряет ли компайл тайм, или это просто тыкание?
@@rustamibrahimli2113 с protected немного проще - это когда вроде бы private, но надо открыть доступ наследникам.
@@rubik6169 Это скорее показывает, что переменная не меняется в процессе и сразу видно, что это константа. Легче не запутаться в процессе "понимания чужого кода"
@@rubik6169, слышал мнение от авторитетного источника (не в видео Немчинского, но так же это был программист с большим опытом), что final обеспечивает гарантированно тот факт, что значение поля не будет изменено в процессе выполнения программы. Все. Ни на какую производительность оно не влияет.
Статические методы удобно использовать в утилитарных классах, чтобы не создавать экземпляр и вызывать явно.
Уже не говоря о всяких фабриках.
А статические поля в многопотоке еще та попоболь, бывало, что три потока стучалось в одно статическое поле. Только потом додумался завернуть в synchronized, но можно и использовать Atomic, для придания операциям атомарности. Но все равно не покидает ощущение, что сделал какой-то лютый костыль, но по-другому никак не могу сделать
локальные переменные, например
А какие альтернативы статических методов в утилитарных классах? Всегда так писал, да и видел везде, что *Utils - набор статических методов.
Ну, утилитные классы - это нарушение ООП из коробки
Даёшь инкапсуляцию и стримы
Коротко: "static"- поля/методы одни для всех экземпляров данного класса, плюс можно использовать без экземпляра, а прямо с класса, "public" - если вызывается из другого класса, "private" - если вызывается только из данного класса. Вот и всё :) Полезно, кстати, смотреть на нативные классы из JDK.
Не знаю, было ли такое видео или нет (по крайней мере я его не нашел), но не могли бы вы рассказать как в целом собирается интерпрайс проект с джавой? Т.е. весь процесс от начала до конца, заранее, спасибо :)
Интересная тема, только уточните, пожалуйста что имеется в виду - как происходит старт проекта с точки зрения маркетинг-продажа-разработка и тд. или с точки зрения CI/CD или с точки зрения что делает разработчик с новым проектом?
@@SergeyNemchinskiy с точки зрения CI/CD
Не понимаю почему нельзя использовать классы утилиты(со статик методами). Ведь всякие типа Collections, Arrays существуют же. Создааать например какой-то парсер или что-то есть же смысл? Или лучше создать экземпляр такого класса и в многопоточности его защитить через ThreadLocal ?
Смотря какая задача. Если вся работа с парсером - это вызов одного метода с параметром - ну можно и в статик засунуть. Тогда при массовом использовании не придётся каждый раз создавать объект на каждый его вызов.
Если же это парсер какой-то большой сложной структуры, у которого есть состояние, к которому нужно много обращений (и не дай б-г коллбэки), то статику лучше не использовать, получится многопоточность на ровном месте, в то время когда её можно было бы избежать, используя обычный класс.
если ты создал класс, наполненный утилитарными методами - запрети создание его экземпляра. Тогда всё будет ок.
не будет ок. Проблемы многопоточности, поднятые с пола
@@SergeyNemchinskiy многопоточность - тема сложная, в двух словах не откоментишь.
)
нац.кружка
питон смотрит на права доступа... с грустью
Очень мутное описание статических методов. То, как вы описывали в начале про статические методы, больше подходит под описание полей и методов в абстрактных классах или просто в супер классах (вроде они так называются). Мне кажется, что статические методы и поля чаще всего используются для каких-нибудь вспомогательных классах, которые выполняют роль библиотек (например, Math)
Да, расскажите пож-та, в вашей манере ("на пальцах") о методах ООП (инкапсуляция, полиморфизм....)
З величезним задоволенням послухав би теж про інкапсуляцію! Зробіть окреме відео, будь ласка!
+1, я понимаю как они все работают, но мне кажется у меня будет проблема что бы обьяснить собеседующему меня человеку про полиморфизм и абстракцию, я понимаю как и где оно используется, но слов подобрать не получается как мне кажется
@@ilyaserov4150 Вот лучшая лекция по этой теме, для понимания данного вопроса : ruclips.net/video/j-zS42qRv88/видео.html - без привязки к языку :)
Везде, где речь заходит про инкапсуляцию, про неё говорят только то что это не сокрытие. Это говорят настолько часто, что наоборот инкапсуляция стойко ассоциируется с сокрытием.
@@СергейПресняков-о4р Инкапсуляция помогает навести порядок в коде, чтоб меньше было путанец. Тут лучше пояснение зачем нужна Инкапсуляция : ruclips.net/video/j-zS42qRv88/видео.html
- пока лучшего пояснения не встречал и это сокрытие тоже :)
Здравствуйте, Сергей. учусь программировать около 5 месяцев. Начал за собой замечать, что чрезмерно использую гугл, для решения какой-либо задачи. К примеру, мне нужно в потоке загрузить данные с сервера через AsyncTask. Я знаю что мне нужно именно AsyncTask и какие методы в нем, но я не знаю, что именно писать в этих методах. Я гуглю и смотрю как люди реализовывали похожую задачу, и меняю их код на свой лад. Очень бы хотелось услышать, что вы думаете на это счет, думаю очень полезно будет для новичков)
Добро пожаловать в профессию :))) цель программиста решать задачи, а не зубрить справочники и весь синтаксис. Вы должны знать ряд принципов работы, методологию, какие основные компоненты есть и с чем их едят, придерживаться стандартов и знать примерно что найти и главное где искать. Уметь анализировать
и применять на практике полученную информацию. ОК ГУГЛ, это фактически ежедневный рабочий инструмент любого разработчика. Как говорится, всё знает только идиот или шизофреник. Чем чаще вы пользуетесь теми или иными методами и компонентами, тем реже вы заглядываете в справку по ним. Но даже зная их досконально, не используя в работе годик другой, вы потом опять полезете в справку и примеры реализации, это норма.
Это норма. Е.Малышева. Хотя с опытом у тебя наберется свой "набор решений" по базовым и не очень задачам. И применять этот набор будет быстрее и предсказуемее чем гуглить. Но при этом привычка гуглить может оказаться полезной что бы держать руку на пульсе - получать иные решения и пересматривать решения из "своего набора"
я - пожилая плавающая ошибка
Надо не меньше давать доступа, а делать продуманную архитектуру ^^)
Одно из другого вытекает. С нормальной архитектурой нет нужды в кучке паблик полей.
Инкапсуляция и сокрытие данных это РАЗНЫЕ ВЕЩИ,
Про красные машины (статические методы): экземпляр класса - объект. Класс - чертеж, по которому этот объект строится. Static метод/поле принадлежит чертежу. Остальные методы принадлежат объектам.
У статических полей/методов нет проблем с многопоточностью. АБСОЛЮТНО. Это фича статических полей/методов в java...если они финальные
@@Iskledian если нет сокрытия, то нет АБСТРАКЦИИ. Меж тем инкапсуляция лишь распределение данных, и не более.
Вопрос: плюсы и минусы магистратуры в IT. Стоит ли того?
Спасибо, было интересно и полезно послушать.
Зашита от дурака, упрощающая и усложняющая. Все равно, что сказать: "Вася, ты не имеешь права управлять самолетом!". А Вася никогда не хотел. и не захочет, и возможности у него такой не будет.
Про статик методы ошибочное утверждение - проблемы с многопоточностью не метод создает, а небезопасный доступ к данным.
То что разные потоки обращаются к статическому методу не создаст проблем если в методе не происходит работа с общими данными.
Метод это просто код и этот код может быть вызван множеством потоков одновременно.
Но если внутри метода, без какой либо защиты, будет модифицироваться общая для всех переменная, то результат будет не предсказуемым.
static int sum(int a, int b) { return a + b; } - прекрасно будет работать в многопотоке.
почему в java нету модификатора доступа "только чтение", очень удобная штука, как по мне в большинстве случаев подходит, я бы это слелал по умолчанию. В c# кстати есть readonly. А то часто приходится делать переменные private, а потом прописывать гетеры.
А еще вопрос, почему в коде на java часто можно заменить как переменную обьявляют private, а потом прописывать и геттеры и сеттеры, не проще сделать ее паблик?
Вообще вопрос ни хрена ни новичковый, связи иль агрегация. А вот хотелось бы услышать с точки зрения архитектуры мож в каких областях предпочтительней агрегировать, есть ли какие то эвристики или професс опыт на эту тему
У автоэлектриков, плавающая ошибка называется "спорадической"🤘
интересено мнение про swift5 и swiftUI.
Я ждал этой фразы - "вызов методов через интерфейс" :)
Лично у меня сильно другой подход к private vs public(методам):
Инкапсуляция инкапсуляцией, но приватные методы - это далеко не всегда тот механизм, который её обеспечивает. В неопытных руках это гораздо чаще приводит к ухудшению качества кода. Появилось желание написать приватный метод -> подумайте, а правильно ли вы моделируете свой домен, может всё-таки лучше выделить абстракцию, уточнить апи текущего класса... и только тогда уже private. Именно тогда, я могу хоть как то быть уверен, что private используется для сокрытия реализации...
1 Наличие большого кол-ва приватных методов, говорит о вероятном нарушении SRP, а значит в классе поселился "чужой". Другими словами, класс взял на себя слишком много ответственности и стоит задуматься над вынесением этой логики в отдельную абстракцию/абстракции.
2 Приватные методы напрямую не протестируешь! И вы очень азартны, если хотите оставлять большие куски такой логики без проверок....
3 Код приватного метода естественно непригоден к повторному использованию вне класса.
Имхо. И да, инкапсуляция - это в первую очередь, сокрытие от пользователя не только реализации класса, но и возможностей по переводу объекта в неконсистентное состояние, плюс предоставление корректного апи по использованию объекта. Когда я вспоминаю об инкапсуляции, я переживаю именно об этом, а не о том, что нужно срочно по закрывать все лишние открытые методы. Успеем закрыть, кончено пабликами не стоит злоупотреблять, и уж тем более не надо просто так клепать. Но бяка не здесь.... А вот отсутствие продуманного интерфейса(api) и наличие большого кол-ва private методов - вот настоящее зло. Код не тестируемые, тяжело поддерживаемый. Ну и в конце концов, клиент сам виноват, что при наличии официального контракта(интерфейса) завязался на паблик методы, которые автор класса и поддерживать не обязан.
Просто тестировать нужно АПИ, а не приватные методы, если мы говорим о CI/CD. Если тестируешь локально, то просто на время тестирования делаешь их пабликом. Нарушения SRP никакого не вижу, если в приватных методах ты создаешь нужные объекты и вызываешь их методы. АПИ классы несут в себе много логики под капотом и разбивать их, чтобы соблюсти идеальный SRP, будет неудобно для пользователя.
@@augustjoyce3504
1 *_"Просто тестировать нужно АПИ"_* - естественно. Только в реалиях, api - это айсберг, а тупое следование принципу прикопать под ковер приводит к тому, что 70% логики в итоге в приватных методах. Да даже хоть 20%, вы думаете это не надо тестировать? Если вы будете тестить это через апи - у вас будет комбинаторный взрыв входных данных. И я всёравно уверен, что куча приватных if'ов так и останутся не покрытыми тестами.
2 *_"если мы говорим о CI/CD. "_* - вообще не понял при чём здесь это сейчас.
3 *_"Если тестируешь локально, то просто на время тестирования делаешь их пабликом."_* - даже комментировать не хочется.
4 *_"АПИ классы несут в себе много логики под капотом и разбивать их, чтобы соблюсти идеальный SRP, будет неудобно для пользователя."_* - SRP, сам по себе, это не самоцель. А вот легко поддерживаемый и тестируемый код - да!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! ИНТЕРЕСНО !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
Сергей, про полиморфизм расскажи
Спасибо, понял смысл модификатора static/
Дядя Сережа, расскажи про инкапсуляцию. Очень туго усваиваются все эти статики и не статики, и что делать совершенно непонятно((
расскажу, да
Тем временем класс Programm в C#: привет Я static class, у меня все методы статичны
В си шарп Program класс уже можно и не писать)
Сергей, а есть в планах инверсия контроля для новичков? Сколько читаю и попробую, до конца догнать не могу.
ruclips.net/video/Bw6RvCSsETI/видео.html
Я хоть и прекрасно разбираюсь в ООП, но послушать было интересно)))
Спасибо))
спасибо
Если прекрасно разбираешься, то расскажи, зачем нужен абстрактный класс.
Немчинский как-то пытался объяснить, вышло очень невнятно.
@@gordonfreeman1842 и тут
Сергей Пащенко замолчал.......
@@jamade3687 ну да, щёки надувать-то все умеют, а как до дела доходит ...
@@gordonfreeman1842, я, конечно не эксперт в ООП, но вроде он нужен в такой ситуации:
в компании о разработке сайта надо обработать из базы данных какую-то информацию, есть 2 группы программистов, одна должна написать класс, где будут средства, для того чтобы вытаскивать по-особому данные из БД, а вторая будет их обрабатывать. Но поскольку работа идет параллельно, то вторая не может работать, пока не закончит работу первая. И тут в дело вступают абстрактные классы и интерфейсы. Вторая группа создает абстрактный класс, где описывает поля и методы, с которыми они будут работать. И теперь они использует эти методы в своем проекте, и когда они завершат работу над своей часть уже будет готова остальная
Вау круто
Как бы ты не пытался скрыть поля в Java, как не крути ты все равно можешь до них достучаться, потому что Java работает на JVM, а через JVM можно легко получить нужный класс и его поля используя рефлексию:) Увы это не С++ или C#, хотя в C# тоже есть вроде как рефлексия.
Бугаенко ругает и клеймит static.
при всей моей нелюбви к Бугаенко - иногда он говорит банальные и поэтому верные вещи
Как тестировать private метод?
Если есть нужда тестировать приватный метод - надо выносить его в отдельный класс. Всё просто
есть public метод A, который вызывает приватные методы B,C. В тесте мне нужно доказать что в нужном мне случае вызвался B, и не вызвался C и наоборот. Можно сделать mock, на нем считать количество вызовов. Но вся беда в приватности методов.
Вопрос: что ты хочешь протестировать - интерфейс или алгоритм/код?
Если интерфейс, то зачем пытаться как-то тестирова приватные методы?
Если код/алгоритм, то да, надо выносить в отдельный класс
Если речь о java, то можно сделать метод package private.
Тест разместить в том же пакете, что и класс содержащий тестируемый метод.
@@SkyAntins за reflection отрубаю руки коллегам программистам
Сергей, спасибо за Ваши видео. С примерами кода было бы ещё круче)
С примерами кода только путанее получается, пробовал
private или protected?
package-private
если ты хочешь, точнее, если ты планируешь, чтобы подклассы получили доступ к полю/методу - protected. Иначе - private
причем поля всегда - private
@@SecretRUclipsAgent это я к тому что между ними разницы особой нету, без наследования. Да, с протектед можно зафакапить код, но это так же легко как и с привате.
Как по мне это отголосок той далекой эпохи когда все умудрялшись вкладывать в 40 килобайт програму, костыли для програмы и еще и пасхалку с сейлормун засунуть.
Что то уровня "названия полей и методов должны быть короткими". Щас даже бюджетные процессоры могут работать с переменными с километровым названием. А если язык компилируемый то тут вообще не важно как ты переменную назоввешь, компилятор название выбросит все равно.
Я так понял, что статик используют когда нужна самая обычная функция. Та самая из функционального прокграммирования. Но вера и/или язык не позволяют просто создать функцию. Приходится городить объект со статик методом :)
Реализация singletone и фабричного метода через static - тоже плохая идея?
Скользкий тип
так не смотрите, не мучайте себя
☺
согласен. Я то же так делаю. Делаю сначала все private. А потом если нужно открываю доступ через public.
Спасибо большое, как всегда все понятно.
Like!
Интересна, интересна!
хорошие видео, но проф СЛЭНГ - плохой тон)
Смешно, 3 года как новичок) Боюсь static классов как огня и по этому ими не пользуюсь)
То есть Вы не развиыаетесь
@@katerinak5997 нет(
@@ИванКожановский-щ6х значит надо начинать)
@@katerinak5997 я бы и с радостью, но банк говорит что нужно выплатить кредит сначала ) а вообще уже начал учить Котлин. Начал писать своё приложение. UI мне уже сделали в подарок на ДН. Дело за малым )
@@ИванКожановский-щ6х круто продолжайте в том же духе=)
Инкапсуляцию!
В своё время тоже были проблемы с пониманием использования static, для себя вывел такую аналогию, что есть класс "свинарник", внутри него есть поле "кормушка" которое является статическим и доступно для каждой свиньи в свинарнике
Паша Назин
то есть у тебя свинья будет экземпляром свинарника?
А можно про методы гденить у Вас подсмотреть?
интересно
Мне как JS разработчику так и не понятно в чем плохо все делать public. Можно описать какой-нибудь практический пример по этому поводу?
Рефакторинг и исправление ошибок. Бахнули вы класс Person, с полем age у которого интовое значение и данные которого сохраняются в базе данных. В результате в 2018 Анне 18 лет. Вопрос, сколько ей будет в 2019 и 2020м? Верно, все так же 18, т.к. хранить надо было дату рождения. И вот вы модифицировали базу и класс персон, теперь есть поле дата рождения и для родительского класса всё ок, чего не скажешь о наследниках, особенно сделанных не вами, а другими разрабами на своих проектах (Students, Customers, Employees и т.п.). Работая через методы у вас есть возможность решить проблему заменой алгоритма гетторов и сетеров в родительском классе, получить дату рождения расчетным путем и возраст (исходя из текущей даты). Сделав поле возраст публичным и призвав прописывать алгоритмы присвоения назначения в наследуемых классах вы вырыли себе и другим яму. Понятно что пример несколько упрощен с математической точки зрения, но общая суть необходимости сетеров и гетеров думаю ясна.
А как тогда заменяется статический метод например Helper.getCountryCodeByIp(String ip). Т.е. если так плохо, то как лучше делать?
this.countryCodeService.getByIp(String ip)
Сергей, просьба поделиться вашими соображениями, чем классы принципиально отличаются от структур в процедурном программировании, для работы с которыми определены функции
Я, конечно, не Сергей, но могу сказать, что классы - это следующая ступень эволюции структур.
Отличие в том, что структура рассматривается в первую очередь как набор данных, а функции играют лишь вспомогательную роль. Класс же рассматривается как представление объекта предметной области с его поведением, а данные, содержащиеся в нём, уходят на второй план.
В целом эти вещи довольно близки с точки зрения кода (в С++ структуры вообще реализованы на базе классов), но различаются по смыслу и предназначению.
Расскажите, пожалуйста, какую роль играет web в java enterprise.
Эм.... так морда в энтерпрайзе всегда веб
Спасибо
По умолчанию, когда пишу новый метод, ставлю private. Можно сказать, рефлекторно.
А я Public реылекторнг ставлю)
Интересно!
В продолжении темы. Когда целесообразно абстрактным классам давать final?)
Слабенькое продолжение. Никогда
Сними видео о полиморфизме)
сниму
следующий выпуск - доступ к приватным полям через рефлексию
не надо вот это вот :)
Давайте про инкапсуляции. У Вас хорошо получается объяснять.
в планах :)
Привет! Раскрытие темы инкапсуляции в формате ответов на новичковые вопросы актуально.
Хорошо, запишу видео про ООП
Да нам всё интересно. Ты главное рассказывай.
вот уж точно буду :)
Есть ли смысл для бизнес логики использовать partial class? Где каждый файл = модуль приложения. В виде одного класса большого (partial). Например: game.character.cs, game.war.cs, game.trade.cs и т.д.
в смысле файлы с 10 тысячами строка?) а пакеты для кого придуманы?
@@maxlich9139 я про c#
пишу на пхп, но тема про ооп прям ок идёт ) вот бы такими же простыми словами о том, как быстро настраивать томкат поверх апача с поддержкой нескольких доменов и чтобы все на 80 порту были и не конфликтовали 😂 (не спрашивайте зачем, - у каждого свои извращения)
РНР - это отличный ООП язык. если вы пишете на нем процедурно - вы себя обкрадываете
Стараюсь всегда ООП использовать, но на маленьких 1-2 месячных промо-проектах обычно нет смысла разворачивать большие системы, поэтому чаще всего всё сводится к использованию микро-фреймворка, MVC, обработчиков ajax-запросов, и парочки своих классов для частых задач с возможностью быстрых правок.
Поэтому иногда залезаю сделать что-нибудь на джаве и ловлю себя на мысли, что на пхп использую ООП не полностью. )
Почему в коде на java часто можно заменить как переменную обьявляют private, а потом прописывать и геттеры и сеттеры, не проще сдель ее паблик?
Потому что, в геттерах/сеттерах кроме гета/сета можно добавить дополнительную логику, плюс запрет на изменение того, что изменяться не должно по логике работы класса, внутренние переменные какие-нибудь или что-то вроде того
Когда ваш класс станет родительским и не факт что вы делали наследника,а вы решите поменять тип такого параметра, то ой как не проще будет. Чуть выше я приводила пример при замене поля возраст на дата рождения. Можно еще пример с весом, сделали вы класс товар где вес в кг. И поле веса паблик. А дальше вам говорят что нам еще для учета нужны граммы. А у вас уже наследников куча и в каждый теперь еще плюс одно поле засунуть придется. Или же весь учет на граммы перестроить и впихать в каждый наследник формулу перевода граммов в кг и обратно.
В подавляющем большинстве случаев это просто общепринятый бойлерплейт. Но лучше делать так (благо это несложно и генерируется любой ИДЕ), чтобы, если что, было легче поменять логику присвоения/получения или закрыть к чертям некоторые поля. Но вообще, джава - самый консервативный язык. Нигде вы не найдете столько бойлерплейта, как в джава коде.
Всегда есть reflection. Этим всё сказано...
за рефлекшн в продакшн коде тебе руки поотрывают
@@SecretRUclipsAgent А нафиг тогда он нужен?
@@DoctorKrolic он предназначен для создания фреймворков, IDE и т.п.
блин, никто не написал, что музыка на фоне мешает. значит походу я один такой
Там есть музыка???))
@@0imax проверил еще раз, есть
Про рефлексию нужно снять и интересно было бы от вас послушать про спринг, когда новичковые и мидл будут видосы по спрингу?))
Про рефлекшн я не уверен, что надо снимать. надо? А про спринг - скоро будут
@@SergeyNemchinskiy ну я думаю многим было бы полезно узнать что это и как работает и для чего нужно и что спринг работает на рефлексии, особенно если объясняют простыми словами. Если снимете было бы неплохо, но как вы посчитаете нужным
@@SergeyNemchinskiy о, это отлично) давно жду. Спасибо за простое объяснение и примеры, это помогает
Может ли человек не обладающий талантом в математике освоить программирование на достойном уровне?
@@nephritered4466 если более конкретнее задать вопрос то нужны ли глубокие знания в математике чтобы освоить например Java для написания приложений под Андроид или JS под web разработку или например Python. Дело в том, что опыта в программировании я не имею. Занимаюсь пока что только с HTML и CSS и хотелось бы углубиться. Выучить какой нибудь ЯП а лучше несколько. И найти работу в этой сфере. И я задался вопросом насколько в программировании роляет знания математики при написании различных алгоритмов и т.д.
@@nephritered4466 Это был тот самый Яков? Хм, интересно
@@spllit9212 Что джава в Андроиде, что джс во фронт-энде не требуют познаний математики от слова совсем. Писать алгоритмы в обоих этих областях не приходится практически никогда. Математика нужна для разработки игр, дата сайенса, низкоуровнего программирования и всего такого. Для веба нужно знать фреймворки.
ruclips.net/video/2A_l9aKVNqM/видео.html
Спасибо за видео. Хотелось бы услышать о private package, редко вижу, но идеешка настоятельно рекомендуем его использовать.
Плюс интересна тема полиморфизма
Статик есть константа, так мне кажется понятнее)
статик можно изменить, это не константа. статик определает время жизни объекта - по факту он созадется при старте программы и разрушается при завершении. это скорее всего одинаково во всех языках.
@@vladimir0rus согласен с вами
Спасибо за понятное обьяснение) я как раз работаю с синглтоном)) есть плюсы в нём,а есть и минусы) 😝
Интересно про ООП, инкапсуляцию и вообще SOLID - в студию))) 😎😁😜
Это немного разные топики, но запишу и то и другое постепенно
Sergey Nemchinskiy спасибо 🙏🏻 жду с нетерпением)))
Maria Navalnaya
нет плюсов у синглтона, это антипаттерн.
ну это уже слишком, на кого это расчитано?
другие комментарии почитайте и вылезайте, наконец, из информационного пузыря