Conversation
| private String message; | ||
| private boolean isReceived = false; | ||
|
|
||
| public Message() { |
There was a problem hiding this comment.
зачем явно прописывать конструктор по умолчанию?
| wait(); | ||
| } catch (InterruptedException e) { | ||
| Thread.currentThread() | ||
| .interrupt(); |
| isReceived = true; | ||
|
|
||
| notifyAll(); | ||
| } |
There was a problem hiding this comment.
Размещать функциональность отправки и получения сообщения в самом Message - грубая ошибка. Завтра я захочу логику отправки-получения переделать через брокер сообщений или еще как-то - почему я при этом должен менять саму сущность "сообщение"?
There was a problem hiding this comment.
То есть текущий класс надо либо переименовать, либо выделить класс логики, который будет отвечать за обработку сообщения
There was a problem hiding this comment.
Но я бы просто вынес отправку и получение в логику отдельных сущностей - тогда любой потенциальный полиморфизм будет реализовать проще
|
|
||
| public class MessageReceiver implements Runnable { | ||
| private final Message message; | ||
| private final Consumer<String> stringConsumer; |
There was a problem hiding this comment.
Интересная идея. Но не всегда корректная на практике. В данном случае класс, создающий сущность получателя (или отправителя), должен знать, что будет происходить при отправке или получении. Чаще всего это не будет его ответственностью
| message.send(stringSupplier.get()); | ||
| } | ||
| } | ||
| } |
There was a problem hiding this comment.
Вердикт: технические решения местами интересные, с зонами ответственности классов перемудрил
| @Override | ||
| public void run() { | ||
| while (!Thread.currentThread() | ||
| .isInterrupted()) { |
| ; | ||
| } catch (InterruptedException e) { | ||
| Thread.currentThread() | ||
| .interrupt(); |
|
|
||
| logger.log("Остаток товаров на складе - %d".formatted(depot.getStock())); | ||
| } | ||
| } |
There was a problem hiding this comment.
Хорошая идея. Но Depot тут определенно лишний, из-за него слушатель получает сильно много ответственности. Как вариант - можно пост-эффект тоже передавать лямбдой, этой будет логичнее
Ну и с названием класса можно подумать, ибо сейчас оно не отражает суть. Но это не так страшно
| if ("finish".equalsIgnoreCase(stringSupplier.get())) { | ||
| break; | ||
| } | ||
| ; |
| Thread.sleep(Duration.ofSeconds(1)); | ||
|
|
||
| if ("finish".equalsIgnoreCase(stringSupplier.get())) { | ||
| break; |
There was a problem hiding this comment.
прохладная история, если есть флаг остановки
| int surplus = 0; | ||
|
|
||
| while (!Thread.currentThread() | ||
| .isInterrupted()) { |
| surplus = intSupplier.getAsInt(); | ||
| } | ||
|
|
||
| Thread.sleep(Duration.ofSeconds(random.nextInt(1, 4))); |
There was a problem hiding this comment.
не помню в условии требований к простою у покупателей или поставщиков
| } | ||
|
|
||
| logger.log("Остаток товаров - %d. %s пытается купить %d товаров.".formatted(stock, Thread.currentThread() | ||
| .getName(), count)); |
| } | ||
| } | ||
|
|
||
| logger.log("Остаток товаров - %d. %s пытается купить %d товаров.".formatted(stock, Thread.currentThread() |
There was a problem hiding this comment.
не логичнее в методы логгера докрутить varargs и дать возможность передавать параметры для форматирования? Чтобы не форматировать вручную в бизнес-коде
2 participants
No description provided.