Статические (общие в VB.NET) или обычные методы

Question

Статические (общие в VB.NET) или обычные методы

2

Я хочу знать, какой из них предпочтительнее при кодировании для использования статических методов или обычных экземпляров, я предпочитаю использовать статические, если их мало, но если их было много, я начинаю сомневаться

Пример

EmployeeCollection EmpLst = EmployeeManager.GetAllEmployees();

или

EmployeeManager EmpMgr = new EmployeeManager();
EmployeeCollection EmpLst = EmpMgr.GetAllEmployees();

если у EmployeeManager есть много методов (выбирает удаление обновлений), нормально ли сделать их статичными.

и если это был обычный экземпляр. не будет недостатком, если объект инициируется каждый раз специально, если GetAllEmployees() используется в значительной степени.

Какой лучший подход к использованию?

Kronass 27 окт. 2009, в 12:06

Источник

0

Проверьте эти темы: stackoverflow.com/questions/596367/… , stackoverflow.com/questions/202631/…
Groo 27 окт. 2009, в 10:53

Теги:

c#

asp.net

.net

vb.net

3 ответа

1

Возможно, вы захотите взглянуть на шаблоны factory и singleton, которые являются образцами творчества, задуманными для такого рода вещей. Для вашей проблемы я бы предложил использовать singleton, который обеспечивает однократное создание объекта.

Аннотация Factory

Singleton

(Ссылки на dofactory.com)

Dominiek 27 окт. 2009, в 08:24

1

ИМХО, синглтоны сильно переоценены ...
Maximilian Mayerl 27 окт. 2009, в 10:57
0

Хотите уточнить это?
Dominiek 27 окт. 2009, в 10:59
0

Ну, а в чем преимущество синглтона? Да, вы можете создать синглтон поверх производного класса, но это все, не правда ли? Единственное другое различие между одноэлементным и статическим классом состоит в том, что у вас есть накладные расходы на доступ к свойству Instance для синглетонов.
Maximilian Mayerl 27 окт. 2009, в 11:01
0

Договорились, но это может помочь, когда количество экземпляров должно быть ограничено. Например, когда вам нужно всего 5 экземпляров класса и вы хотите балансировать запросы между ними. Тем не менее, я также считаю, что класс со статическими членами эквивалентен в этом случае.
Dominiek 27 окт. 2009, в 11:06
1

Статические классы не могут быть полиморфными. Нет наследования, реализации интерфейса или тому подобное. Одноэлементный подход позволяет вам иметь лучшее из обоих миров.
Adrian Zanescu 27 окт. 2009, в 14:13

Показать ещё 3 комментария

0

В случае вашего метода GetEmployee я придерживаюсь статичности.

Обычно я использую static, если для этого метода не требуется доступ к каким-либо состояниям экземпляра и методам экземпляров, если это необходимо. Таким образом, я не использую методы экземпляра, если для метода не требуется состояние экземпляра.

Maximilian Mayerl 27 окт. 2009, в 09:09

Ещё вопросы

Проверьте эти темы: stackoverflow.com/questions/596367/… , stackoverflow.com/questions/202631/…
ИМХО, синглтоны сильно переоценены ...
Ну, а в чем преимущество синглтона? Да, вы можете создать синглтон поверх производного класса, но это все, не правда ли? Единственное другое различие между одноэлементным и статическим классом состоит в том, что у вас есть накладные расходы на доступ к свойству Instance для синглетонов.
Договорились, но это может помочь, когда количество экземпляров должно быть ограничено. Например, когда вам нужно всего 5 экземпляров класса и вы хотите балансировать запросы между ними. Тем не менее, я также считаю, что класс со статическими членами эквивалентен в этом случае.
Статические классы не могут быть полиморфными. Нет наследования, реализации интерфейса или тому подобное. Одноэлементный подход позволяет вам иметь лучшее из обоих миров.

Vitaliy Liptchinsky · Accepted Answer · 2009-10-27T09-46-00.000Z

Если у вас много статических методов, я предполагаю, что вы не следуете принципам ООП. Статические методы полезны как методы factory или как вспомогательные методы. Но я бы избегал строить дизайн приложений поверх них.

но в приложении ASP.NET объект удаляется каждый раз, когда запрос завершается и отправляется. поэтому мне нужно инициировать объект каждый раз, когда я хочу вызвать метод, не будет ли это недостатком?
Прежде всего, вы должны заботиться о дизайне, а не о производительности. После того, как вы хорошо спроектировали, вы можете проверить, является ли производительность приемлемой, а если нет - только тогда вы можете начать рассматривать статические методы или любые другие подходы.
Большое спасибо, что было очень полезно