(продолжение пред. поста)
Если метод a использует внутри себя метод b, который может выбросить checked исключение, то метод a должен:
1. Или заключить вызов метода b в try/catch блоки
2. Или/и объявить, что он тоже может выбросить это checked исключение или его super класс.
Error - это очень серьезные ошибки, который не могут быть напрямую контролированы вашей программой.
Error'ы могут быть объявлены, но объявлять error'ы считается глупой практикой. Некоторые error'ы могут быть обработаны, но это тоже будет очень глупой затеей. Error'ы, как и runtime исключения считаются unchecked.
⟡ Checked exceptionsЕсли метод a использует внутри себя метод b, который может выбросить checked исключение, то метод a должен:
1. Или заключить вызов метода b в try/catch блоки
2. Или/и объявить, что он тоже может выбросить это checked исключение или его super класс.
⟡ ErrorError - это очень серьезные ошибки, который не могут быть напрямую контролированы вашей программой.
Error'ы могут быть объявлены, но объявлять error'ы считается глупой практикой. Некоторые error'ы могут быть обработаны, но это тоже будет очень глупой затеей. Error'ы, как и runtime исключения считаются unchecked.
#java
Важные моменты в исключениях
Важные моменты в исключениях
⟡ Очередность catch блоков очень важна. Компилятор не пропустит код, если исключение "супер класс" будет стоять перед исключением "дочерний класс".⟡ Если в части кода, которая не находится в блоке try или в блоке try выбрасывается исключение, то соответствующая оставшаяся часть кода уже не обрабатывается.⟡ После выброса исключения мы можем увидеть стэк трейс (1) для всех методов, задействованных в выбросе этого исключения.⟡ При создании объекта исключения вы можете воспользоваться его конструктором, который принимает String параметр и вписать в него необходимую информацию. Вы также можете воспользоваться конструктором, который не принимает параметры.⟡ finally блок выполняется в том случае, если в try блоке или в catch блоке имеется return statement.⟡ finally блок не выполнится только в том случае, если вы прекращаете работу программы с помощью System.exit в try или в catch блоке или же, если происходит "крушение" JVM или, например, операционной системы.⟡ Если return statement имеется и в catch блоке и в finally блоке, то аутпутом метода будет возвращаемое значение из finally блока.(1) Про это позже будет пост#java
Лямбда выражения
( Поскольку пост вышел довольно объемным, сделал его в телеграфе. Удобная штука оказалась )
https://telegra.ph/Lyambda-vyrazheniya-06-06
Лямбда выражения
( Поскольку пост вышел довольно объемным, сделал его в телеграфе. Удобная штука оказалась )
https://telegra.ph/Lyambda-vyrazheniya-06-06
Telegraph
Лямбда выражения
Как всегда, начнем с неудобств, которые решают лямбды) Имеется обычный класс, Employee. Поля - имя, департамент, ЗП. Есть задача - отфильтровать сотрудников. Если бы фильтрация была одноразовой, за каким-то одним параметром, проблем бы не было. Но, фильтровать…
#java
Встроенные функциональные интерфейсы
Решил написать сначала о функциональных интерфейсах, все-таки, это база для StreamAPI. Кстати, следующий пост будет о именно о них.
https://telegra.ph/Vstroennye-funkcionalnye-interfejsy-06-11
Встроенные функциональные интерфейсы
Решил написать сначала о функциональных интерфейсах, все-таки, это база для StreamAPI. Кстати, следующий пост будет о именно о них.
https://telegra.ph/Vstroennye-funkcionalnye-interfejsy-06-11
Telegraph
Встроенные функциональные интерфейсы
Как и упоминалось в предыдущем посте, разработчики Java создали довольно много функциональных интерфейсов. Рассмотрим основные.
#web
Модель OSI. Кратко.
7. Прикладной уровень - это единственный уровень который работает с пользователем и пользовательскими данными.
6. Уровень представления - данные с 7 уровня преобразуются в массив байт, возможно происходит сжатие и шифрования данных.
5. Сеансовый уровень - открывает соединение, и передает данные транспортному уровню.
4. Транспортный уровень - разбивает огромный массив байт на сегменты и добавляет к каждому сегменту свой заголовок в виде портов приложений откуда передается информация куда.
3. Сетевой уровень - разбивает сегменты на IP-пакеты, также добавляет свой заголовок.
2. Канальный уровень - разбивает эти пакеты на фреймы(кадры), добавляет заголовки.
1. Физический уровень - фреймы переходят на физический уровень, и через кабель или вайфай, мы преобразуем каждый из этих кадров в последовательность нулей и единиц, которые передаются на наш маршрутизатор или свитч.
После получения данных вторым устройством, начинается обратное преобразование последовательности нулей и единиц в данные прикладного уровня.
Каждый из протоколов знает как работать с протоколами смежных уровней.
Модель OSI. Кратко.
7. Прикладной уровень - это единственный уровень который работает с пользователем и пользовательскими данными.
6. Уровень представления - данные с 7 уровня преобразуются в массив байт, возможно происходит сжатие и шифрования данных.
5. Сеансовый уровень - открывает соединение, и передает данные транспортному уровню.
4. Транспортный уровень - разбивает огромный массив байт на сегменты и добавляет к каждому сегменту свой заголовок в виде портов приложений откуда передается информация куда.
3. Сетевой уровень - разбивает сегменты на IP-пакеты, также добавляет свой заголовок.
2. Канальный уровень - разбивает эти пакеты на фреймы(кадры), добавляет заголовки.
1. Физический уровень - фреймы переходят на физический уровень, и через кабель или вайфай, мы преобразуем каждый из этих кадров в последовательность нулей и единиц, которые передаются на наш маршрутизатор или свитч.
После получения данных вторым устройством, начинается обратное преобразование последовательности нулей и единиц в данные прикладного уровня.
Каждый из протоколов знает как работать с протоколами смежных уровней.
#java #design
Почему композиция лучше наследования?
GoF: «Предпочитайте композицию наследованию класса».
Гибкость – это конечно полезная черта дизайна. Однако при выборе архитектуры нас интересуют в первую очередь сопровождаемость, тестируемость, читабельность кода, повторное использование модулей. Так вот с этими критериями хорошего дизайна у наследования проблемы.
Проблема хрупкого базового класса
Одним из основных критериев хорошей архитектуры является слабое зацепление (loose coupling), которое характеризует степень взаимосвязи между программными модулями. Не зря слабое зацепление входит в перечень паттернов GRASP, описывающих базовые принципы для распределения ответственности между классами.
Слабое зацепление имеет массу преимуществ!
Ослабив зависимости между программными модулями, вы облегчаете сопровождение и поддержку системы за счет формирования более гибкой архитектуры.
Появляется возможность параллельной разработки слабозацепленных модулей без риска нарушить их функционирование.
Логика работы класса становится более очевидной, легче становится использовать класс правильно и по назначению, и сложно использовать – неправильно.
Почему композиция лучше наследования?
GoF: «Предпочитайте композицию наследованию класса».
Гибкость – это конечно полезная черта дизайна. Однако при выборе архитектуры нас интересуют в первую очередь сопровождаемость, тестируемость, читабельность кода, повторное использование модулей. Так вот с этими критериями хорошего дизайна у наследования проблемы.
Проблема хрупкого базового класса
Одним из основных критериев хорошей архитектуры является слабое зацепление (loose coupling), которое характеризует степень взаимосвязи между программными модулями. Не зря слабое зацепление входит в перечень паттернов GRASP, описывающих базовые принципы для распределения ответственности между классами.
Слабое зацепление имеет массу преимуществ!
Ослабив зависимости между программными модулями, вы облегчаете сопровождение и поддержку системы за счет формирования более гибкой архитектуры.
Появляется возможность параллельной разработки слабозацепленных модулей без риска нарушить их функционирование.
Логика работы класса становится более очевидной, легче становится использовать класс правильно и по назначению, и сложно использовать – неправильно.
#utils #definition
Grafana — лучший дашборд для метрик
Graphana — первый действительно хороший дашборд для отображения метрик.
Метрика - мера, позволяющая получить численное значение некоторого свойства программного обеспечения или его спецификаций.
Graphana предназначена для отображения всевозможных циклических метрик. Помимо предопределенных системных метрик (CPU, IO, etc..), можно сконфигурировать любой набор произвольных метрик — онлайн, профит и т.д. Graphana имеет две встроенных темы оформления — обе выглядят очень хорошо. Можно создать любое количество произвольных дашбордов.
Grafana — лучший дашборд для метрик
Graphana — первый действительно хороший дашборд для отображения метрик.
Метрика - мера, позволяющая получить численное значение некоторого свойства программного обеспечения или его спецификаций.
Graphana предназначена для отображения всевозможных циклических метрик. Помимо предопределенных системных метрик (CPU, IO, etc..), можно сконфигурировать любой набор произвольных метрик — онлайн, профит и т.д. Graphana имеет две встроенных темы оформления — обе выглядят очень хорошо. Можно создать любое количество произвольных дашбордов.
Все Enums наследуются от класса
Anonymous Quiz
6%
Enums
10%
java.lang.Enums
23%
Это специальный тип, у него нету наследника
35%
Object
25%
java.lang.Enum
#java #testing
Для чего вообще нужно тестирование?
Недавно узнал, что не все начинающие разработчики понимают, почему тестирование необходимо и почему на него так много тратят времени.
Написание тестов, это всегда минимум 40% от выполнения каждого моего таска. Юнит-тесты, интеграционные, и тесты на взаимодействие с другими сервисами. Чем больше возможных ситуаций можно предугадать, тем лучше.
Юнит-тесты конечно простейшие. Вы с ними точно встречались, если делали какие-то задачи на LeetCode, или Codewars. Вы просто выделяете маленький блок кода, класс и его методы, даете определенные данные на вход и проверяете, что получаете на выходе. Это самый быстрый и наименее эффективный способ проверить, все ли работает корректно, ведь, если метод работает корректно сам по себе, это не значит, что он будет работать корректно в самой системе. Вот здесь нам и нужны интеграционные тесты.
При имплементации сложных решений, например создание больших фич, как переписывание утилитарного класса на другую библиотеку, необходимо писать интеграционные тесты. Интеграционные тесты, это по сути много юнит-тестов. Вы берете класс и проверяете, как он будет взаимодействовать с другими классами в вашей системе. Хорошие интеграционные тесты требуют написания тысяч линий кода, поэтому иногда приходится писать собственные фреймворки для тестирования.
Ну вот я проверил, что все правильно работает, для чего мне оставлять тысячи линий кода в проекте, если все и так работает?
Тесты часто вам помогают убедиться, что новая фича ничего старого не поломала. При хорошем деплойе проходят все тесты и, если что-то пойдет не так, то поблагодарите тестам, что это не случилось на проде и к вам домой не едет CEO.
Пишите много тестов.
Для чего вообще нужно тестирование?
Недавно узнал, что не все начинающие разработчики понимают, почему тестирование необходимо и почему на него так много тратят времени.
Написание тестов, это всегда минимум 40% от выполнения каждого моего таска. Юнит-тесты, интеграционные, и тесты на взаимодействие с другими сервисами. Чем больше возможных ситуаций можно предугадать, тем лучше.
Юнит-тесты конечно простейшие. Вы с ними точно встречались, если делали какие-то задачи на LeetCode, или Codewars. Вы просто выделяете маленький блок кода, класс и его методы, даете определенные данные на вход и проверяете, что получаете на выходе. Это самый быстрый и наименее эффективный способ проверить, все ли работает корректно, ведь, если метод работает корректно сам по себе, это не значит, что он будет работать корректно в самой системе. Вот здесь нам и нужны интеграционные тесты.
При имплементации сложных решений, например создание больших фич, как переписывание утилитарного класса на другую библиотеку, необходимо писать интеграционные тесты. Интеграционные тесты, это по сути много юнит-тестов. Вы берете класс и проверяете, как он будет взаимодействовать с другими классами в вашей системе. Хорошие интеграционные тесты требуют написания тысяч линий кода, поэтому иногда приходится писать собственные фреймворки для тестирования.
Ну вот я проверил, что все правильно работает, для чего мне оставлять тысячи линий кода в проекте, если все и так работает?
Тесты часто вам помогают убедиться, что новая фича ничего старого не поломала. При хорошем деплойе проходят все тесты и, если что-то пойдет не так, то поблагодарите тестам, что это не случилось на проде и к вам домой не едет CEO.
Пишите много тестов.
