Я хочу создать псевдоним для имени класса. Следующий синтаксис был бы идеальным:
public class LongClassNameOrOneThatContainsVersionsOrDomainSpecificName
{
...
}
public class MyName = LongClassNameOrOneThatContainsVersionOrDomainSpecificName;
но он не компилируется.
пример
Примечание. Этот пример предоставлен только для удобства. Не пытайтесь решить эту конкретную проблему, предлагая изменить конструкцию всей системы. Наличие или отсутствие этого примера не меняет исходный вопрос.
Некоторый существующий код зависит от наличия статического класса:
public static class ColorScheme
{
...
}
Эта цветовая схема является цветовой схемой Outlook 2003. Я хочу представить цветовую схему Outlook 2007, сохранив цветовую схему Outlook 2003:
public static class Outlook2003ColorScheme
{
...
}
public static class Outlook2007ColorScheme
{
...
}
Но я все еще сталкиваюсь с тем, что код зависит от наличия вызываемого статического класса ColorScheme
. Моя первая мысль была создать ColorScheme
класс , который я буду наследовать либо Outlook2003
или Outlook2007
:
public static class ColorScheme : Outlook2007ColorScheme
{
}
но вы не можете наследовать от статического класса.
Следующей моей мыслью было создать статический ColorScheme
класс, но классы make Outlook2003ColorScheme
и Outlook2007ColorScheme
не статические. Тогда статическая переменная в статическом ColorScheme
классе может указывать на любую «истинную» цветовую схему:
public static class ColorScheme
{
private static CustomColorScheme = new Outlook2007ColorScheme();
...
}
private class CustomColorScheme
{
...
}
private class Outlook2008ColorScheme : CustomColorScheme
{
...
}
private class Outlook2003ColorScheme : CustomColorScheme
{
...
}
но для этого мне потребовалось бы преобразовать класс, состоящий только из статических цветов, доступных только для чтения, в переопределяемые свойства, и тогда моему ColorScheme
классу потребовалось бы, чтобы 30 различных методов получения свойств были перенесены в содержащийся объект.
Это слишком много для набора текста.
Следующей моей мыслью было присвоить классу псевдоним:
public static ColorScheme = Outlook2007ColorScheme;
Но это не компилируется.
Как я могу присвоить статическому классу другое имя?
Обновление: может кто-нибудь добавить ответ «Вы не можете сделать это на C #» , чтобы я мог отметить это как принятый ответ. Любой другой, желающий получить ответ на тот же вопрос, найдет этот вопрос, принятый ответ и ряд обходных путей, которые могут оказаться полезными, а могут и не оказаться.
Я просто хочу закрыть этот вопрос.
источник
interface
, который реализуют все ваши классы. Как упоминалось в ответе chills42 . Затем вы можете определить «службу» или «фабрику», которая возвращает объект, реализующий этот интерфейс, в зависимости от текущих обстоятельств (например, платформы / ОС) или от конфигурационного файла.Ответы:
Вы не можете . Следующее, что вы можете сделать, это иметь
using
объявления в файлах, которые используют этот класс.Например, вы можете переписать зависимый код, используя псевдоним импорта (в качестве квазизамещения
typedef
):using ColorScheme = The.Fully.Qualified.Namespace.Outlook2007ColorScheme;
К сожалению, это необходимо для каждой области / файла, использующего это имя.
Поэтому я не знаю, практично ли это в вашем случае.
источник
using
должно быть добавлено ко всему сломанному коду. И это также отрицает значение наличия единственного псевдонима, что позволяет мне переключить всех пользователей существующегоColorScheme
класса на использование нового класса - без изменений. Другими словами: я хочу присвоитьColorScheme
класс другому классу.Вы можете создать псевдоним для своего класса, добавив эту строку кода:
using Outlook2007ColorScheme = YourNameSpace.ColorScheme;
источник
Imports
. Я ошибся?using
директиву в его пространство имен, например, когда вам нужен псевдоним вашего собственного класса.Вам нужен ( Factory | Singleton ), в зависимости от ваших требований. Предпосылка состоит в том, чтобы сделать так, чтобы клиентский код не знал, какую цветовую схему он получает. Если цветовая схема должна подходить для всего приложения, подойдет синглтон. Если вы можете использовать другую схему в различных обстоятельствах, вероятно, вам подойдет шаблон Factory. В любом случае, когда необходимо изменить цветовую схему, нужно изменить код только в одном месте.
public interface ColorScheme { Color TitleBar { get; } Color Background{ get; } ... } public static class ColorSchemeFactory { private static ColorScheme scheme = new Outlook2007ColorScheme(); public static ColorScheme GetColorScheme() { //Add applicable arguments return scheme; } } public class Outlook2003ColorScheme: ColorScheme { public Color TitleBar { get { return Color.LightBlue; } } public Color Background { get { return Color.Gray; } } } public class Outlook2007ColorScheme: ColorScheme { public Color TitleBar { get { return Color.Blue; } } public Color Background { get { return Color.White; } } }
источник
Вы не можете использовать псевдоним класса в C #.
Есть вещи, которые можно сделать, не применяя псевдонима к имени класса в C #.
Но чтобы ответить на исходный вопрос: вы не можете использовать псевдоним имени класса в C #.
Обновление: люди не понимают, почему
using
не работает. Пример:Form1.cs
private void button1_Click(object sender, EventArgs e) { this.BackColor = ColorScheme.ApplyColorScheme(this.BackColor); }
ColorScheme.cs
class ColorScheme { public static Color ApplyColorScheme(Color c) { ... } }
И все работает. Теперь я хочу создать новый класс и псевдоним
ColorScheme
для него (чтобы не изменять код ):ColorScheme.cs
using ColorScheme = Outlook2007ColorScheme; class Outlook2007ColorScheme { public static Color ApplyColorScheme(Color c) { ... } }
Ох, извини. Этот код не компилируется:
Мой вопрос заключался в том, как создать псевдоним класса в C #. Это невозможно. Есть вещи, которые я могу сделать, не используя псевдонима имени класса в C #:
ColorScheme
кusing
ColorScheme
вместо (обходного пути изменения коды , потому что я не могу псевдоним)ColorScheme
использования фабричного шаблона, на полиморфный класс или интерфейс (обходной путь изменения кода, потому что я не могу использовать псевдоним)Но эти обходные пути включают нарушение существующего кода: не вариант.
Если люди зависят от наличия
ColorScheme
класса, мне нужно скопировать / вставитьColorScheme
класс.Другими словами: я не могу использовать псевдоним имени класса в C #.
Это контрастирует с другими объектно-ориентированными языками, где я мог определить псевдоним:
и я бы сделал.
источник
попробуй это:
using ColorScheme=[fully qualified].Outlook2007ColorScheme
источник
Я добавляю этот комментарий для пользователей, обнаруживших это спустя много времени после того, как OP принял их «ответ». Псевдонимы в C # работают путем указания имени класса с использованием его полностью определенного пространства имен. Одно определенное имя псевдонима может использоваться в его области. Пример.
using aliasClass = Fully.Qualified.Namespace.Example; //Example being the class in the Fully.Qualified.Namespace public class Test{ public void Test_Function(){ aliasClass.DoStuff(); //aliasClass here representing the Example class thus aliasing //aliasClass will be in scope for all code in my Test.cs file } }
Приносим извинения за быстро набираемый код, но, надеюсь, он объясняет, как это должно быть реализовано, чтобы пользователи не вводили в заблуждение, полагая, что это невозможно сделать на C #.
источник
namespace Fully.Qualified.Namespace{
public class Example {
...public void DoStuff(){
...}
...}
}
.Псевдонимы, которые вы хотели бы сделать, не будут работать в C #. Это связано с тем, что сглаживание выполняется с помощью
using
директивы, которая ограничена рассматриваемым файлом / пространством имен. Если у вас есть 50 файлов, которые используют старое имя класса, это означает, что нужно обновить 50 мест.Тем не менее, я думаю, что есть простое решение, позволяющее минимизировать изменения кода. Сделайте
ColorScheme
класс фасадом для ваших вызовов фактических классов с реализацией и используйтеusing
в этом файле, чтобы определить, чтоColorScheme
вы используете.Другими словами, сделайте так:
using CurrentColorScheme = Outlook2007ColorScheme; public static class ColorScheme { public static Color ApplyColorScheme(Color c) { return CurrentColorScheme.ApplyColorScheme(c); } public static Something DoSomethingElse(Param a, Param b) { return CurrentColorScheme.DoSomethingElse(a, b); } }
Затем в вашем коде ничего не меняйте:
private void button1_Click(object sender, EventArgs e) { this.BackColor = ColorScheme.ApplyColorScheme(this.BackColor); }
Затем вы можете обновить значения
ColorScheme
, обновив одну строку кода (using CurrentColorScheme = Outlook2008ColorScheme;
).Здесь есть пара проблем:
ColorScheme
класс и вOutlook2007ColorScheme
класс. Это дополнительная работа, но если это действительно устаревший код, это не должно происходить часто. В качестве бонуса кодColorScheme
настолько прост, что любая возможная ошибка очень очевидна.ColorScheme
класс, который вы заменяете, этот и любой другой подход могут стать проблемой. Я бы посоветовал вам переименовать этот класс во что-то вродеColorSchemeOld
, а затем получить к нему доступusing CurrentColorScheme = ColorSchemeOld;
.источник
Я полагаю, вы всегда можете наследовать от базового класса, ничего не добавляя
public class Child : MyReallyReallyLongNamedClass {}
ОБНОВИТЬ
Но если у вас есть возможность рефакторинга самого
class
себя: имя класса обычно излишне длинное из-за отсутствияnamespace
s.Если вы видите случаи , как
ApiLoginUser
,DataBaseUser
,WebPortalLoginUser
, как правило , указывает на отсутствиеnamespace
из - за страха , что имяUser
может вступить в конфликт.Однако в этом случае вы можете использовать
namespace
псевдоним , как было указано в сообщениях выше.using LoginApi = MyCompany.Api.Login; using AuthDB = MyCompany.DataBase.Auth; using ViewModels = MyCompany.BananasPortal.Models; // ... AuthDB.User dbUser; using ( var ctxt = new AuthDB.AuthContext() ) { dbUser = ctxt.Users.Find(userId); } var apiUser = new LoginApi.Models.User { Username = dbUser.EmailAddess, Password = "*****" }; LoginApi.UserSession apiUserSession = await LoginApi.Login(apiUser); var vm = new ViewModels.User(apiUserSession.User.Details); return View(vm);
Обратите внимание, как все
class
именаUser
, но в разныхnamespace
s. Цитата PEP-20: Zen of Python :Надеюсь это поможет
источник
new
ключевому слову для таких методов или даже придумать свои собственные ExtensionMethods, верно? В любом случае я твердо убежден в том, что вы всегда должны использовать классы vanilla Collection (например, Dictionary, List, IEnumerable, IQueryable и т. Д.) С пользовательскими моделями Models / ViewModels / POCO. Как заявляет Mvc: СоглашениеIColorScheme oColorScheme = ColorSchemeFactory.Create();
Кроме того, вы можете изучить « Внедрение зависимостей»Можно ли перейти на использование интерфейса?
Возможно, вы могли бы создать
IColorScheme
интерфейс, который реализуют все классы?Это будет хорошо работать с заводским шаблоном, как показано Крисом Марасти-Георгом.
источник
Это очень поздний частичный ответ, но если вы определяете один и тот же класс ColorScheme в том же пространстве имен Outlook, но в отдельных сборках, одна называется Outlook2003, а другая Outlook2007, тогда все, что вам нужно сделать, это ссылаться на соответствующую сборку .
источник