Там не нужны все эти фортеля с захватом ресурсов, блокировками и прочим, обработкой ошибок. Если у вас к примеру есть некий логгер, просто выделяете процесс отдельный. Падает процесс, файл автоматически закрывается. Процесс обрабатывает поступающие ему сообщения по одному последовательно, и только он имеет доступ к этому файлу, поэтому блокировать ничего не нужно.
Функция вывода на консоль не будет детерминированной. Взять к примеру случай, когда консоль вдруг становится недоступна (а такое бывает, если например это какое-то терминальное устройство) и мы получаем исключение. В случае «нечистых» функций таких «если», может быть порядочно, чтобы с уверенностью заявить, что функции не являются детерминированными.
лямбды с помощью композиции функций можно комбинировать. естественно один обход со сложной комбинированной лямбдой будет эффективнее трех обходов с простыми.
да, точно, стратегия. но это не функциональный подход, а самый что ни на есть ООП. В функционально мне было бы достаточно передать функцию, вместо того, чтобы городить интерфейсы, но принцип да, тот же.
Инкапсуляция это
1) технические меры, которые предпринимаются для того, чтобы не допустить неправильного использования класса. Именно технические, а не описания навроде «вызывайте это в таком порядке потому что иначе не работает». Это кстати называется принципом инварианта. собственно инкапсуляция и позволяет сохранять инвариант. Случай с именами вырожден, это очевидно, но существуют и более сложные случаи.
2) исключение использования данных одного класса внутри другого. Каждый класс несет ответственность за свои данные и не должен нести ответственность за данные другого класса.
Нужна она для уменьшения связности кода и разделения зон ответственности.
тогда что же тут некоторые личности заливали, что истинное ООП сделает ваш код идеальным? если даже такие вещи как инкапсуляция — это не свойство ООП, а свойство решения разработчика?
Но вы же не пишете мне «Здравствуй владелец такого-то счета в таком-то банке».
Кстати отличный пример, большинство комментариев не содержат в себе имени адресата. Логика того, кому комментарий отправлен скрыта. Порой даже не задумываются, кому пишут комментарии, потому что это и не надо. Есть кнопка «ответить» и поле для ввода текста.
Окей, тогда вся идея инкапсуляции не имеет смысла. Я пишу в документации, что поля публичные и используте как хотите. так же пишу, что вот это метод нельзя вызывать пока не проинициализировано вот это поле, и пока не вызван вот этот метод. Не, а что такого? в документации-то описано.
В свое время меня повеселила какая-то либа (по-моему DirectDraw или что-то в этом роде), в который был такой код:
SomeClass c = new SomeClass();
c.SetValue1(1);
c.SetValue2(2);
c.DoSomeWork();
Причем в документации был описан порядок, но от этого легче не становилось
Ну это чистое ООП без всяких нарушений. я не говорил, что это идеальное практическое решение. но инкапсуляция зато есть, никто не знает структуры других объектов.
По поводу злоупотребления. Есть принцип OCP, который гласит, что классы должны быть закрыты для модификации, но открыты для расширения.
А так да. ООП вообще славен многословностью. В данном примере с тем же успехом можно сделать и без ООП и будет проще.
ну то есть по вашей логике нарушением инкапсуляции не будет то, что я указал, что это не нарушение инкапсуляции в комментарии или документации?
инкапсуляция — это архитектурное понятие, а не понятие реализации и документации.
Инкапсуляция это
1) технические меры, которые предпринимаются для того, чтобы не допустить неправильного использования класса. Именно технические, а не описания навроде «вызывайте это в таком порядке потому что иначе не работает». Это кстати называется принципом инварианта. собственно инкапсуляция и позволяет сохранять инвариант. Случай с именами вырожден, это очевидно, но существуют и более сложные случаи.
2) исключение использования данных одного класса внутри другого. Каждый класс несет ответственность за свои данные и не должен нести ответственность за данные другого класса.
Нужна она для уменьшения связности кода и разделения зон ответственности.
Кстати отличный пример, большинство комментариев не содержат в себе имени адресата. Логика того, кому комментарий отправлен скрыта. Порой даже не задумываются, кому пишут комментарии, потому что это и не надо. Есть кнопка «ответить» и поле для ввода текста.
OCP применим в том, что я не изменяю класс Person, для новых приветствий, а просто передаю другой билдер.
В свое время меня повеселила какая-то либа (по-моему DirectDraw или что-то в этом роде), в который был такой код:
Причем в документации был описан порядок, но от этого легче не становилось
По поводу злоупотребления. Есть принцип OCP, который гласит, что классы должны быть закрыты для модификации, но открыты для расширения.
А так да. ООП вообще славен многословностью. В данном примере с тем же успехом можно сделать и без ООП и будет проще.
инкапсуляция — это архитектурное понятие, а не понятие реализации и документации.