Deutsch
Germany.ruФорумы → Архив Досок→ Программирование

Одинаковые fully qualified type names - а ошибки нет?

778  1 2 все
Отпускник гость14.06.22 15:29
NEW 14.06.22 15:29 
в ответ Программист 14.06.22 10:29

зачем интерфейсы одни и те же, они про должны быть одни!

Ты программист вообще?))

#21 
Программист коренной житель14.06.22 20:52
NEW 14.06.22 20:52 
в ответ Отпускник 14.06.22 15:29, Последний раз изменено 14.06.22 20:53 (Программист)
зачем интерфейсы одни и те же

Чтобы не писать документацию 100 раз. Описал один раз контракты и дело в шляпе.


они про должны быть одни!

Несколько раз перечитал эту часть предложения, но так и не понял что ты хотел сказать.


Ты программист вообще?))

В отличие от тебя да.

#22 
MrSanders коренной житель15.06.22 10:56
NEW 15.06.22 10:56 
в ответ Программист 14.06.22 20:52, Последний раз изменено 15.06.22 10:56 (MrSanders)

Я так понимаю что претензия к копированию интерфейсов. Они должны быть написаны один раз. А все проекты использовать эти, определенные один раз, интерфейсы.

Мы же не копировали в каждый проект stdio.h чтобы его заинклюдить.

#23 
Программист коренной житель15.06.22 11:27
NEW 15.06.22 11:27 
в ответ MrSanders 15.06.22 10:56
Я так понимаю что претензия к копированию интерфейсов.

Но я нигде не писал про копирование интерфейсов :)

#24 
alex445 коренной житель15.06.22 13:54
NEW 15.06.22 13:54 
в ответ Программист 14.06.22 09:10, Последний раз изменено 15.06.22 13:56 (alex445)
Я привел тебе просто один пример для чего это может понадобиться.
По факту, даже у тоже же lg4net могут быть разные фичи для разных платформ, т.е. например интерфейсы все одинаковые, а конкрентны классы для каждой платформы разные.


Не знаю, например ты можешь сделать адаптер для взаимодействия с базами данных - MSSQL, SQLite, Oracle, MySQL при этом ты хочешь выпускать одну сборку, которая включает все необходимое. Таким образом интерфейсы будут везде одни и теже файлы с интерфейсами и разные реализации.

Как тогда может выглядеть структура проектов с пространствами имён? Например, так, как ниже? Т.е. разные проекты реализации, но с одинаковыми пространствами имён и, соответственно, полными квалификационными именами в классах, реализующих интерфейсы?


MyProject - the base name for the project (can also be a solution name)


project: MyProjectInterfaces

default namespace: MyProjectInterfaces


project: MyProjectImplementation1 - reference to MyProjectInterfaces

default namespace: MyProjectImplementation


project: MyProjectImplementation2 - reference to MyProjectInterfaces

default namespace: MyProjectImplementation

#25 
MrSanders коренной житель15.06.22 14:19
15.06.22 14:19 
в ответ Программист 15.06.22 11:27
Но я нигде не писал про копирование интерфейсов :)

А это разве не про копирование?

Хотя, я уверен, можно придумать структуру в которой каждый проект будет включать исходники (т.е. можно обойтись без ссылок)
#26 
alex445 коренной житель15.06.22 14:33
NEW 15.06.22 14:33 
в ответ MrSanders 15.06.22 14:19
Хотя, я уверен, можно придумать структуру в которой каждый проект будет включать исходники (т.е. можно обойтись без ссылок)

Это следующий вопрос, который я бы хотел задать, но он слегка из другой темы. Ну да ладно.


В каких случаях добавление файла с кодом (именно с кодом, а не какого-то ресурса, хотя и с ними тоже вопросы) как ссылки нужно вместо добавления ссылки на проект, в котором этот файл находится? Т.е. зачем придумывать какие-то дополнительные механизмы распределения файлов или кода, когда уже есть один хороший? Тем более, что добавление файла с кодом не отслеживается IDE как установление связи между проектами.

#27 
Отпускник гость15.06.22 15:16
NEW 15.06.22 15:16 
в ответ Программист 15.06.22 11:27
Но я нигде не писал про копирование интерфейсов

тогда чем обосновано желание создавать в разных проектах классы с идентичными идентификаторами?

#28 
Программист коренной житель15.06.22 16:24
NEW 15.06.22 16:24 
в ответ MrSanders 15.06.22 14:19
А это разве не про копирование?

Нет. ЕМНИП исходники будут скопированы, если они находятся где-то в параллельном каталоге с проектным файлом. Т.е. можно сложить все проектрые файлы в одну папку и тогда при включении существующих файлов они не будут скопированы. Это мое предположение, я это не проверял.

