Принцип инверсии зависимостей на практике

[SergeyUsok]

Поскольку одной записе LogEntry может соответствовать

• записИ

Класс нарушает ISP. Самой простой зависимостью класса LogEntryParser является строка ( System.String ), и именно ее должен принимать метод Parse , в качестве аргумента метода

• не понял, где здесь нарушение ISP, нужно дополнительное разъяснение.
• после Parse запятая не нужна

Класс LogEntryParser использует IFileReader , которую нельзя назвать

пропустил слово "зависимость"

"абстрагироваться" от ввода/выводы

выводА

Если он, по какой-то причине не подходит, то вместо интерфейса IFileReader , нужно выделять интерфейс IRawLogEntryStream

Немного странно, что нам не подходит Stream, но подходит IRawLogEntryStream, пусть это и самописный интерфейс. Кроме того, название Stream уже сразу говорит нам о том, откуда данные, то есть это фактически теже проблемы, что и с названием IFileReader. Может сделать интерфейс IRawLogEntryReader или IRawLogEntryProvider или просто IReader?

Повдеение класса LogEntryParser не точно отражало его название

Поведение

Листинг 6.5 - Фабричный метод LogEntryReader.FromFile

зачем мы провайдим парсеру имя файла, если у нас уже есть файл ридер?

использование класса большинством клиентами

клиентОВ

содержать лишь код, приведенный в листинге 6.7

здесь наверное имелся в виду листинг 6.6

Разделение обязанностей между классами LogImporter , LogSaver и LogEntryReader , уже достаточно для успешной эволюции приложения.

разделениЯ

[SergeyTeplyakov]

Немного странно, что нам не подходит Stream, но подходит IRawLogEntryStream, пусть это и самописный интерфейс. Кроме того, название Stream уже сразу говорит нам о том, откуда данные, то есть это фактически теже проблемы, что и с названием IFileReader. Может сделать интерфейс IRawLogEntryReader или IRawLogEntryProvider или просто IReader?

Ну, нам не подходит встроенный стрим, но мы хотим использовать интерфейс. Тогда создаем свой, но называем его так, чтобы в его имени не было реализации.

IStream - это более абстрактное понятие, по сравнению с IFile, поскольку первый говорит о любом потоке ввода/вывода, включая файлы, а второй - лишь о файлах. При этом я не хочу вводить еще один ридер. Если я бы абстрагировался самостоятельно от источника. то вводил бы именно специализированный стрим, заточенный под мои конкретные нужды, а уже ридер его бы использвал. Аналогично тому, как это сделано в потоках ввода/вывода в .NET - стримы - отдельно, ридеры/райтеры - отдельно.

[SergeyTeplyakov]

зачем мы провайдим парсеру имя файла, если у нас уже есть файл ридер?

Там я даю ссылку, что класс LogEntryParser.Create был рассмотрен в предыдущей главе. Там используется имя файла, чтобы понять, какой конкретно парсер используется.

[SergeyTeplyakov]

содержать лишь код, приведенный в листинге 6.7

Там же полная фраза такая: Если класс LogImporter будет содержать лишь код, приведенный в листинге 6.7 И речь в ней идет о реализации класса LogImpoerter который рассмотрен именно в листинге 6.7.