|
Реализация метода BufferedInputStream.reset()
|
|||
---|---|---|---|
#18+
Метод reset(): Код: java 1. 2. 3. 4. 5. 6.
Метод getBufIfOpen() Код: java 1. 2. 3. 4. 5. 6.
Парочка вопросов: 1). Почему в методе getBufIfOpen() написано: Код: java 1. 2. 3.
а не просто: Код: java 1. 2.
2). В методе reset есть строчка кода Код: java 1.
т.е. метод, который должен возвращать массив, в данном методе ничего не возвращает (в других да). И получается, что метод выполняет две функции: возврат результата и проверка закрытия потока. А как же принцип "Single responsobility"? ... |
|||
:
Нравится:
Не нравится:
|
|||
18.04.2019, 01:36 |
|
Реализация метода BufferedInputStream.reset()
|
|||
---|---|---|---|
#18+
По первому вопросу: В классе есть метод fill(): Код: java 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34.
Тут buffer используется в Atomic-ах (метод compareAndSet), походу и в методе getBufIfOpen предполагалось, что то подобное или просто какая то заготовка на будущее. ... |
|||
:
Нравится:
Не нравится:
|
|||
18.04.2019, 09:35 |
|
Реализация метода BufferedInputStream.reset()
|
|||
---|---|---|---|
#18+
faustgreen 1). Почему в методе getBufIfOpen() написано: Потому что там дальше написано Код: sql 1.
Это никакая не заготовка а полностью корректный код. Метод разрабатывался так, чтобы он никогда не мог вернуть null. Даже в случае, если поток был закрыт асинхронно. Вот что вы собираетесь из метода возвращать, если проверяете buf на null? Какие гарантии, что до следующего чтения buf не изменился (он меняется методом close из другого потока)? Еще нужно учитывать, что synchronized вешать на все не очень хорошо. Ладно даже с точки зрения микропроизводительности (synchronized медленнее простого чтения/volatile), это можно пережить. А вот факт, что synchronized close() будет ожидать, пока операция чтения завершится (которая заблокировалась на нижележащем потоке) пережить сложно. С учетом требования атомарности и неблокирующиего close() это как раз прекрасный код. faustgreen 2). В методе reset есть строчка кода ... И получается, что метод выполняет две функции: возврат результата и проверка закрытия потока. А как же принцип "Single responsobility"? Издержки производства. Про атомарность из пункта 1 помните? Там реализуется функциональность "вернуть буффер открытого потока". На два метода тот код не разделяется. Создать же отдельный метод для проверки (или проверить по месту) конечно можно, но даст ли это существенную выгоду? С учетом того, что метод приватный и находится в системной библиотеке такое использование вполне приемлемо. Да и вообще, если считать "возврат результата" за responsibility, мы далеко не уйдем. Можно же так объявить все функции нарушающими SRP. Math.sin имеет две ответственности - вычисление синуса и возврат результата. ... |
|||
:
Нравится:
Не нравится:
|
|||
18.04.2019, 21:25 |
|
|
start [/forum/topic.php?fid=59&fpage=29&tid=2121357]: |
0ms |
get settings: |
9ms |
get forum list: |
12ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
73ms |
get topic data: |
13ms |
get forum data: |
3ms |
get page messages: |
46ms |
get tp. blocked users: |
1ms |
others: | 244ms |
total: | 409ms |
0 / 0 |