@SpringBootTest
class PrimaryExampleApplicationTests {
@Autowired
BankService messageService;
@Test
public void testing(){
Bank newBank1 = messageService.getNewBank();
Bank newBank = messageService.getNewBank(); // <- Это здесь не нужно. getNewBank() возвращает всегда один и тот же прокси объект. А вот при обращении к прокси объекту внутри него идет создание каждый раз нового прототипа.
System.out.println(newBank.getInput());
System.out.println(newBank1.getInput());
}
}
Такой код даст такой же результат:
@SpringBootTest
class PrimaryExampleApplicationTests {
@Autowired
BankService messageService;
@Test
public void testing(){
Bank newBank = messageService.getNewBank();
System.out.println(newBank.getInput());
System.out.println(newBank.getInput());
}
}
Подход может подойти для обработкчиков каких-нибудь, чтобы в них можно было хранить состояния на время выполнения обработки. Ну а вообще подход извращенный, гораздо проще через контекст доставать бины прототипа.
EPAM никого никуда не перевозил, до последнего не было точности, а был посыл переезжать за свой счёт, причем условия компенсации не озвучивались четко. Ещё говорили, что сроки на программу релокации сохраняются, многие вообще надеялись, что получится раньше релоцироваться, а по итогу, на сколько мне потом стало известно из чатов, все сроки обнулились, так как смена компании на компанию в другой стране. У меня оставалось 6 месяцев до поездки в штаты, но я не стал дёргаться, как выяснилось не зря.
Прошло почти 10 лет, idea таки сильно потеснила eclipse. Но теперь idea бесит тем, что за деньги получаешь баги, которые долго исправляются, после обновлений порой бывают тормоза. Периодически приходится перезапуска сбрасывая кеш. Использую очень активно на порядка 50 отдельных проектах (микросервисы).
Не исключено, что в будущем нас ждут общественные квадрокоптеры, которые будут летать по строгим траекториям. Возможно технически это реализовать ещё проще, чем беспилотные автомобили, ведь тут будут две площадки, между которыми он будет курсировать. Хотя отсутствие засилия служб доставок квадрокоптерами наталкивает на смысл, что не все так гладко в этой области.
Это не старая школа, а классические определения, не привязанные к языку или семейству языков типа «C++ образных».
Большая часть продуктов все равно на них, а опыт был получен в резальтате их использования.
В массивах нет методов, можно функции в них хранить, не более. И да, ООП именно для организации вместе данных и подпрограмм их обработки, а сокрытие ему ортогонально. Например, в некоторых языках есть сокрытие уровня модуля или сборки, никак к ООП не относящееся.
Но ООП без сокрытия это сущий ад.
Status: Implemented (in PHP 7.4)
Но релиз-то еще только в конце 2019 и оно еще может быть перенесен. А пока повсеместно начнут использовать, так появится еще куча кода в старом стиле.
Количественные оценки этого «гораздо больше» есть? Они учитывают возможность использования магического метода __set(), если вот прямо срочно нужно?
А разыскивать где атрибут изменился вроде ничуть не сложнее, чем разыскивать где же сеттер вызвался.
А вот тут мы идем как раз по типичной дорожке к запутанному коду. Magic методы вообще губительны как для проекта, так и для ООП. В этом случае предполагается, что вы знаете код, и как там работают эти магические методы. Об автокомплите тоже можно забыть, так как «Метод __set() будет выполнен при записи данных в недоступные свойства. », т.е. придется сначала убарть атрибут, чтобы заработал методы, а значит пропадет автокомплит. Ну и искать где он там меняется все же сложнее, чем искать вызовы метода.
В 4-й версии модификаторов доступа не было, все члены класса были публичными.
Ну вы вспомнили. Даже 5 уже устарел. Меня смущает упоминание 4 версии. Если у вас старая школа, я вас не переубежу.
К чему вы будете $this привязывать?
Так, тут вообще зарулили не туда, изначально суть была вообще в другом. ООП позволяет хорошо организовать, массивы позволяют хранить все те же переменные и методы, но без всякой структуры. Ограничение доступа — один из инструментов сохранения этой структуры.
Можно конечно поизвращаться:
<?php
$a = [
'value' => 1,
];
$a['this'] = function () use ($a) {
return $a;
};
var_dump($a['this']()['value']);
но в PHP тайпхинтинг и для свойств завезли
Серьезно? Похоже, что еще только в проекте. Если разработчик не использует типы, то это уже на его совести.
А практика показывает, что в 99% случаев геттеры/сеттеры так и остаются тупыми, по факту не делая никакого сокрытия, но понимание кода усложняя.
Зато в том 1% случаев вы выиграете гораздо больше чем потеряете, если не будете рефакторить код по всему проекту переводя атрибут на метод, или разыскивая где-эже этот атрибут изменился.
Авторы (навскидку) python, javascript, php (4) решили, что и без сокрытия имеет смысл объединять данные и методы, их обрабатывающие.
PHP то вы зачем сюда приплели, у него с инструментами сокрытия все впорядке.
Будет. К массивам нельзя методы прикрутить, конструкторы, использовать в тайпхинтинге нормально и в инстансоф
Что мешает запихать методы в массив.
Именно. Если делаю публичные геттеры-сеттеры, то только когда понимаю зачем я их делаю. И обычно для меня такие «тупые» геттеры-сеттеры маркер плохого проектирования: если они ничего не делают, кроме сокрытия ради сокрытия, то нет смысла их использовать, это нарушение KISS и YAGNI.
Все с точность до наоборот, они позволяют в момент ограничить входные данные, повзволяют быть уверенным в том, что на входе именно то что ожидаешь, повзволяют расширять код в будущем (к слову о плохой архитектуре). Не раз приходилось сталкиваться с ситуацией, когда было крайне необходимо добавить дополнительную обработку в setter, отловить входной параметр при бебаге, или преобразовать данные при входе/выходе. KISS и YAGNI тут вообще не причем, генерация методов идет на уровне IDE и ничего не усложняет.
preventing unauthorized parties' direct access to them
«Она может использоваться для сокрытия, а может не использоваться.» — только вот использовать её без сокрытия не имеет смысла, и в большинстве случаем их и не разделяют, а если решили разделить, то надо описывать это. В противном случае, привыкнув писать публичные атрибуты и взявшись за что-то более менее сложное, вы и итоге получите бесконечные неуверенности в том, что же у вас там в этом публичном атрибуте хранится.
В большинстве случае публичные атрибуты — зло, исключения составляют случаи когда речь идет о совсем простых классых типа
class Point {
public int x;
public int y;
}
, да вот только в PHP нет типов и туда можно запихать хоть строку например которая вообще не приводится к числу. Методы ограничивают доступ к данным класса и позволяют фильтровать вход. А если будете писать в такой манере, делая публичными методы, то ваш код ничем не будет отличаться от использования массивов.
class Point {
private $x;
private $y;
public function getX(): int
{
return $this->x;
}
public function setX(int $x): void
{
$this->x = $x;
}
public function getY(): int
{
return $this->y;
}
public function setY(int $y): void
{
$this->y = $y;
}
}
Если вы делаете публичные методы, то вы должны точно понимать зачем вы это делаете именно в данной ситуации, и давать себе отчет в том, что это может стать проблемой в будущем.
Да хотябы вот даже определение:
Encapsulation is one of the fundamentals of OOP (object-oriented programming). It refers to the bundling of data with the methods that operate on that data.[5] Encapsulation is used to hide the values or state of a structured data object inside a class, preventing unauthorized parties' direct access to them. Publicly accessible methods are generally provided in the class (so-called getters and setters) to access the values, and other client classes call these methods to retrieve and modify the values within the object. en.wikipedia.org/wiki/Encapsulation_(computer_programming)
Мне одному мозолят глаза public атрибуты в примерах? Инкапсуляция, наследование и полиморфизм до SOLID обычно продаются. Если уж давать примеры, то сразу по всем канонам, ничего бы не усложнилось сильно.
Вообще все зависит от случая. Есть много примеров, когда небольшой семейный бизнес по продаже шмотья приносить прибыль, которая позволяет не работать пару месяцев летом. Или наоборот работаешь пару месяцев в году, а потом ждешь следующего сезона. Надо за год оценку брать.
В придачу к legacy коду часто достаются legacy разработчики, которые в упор не видят своих проблем, не хотят ничего менять, а банку червячков поддерживать становится все сложнее и бессмысленнее.
Компания на букве E сегодня сообщила, что позавчера ты уже не на проекте. А до этого всем предлага совершить прыжок веры без гарантий за свой счет.
Такой код даст такой же результат:
Подход может подойти для обработкчиков каких-нибудь, чтобы в них можно было хранить состояния на время выполнения обработки. Ну а вообще подход извращенный, гораздо проще через контекст доставать бины прототипа.
EPAM никого никуда не перевозил, до последнего не было точности, а был посыл переезжать за свой счёт, причем условия компенсации не озвучивались четко. Ещё говорили, что сроки на программу релокации сохраняются, многие вообще надеялись, что получится раньше релоцироваться, а по итогу, на сколько мне потом стало известно из чатов, все сроки обнулились, так как смена компании на компанию в другой стране. У меня оставалось 6 месяцев до поездки в штаты, но я не стал дёргаться, как выяснилось не зря.
Кажется можно без metric
management.endpoints.web.exposure.include=prometheus,health,infoПрошло почти 10 лет, idea таки сильно потеснила eclipse. Но теперь idea бесит тем, что за деньги получаешь баги, которые долго исправляются, после обновлений порой бывают тормоза. Периодически приходится перезапуска сбрасывая кеш. Использую очень активно на порядка 50 отдельных проектах (микросервисы).
Не исключено, что в будущем нас ждут общественные квадрокоптеры, которые будут летать по строгим траекториям. Возможно технически это реализовать ещё проще, чем беспилотные автомобили, ведь тут будут две площадки, между которыми он будет курсировать. Хотя отсутствие засилия служб доставок квадрокоптерами наталкивает на смысл, что не все так гладко в этой области.
Большая часть продуктов все равно на них, а опыт был получен в резальтате их использования.
Но ООП без сокрытия это сущий ад.
Но релиз-то еще только в конце 2019 и оно еще может быть перенесен. А пока повсеместно начнут использовать, так появится еще куча кода в старом стиле.
А вот тут мы идем как раз по типичной дорожке к запутанному коду. Magic методы вообще губительны как для проекта, так и для ООП. В этом случае предполагается, что вы знаете код, и как там работают эти магические методы. Об автокомплите тоже можно забыть, так как «Метод __set() будет выполнен при записи данных в недоступные свойства. », т.е. придется сначала убарть атрибут, чтобы заработал методы, а значит пропадет автокомплит. Ну и искать где он там меняется все же сложнее, чем искать вызовы метода.
Ну вы вспомнили. Даже 5 уже устарел. Меня смущает упоминание 4 версии. Если у вас старая школа, я вас не переубежу.
Так, тут вообще зарулили не туда, изначально суть была вообще в другом. ООП позволяет хорошо организовать, массивы позволяют хранить все те же переменные и методы, но без всякой структуры. Ограничение доступа — один из инструментов сохранения этой структуры.
Можно конечно поизвращаться:
Серьезно? Похоже, что еще только в проекте. Если разработчик не использует типы, то это уже на его совести.
Зато в том 1% случаев вы выиграете гораздо больше чем потеряете, если не будете рефакторить код по всему проекту переводя атрибут на метод, или разыскивая где-эже этот атрибут изменился.
PHP то вы зачем сюда приплели, у него с инструментами сокрытия все впорядке.
Что мешает запихать методы в массив.
Все с точность до наоборот, они позволяют в момент ограничить входные данные, повзволяют быть уверенным в том, что на входе именно то что ожидаешь, повзволяют расширять код в будущем (к слову о плохой архитектуре). Не раз приходилось сталкиваться с ситуацией, когда было крайне необходимо добавить дополнительную обработку в setter, отловить входной параметр при бебаге, или преобразовать данные при входе/выходе. KISS и YAGNI тут вообще не причем, генерация методов идет на уровне IDE и ничего не усложняет.
«Она может использоваться для сокрытия, а может не использоваться.» — только вот использовать её без сокрытия не имеет смысла, и в большинстве случаем их и не разделяют, а если решили разделить, то надо описывать это. В противном случае, привыкнув писать публичные атрибуты и взявшись за что-то более менее сложное, вы и итоге получите бесконечные неуверенности в том, что же у вас там в этом публичном атрибуте хранится.
В большинстве случае публичные атрибуты — зло, исключения составляют случаи когда речь идет о совсем простых классых типа
, да вот только в PHP нет типов и туда можно запихать хоть строку например которая вообще не приводится к числу. Методы ограничивают доступ к данным класса и позволяют фильтровать вход. А если будете писать в такой манере, делая публичными методы, то ваш код ничем не будет отличаться от использования массивов.
Если вы делаете публичные методы, то вы должны точно понимать зачем вы это делаете именно в данной ситуации, и давать себе отчет в том, что это может стать проблемой в будущем.
Encapsulation is one of the fundamentals of OOP (object-oriented programming). It refers to the bundling of data with the methods that operate on that data.[5] Encapsulation is used to hide the values or state of a structured data object inside a class, preventing unauthorized parties' direct access to them. Publicly accessible methods are generally provided in the class (so-called getters and setters) to access the values, and other client classes call these methods to retrieve and modify the values within the object.
en.wikipedia.org/wiki/Encapsulation_(computer_programming)
А как же доступ к атрибутам класса через методы этого класса.
А разве доктрина сама все не генерирует? И сущности и репозитории и базу? По крайней мере в Symfony это генерируется.
Что программируете? Почему не можете это сделать работой?
Есть особый вид бизнеса — ебизнес) Если бизнес приносит меньше чем 2.5*ЗП, тогда нет смысла, нервы, усталость и т.д.
В придачу к legacy коду часто достаются legacy разработчики, которые в упор не видят своих проблем, не хотят ничего менять, а банку червячков поддерживать становится все сложнее и бессмысленнее.