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