#29 
Программист коренной житель15.06.22 16:26
NEW 15.06.22 16:26 
в ответ Отпускник 15.06.22 15:16
тогда чем обосновано желание создавать в разных проектах классы с идентичными идентификаторами?

Я привел пример, когда это может иметь смысл.

А вообще, это был вопрос ТС.

#30 
Программист коренной житель15.06.22 16:31
NEW 15.06.22 16:31 
в ответ alex445 15.06.22 13:54

Как тогда может выглядеть структура проектов с пространствами имён?

Структура может быть такой:

.\SomeSolution
   +- SomeSolution.sln
   +- Implementation1.csproj
   +- Implementation2.csproj
   \Interfaces
     +- Interface1.cs
     +- Interface2.cs
   \Impl1
     +- SomeCode1a.cs
     +- SomeCode1b.cs
   \Impl2
     +- SomeCode2a.cs
     +- SomeCode2b.cs
#31 
Murr патриот15.06.22 17:44
Murr
NEW 15.06.22 17:44 
в ответ MrSanders 15.06.22 14:19

А это разве не про копирование?

-----

Не-а. Просто ознакомься с тем что включается в проект и как указываются файлы и библиотеки.

#32 
Murr патриот15.06.22 17:51
Murr
NEW 15.06.22 17:51 
в ответ Программист 15.06.22 16:24

все проектрые файлы в одну папку

-----

Пыхх...

Зачем так сложно?

Там вполне нормально используются относительные пути к фактическим файлам.


я это не проверял

-----

А Я - проверял.

К тому же там нет проблемы завести переменную для части пути к файлу и ее использовать.

Все детали - в MsBuild'e.

#33 
Murr патриот15.06.22 17:52
Murr
NEW 15.06.22 17:52 
в ответ Программист 15.06.22 16:31

Структура может быть такой

------

Не-а... еще проектик добавь...

#34 
MrSanders коренной житель16.06.22 09:21
NEW 16.06.22 09:21 
в ответ Murr 15.06.22 17:44
Не-а. Просто ознакомься с тем что включается в проект и как указываются файлы и библиотеки.

Не дождётесь. Никогда в жизни больше не буду что-то разрабатывать в продуктах мелкософта. Лучше опять на голых сях в емаксе писать. Развлекайтесь с этими дебилами сами :)

#35 
Murr патриот16.06.22 12:36
Murr
NEW 16.06.22 12:36 
в ответ MrSanders 16.06.22 09:21

не буду

------

Ну и зачем себя так сильно ограничивать?

#36 
alex445 коренной житель17.06.22 01:53
NEW 17.06.22 01:53 
в ответ Программист 15.06.22 16:31

Структура может быть такой:

.\SomeSolution
   +- SomeSolution.sln
   +- Implementation1.csproj
   +- Implementation2.csproj
   \Interfaces
     +- Interface1.cs
     +- Interface2.cs
   \Impl1
     +- SomeCode1a.cs
     +- SomeCode1b.cs
   \Impl2
     +- SomeCode2a.cs
     +- SomeCode2b.cs

Вы шарите интерфейсы между проектами в виде файлов, добавленных как ссылки? А зачем? Можно же вынести их в отдельный проект, чтобы подключать потом к проектам имплементаций

#37 
alex445 коренной житель17.06.22 11:38
NEW 17.06.22 11:38 
в ответ Murr 15.06.22 17:51, Последний раз изменено 17.06.22 11:41 (alex445)
Там вполне нормально используются относительные пути к фактическим файлам.
Там вполне нормально используются относительные пути к фактическим файлам.

Главный вопрос не в том, "можно?" или "не можно?", а "нахрена?". Вот в моём нынешнем проекте наворотили циклических зависимостей между проектами через ссылки на проекты и ссылки на файлы, так что теперь при переписывании хрен проверишь через компиляцию, правильно ли сделал, пока не напишешь весь цикл зависимостей. Или придётся отключать часть кода, чтобы скомпилилось. А юнит-тестов ваших благословенных нет.


Я понимаю, что нужно в проекте о себе оставить "память", мину замедленного действия, так сказать. Когда делаешь проект лет 5, да ещё с такими "наворотами", то становишься незаменимым. Потом другая команда хрен что перепишет без тебя. Сдал проект, получил гонорар. А потом сидишь и ждёшь, когда тебя позовут на сдельную работу за пятерную оплату - мины свои подчищать. Так семь знаков и зарабатываются. ))


Может, Мурр нам просто подсказывает, как тоже богатыми стать? А то сидят дурачки молодые и средние, пытаются всё по фен-шуям сделать. И не ведают, идиоты, своего счастья в маленьких, но заковыристых закладках, которые их потом ещё несколько лет кормить будут.

#38 
1 2 все