Conversation
…ых, но и .docx, с возможностью для расширения в будущем для новых расширений
…topwords и картинка.
TagCloud.Core/DI/TagCloudModule.cs
Outdated
| { | ||
| var center = new Point(0, 0); | ||
|
|
||
| // ---------- Spiral & Layouter ---------- |
There was a problem hiding this comment.
Если очень хотелось описать что ты регаешь, то не практичней ли использовать методы? И по их названиям определять что ты регаешь внутри.
Сами комменты очень странные. Походят на нейронку.
There was a problem hiding this comment.
Прогнал код, чтобы выровнять отступы и убрать лишние пробелы. Комментарии забыл почистить)
Ну там не только с отступами cleanup
Знаю что можно через шорткат в райдере
| @@ -0,0 +1,13 @@ | |||
| namespace TagCloud.Abstractions.Generic; | |||
|
|
|||
| public abstract class TxtFileProviderBase<T>(string filePath) | |||
There was a problem hiding this comment.
Изначально логика была сложнее и повторялась. Сел рефакторить, дошел до дженериков, потом оказалось что они не нужны.
| @@ -0,0 +1,11 @@ | |||
| using TagCloud.Abstractions; | |||
There was a problem hiding this comment.
Почисти using-и. В Райдере есть под это шорткаты
|
|
||
| namespace TagCloud.Implementations; | ||
|
|
||
| using System.IO; |
There was a problem hiding this comment.
Странный using как будто откуда то скопипастил конкретный кусок кода
|
|
||
| // ---------- Words Source Providers ---------- | ||
| builder.RegisterAssemblyTypes(typeof(TxtWordsSourceProvider).Assembly) | ||
| .AssignableTo<IWordsProvider<IWordsSource>>() |
There was a problem hiding this comment.
Мне кажется ты сильно намудрил с наследованиями и абстракциями. Всю эту мешанину читать анриал.
В чём разница, например IWordsSource и IStopWordsProvider?
Зачем это усложнение в IWordsProvider, который создаёт класс, который уже читает файл?
Зачем завязывать контейнер на какие-то входные параметры и уже от них строить контейнер? Это всё только усложняет код. Нет смысла в красивых абстракциях и расширяемости если поддерживать код нереально. Всегда лучше упрощать.
Попытайся прийти к более простой и читаемой картине. Нужно получить слова - есть один ответственный, который внутри себя уже усложняет логику, умея доставать данные из разных источников и тд.
Ну и зависимость контейнера от внешних переменных кажется плохой. Мне получается нужно его каждый раз заново собирать под разные форматы файлов - это странно. Зависимость может быть от чего-то фундаментального - от окружения, но уж никак не от сценария приложения.
|
|
||
| namespace TagCloud.DI; | ||
|
|
||
| public class TagCloudModule(string wordsFile, string stopWordsFile) : Module |
There was a problem hiding this comment.
и всё таки, зачем контейнеру знать входные данные программы? Как, например, мне использовать этот контейнер в WPF приложении? Сценарий:
- Выбираю путь до основного файла в инпуте,
- Выбираю путь до стоп-слов файла в инпуте
- Жму кнопку "отрисовать".
- Каждый раз пересобираю контейнер в бизнес-коде, чтобы подстроиться под новые
filePath-ы. Не кажется это странным? Или ты будешь сетить эти вещи в качестве каких-то переменных контейнера и разруливать это в контейнере?(что тоже кажется кринжовым)
There was a problem hiding this comment.
Понял, сделал фигню
Правильно понял, что пути нужно передавать в методах а не в конструкторе и тогда регистрация зависимостей будет гибкая и не нужно будет в TagCloudModule передавать пути?
Ну а т.к. путь к файлам может всегда быть разным - то моя логика неверная, если были бы глобальные переменные то еще ок наверно
There was a problem hiding this comment.
Ну тебе просто не нужно было завязываться на такой входной параметр. Можно представить как, например, твой код работал бы в приложении WPF. Я запускаю приложение, выбираю файл в выпадашке - ты, чтобы обработать его, польностью пересобираешь DI. При чём не только для 1 файла, но и стоп слова. Это ненужная работа. DI это про то, чтобы собрать его на старте приложения и забыть. Дальше просто дёргать из него что нужно
2 participants
@FnaTikJK