Різниця між статичним класом і однотонним малюнком?

Яка реальна (тобто практична) різниця існує між статичним класом і однотонним малюнком?

Обидва можна викликати без ініціативи, обидва надають лише один "екземпляр", і жоден з них не є безпечним для потоків. Чи є якась інша різниця?

Що змушує вас сказати, що ні однотонний, ні статичний метод не є безпечними для потоків? Зазвичай і те, і інше повинно бути безпечним для потоків.

Велика різниця між одиночним і купою статичних методів полягає в тому, що одиночні кнопки можуть реалізовувати інтерфейси (або виходити з корисних базових класів, хоча, на мій досвід, це рідше), тож ви можете пройти навколо сингтона так, ніби це "просто інший "реалізація.

Справжня відповідь - Джон Скіт, на іншому форумі тут .

Синглтон дозволяє отримати доступ до одного створеного екземпляра - цей екземпляр (точніше, посилання на цей екземпляр) може бути переданий як параметр іншим методам і трактуватися як звичайний об'єкт.

Статичний клас дозволяє лише статичні методи.

1. Об'єкти Singleton зберігаються в Heap , але статичні об'єкти зберігаються в стеці .
2. Ми можемо клонувати (якщо дизайнер не заборонив це) однотонний об'єкт, але ми не можемо клонувати об’єкт статичного класу.
3. Однокласні класи дотримуються ООП (об'єктно-орієнтовані принципи), статичні класи - ні.
4. Ми можемо реалізувати interfaceкласу Singleton, але статичні методи класу (або, наприклад, C # static class) не можуть.

Шаблон Singleton має ряд переваг перед статичними класами. По-перше, синглтон може розширювати класи та реалізовувати інтерфейси, а статичний клас не може (він може розширювати класи, але не успадковує їх членів екземпляра). Однотонна може бути ініціалізована ліниво або асинхронно, тоді як статичний клас, як правило, ініціалізується під час першого завантаження, що призводить до потенційних проблем завантажувача класів. Однак найважливішою перевагою є те, що з однотонними можна обробляти поліморфно, не змушуючи їх користувачів вважати, що існує лише один екземпляр.

staticзаняття не для нічого, що потрібно державі. Це корисно для поєднання купу функцій, тобто Math(або Utilsв проектах). Тож назва класу просто дає нам підказку, де ми можемо знайти функції та більше нічого.

Singletonє моєю улюбленою схемою, і я використовую її для управління чимось в одній точці. Це більш гнучко, ніж staticзаняття, і може підтримувати стан. Він може реалізовувати інтерфейси, успадковувати від інших класів і допускати спадкування.

Моє правило вибору між staticта singleton:

Якщо є купа функцій, які слід зберігати разом, то staticвибір. Все інше , що потрібно єдиний доступ до деяких ресурсів, можуть бути реалізовані у вигляді singleton.

Статичний клас: -

1. Ви не можете створити екземпляр статичного класу.

2. Автоматично завантажується програмою загальної мови .NET Framework (CLR), коли завантажується програма або область імен, що містять клас.

3. Статичний клас не може мати конструктор.

4. Ми не можемо передати статичний клас методу.

5. Ми не можемо успадкувати статичний клас до іншого статичного класу в C #.

6. Клас, що має всі статичні методи.

7. Більш висока продуктивність (статичні методи зв’язуються на час компіляції)

Синглтон: -

1. Ви можете створити один екземпляр об'єкта і повторно використовувати його.

2. Екземпляр Singleton створюється вперше, коли користувач запитував.

3. Сингл-клас може мати конструктор.

4. Ви можете створити об'єкт однокласного класу і передати його методу.

5. Клас одиночки не говорить про обмеження спадкування.

6. Ми можемо розміщувати об'єкти однотонного класу, але не статичного класу.

7. Методи можуть бути відмінені.

8. Можна ліниво завантажуватись при потребі (статичні класи завжди завантажуються).

9. Ми можемо реалізувати інтерфейс (статичний клас не може реалізувати інтерфейс).

Статичний клас - це той, який має лише статичні методи, для яких кращим словом були б "функції". Стиль дизайну, втілений у статичному класі, суто процедурний.

Синглтон, з іншого боку, є візерунком, характерним для дизайну ОО. Це екземпляр об'єкта (з усіма притаманними йому можливостями, наприклад, поліморфізм), з процедурою створення, яка забезпечує існування лише одного екземпляра цієї конкретної ролі протягом усього його життя.

У одиночному шаблоні ви можете створити синглтон як екземпляр похідного типу, ви не можете зробити це зі статичним класом.

Короткий приклад:

if( useD3D )
    IRenderer::instance = new D3DRenderer
else
    IRenderer::instance = new OpenGLRenderer

Щоб розширити відповідь Джона Скіта

Велика різниця між однотонним і купою статичних методів полягає в тому, що одиночні кнопки можуть реалізовувати інтерфейси (або виходити з корисних базових класів, хоча це менш поширений IME), тож ви можете пройти навколо сингтона так, ніби це "лише інша" реалізація.

З одиночними кнопками простіше працювати при тестуванні одиниці класу. Де б ви не передавали одиночні параметри в якості параметра (конструктори, сетери або методи), ви можете замінити заміщену або стерту версію синглтона.

Ось хороша стаття: http://javarevisited.blogspot.com.au/2013/03/difference-between-singleton-pattern-vs-static-class-java.html

Статичні класи

• клас, що має всі статичні методи .
• краща продуктивність (статичні методи залежать від часу компіляції)

• не може змінити методи, але може використовувати метод приховування. ( Який метод ховається в Java? Навіть пояснення JavaDoc є заплутаним )

  public class Animal {
      public static void foo() {
          System.out.println("Animal");
      }
  }
  
  public class Cat extends Animal {
      public static void foo() {  // hides Animal.foo()
          System.out.println("Cat");
      }
  }
  

Сінглтон

• об'єкт , який може бути реалізований тільки один раз.
• методи можуть бути замінені ( Чому Java не дозволяє переосмислити статичні методи? )
• легше глузувати, ніж статичні методи
• краще підтримувати державу

Підсумовуючи, я б використовував лише статичні класи для проведення утилічних методів, а для Singleton - використання всього іншого.

Правки

• статичні класи також ліниво завантажуються. Дякую @jmoreno ( Коли відбувається ініціалізація статичного класу? )

• метод приховування для статичних класів. Дякуємо @MaxPeng

Ще однією перевагою синглтона є те, що він може легко серіалізуватися, що може знадобитися, якщо вам потрібно зберегти його стан на диску або відправити його кудись віддалено.

Я не великий теоретик ОО, але, наскільки я знаю, я думаю, що єдиною особливістю ОО, якої не вистачає статичних класів порівняно з Синглтонсом, є поліморфізм. Але якщо він вам не потрібен, зі статичним класом ви, звичайно, можете мати спадщину (не впевнений у реалізації інтерфейсу) та інкапсуляцію даних та функцій.

Коментар Моренділа: "Стиль дизайну, втілений у статичному класі, є суто процедурним". Можливо, я помиляюся, але я не згоден. У статичних методах ви можете отримати доступ до статичних членів, що було б точно так само, як одиночні методи, що мають доступ до членів їхнього єдиного примірника.

редагувати:
Насправді я зараз думаю, що інша різниця полягає в тому, що статичний клас інстанціюється при запуску програми * і живе протягом усього періоду життя програми, тоді як сингтон явно інстанціюється в якийсь момент і може бути також знищений.

* або це може бути примірник при першому використанні, я думаю, залежно від мови.

Щоб проілюструвати точку Джона, що показано нижче, неможливо зробити, якщо Logger був статичним класом. Клас SomeClassочікує, що екземпляр ILoggerреалізації буде переданий в його конструктор.

Клас синглтон важливий для можливого введення залежності.

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;

namespace ConsoleApplication2
{
    class Program
    {
        static void Main(string[] args)
        {

            var someClass = new SomeClass(Logger.GetLogger());
        }


    }

    public class SomeClass 
    {
        public SomeClass(ILogger MyLogger)
        {

        }
    }

    public class Logger : ILogger
    {
        private static Logger _logger;
        private Logger() { }

        public static Logger GetLogger()
        {
            if (_logger==null)
            {
                _logger = new Logger();
            }

            return _logger;
        }

        public void Log()
        {

        }

    }


    public interface ILogger
    {
         void Log();
    }
}

Ну синглтон - це просто звичайний клас, який ІСНІСТЬ, але лише один раз і опосередковано з клієнтського коду. Статичний клас не є примірником. Наскільки мені відомо, статичні методи (статичний клас повинен мати статичні методи) швидші, ніж нестатичні.

Редагувати:
Опис правила продуктивності FxCop: "Методи, які не отримують доступ до даних екземпляра або методи екземпляра виклику, можуть бути позначені як статичні (Спільне в VB). Після цього компілятор передасть цим членам невіртуальні сайти викликів, що запобіжить перевіряйте під час виконання кожного виклику, який гарантує, що поточний вказівник об'єкта є недійсним. Це може призвести до вимірювання посилення продуктивності для коду, що залежить від продуктивності. У деяких випадках недоступ до поточного екземпляра об'єкта представляє проблему правильності. "
Я насправді не знаю, чи це стосується також статичних методів у статичних класах.

Сінглтон є екземпляром, це просто один примірник, коли-небудь інстанційований, отже, сингл у Сінглтоні.

Статичний клас не може бути примірник іншим, окрім себе.

Основні відмінності:

• У Singleton є екземпляр / об'єкт, а статичний клас - це купа статичних методів
• Singleton можна розширити, наприклад, через інтерфейс, тоді як статичний клас не може бути.
• Singleton може бути успадкований, що підтримує принципи відкриття / закриття в принципах SOLID, з іншого боку статичний клас не може бути успадкований, і нам потрібно внести зміни в себе.
• Об'єкт Singleton може передаватися методам, тоді як статичний клас, оскільки він не має примірника, не може бути переданий як параметри

Синглтон краще підходити з точки зору тестування. На відміну від статичних класів, одиночний може реалізувати інтерфейси, і ви можете використовувати екземпляр макету та вводити їх.

У наведеному нижче прикладі я проілюструю це. Припустимо, у вас є метод isGoodPrice (), який використовує метод getPrice (), а ви реалізуєте getPrice () як метод в одиночному.

синглтон, який забезпечує функцію getPrice:

public class SupportedVersionSingelton {

    private static ICalculator instance = null;

    private SupportedVersionSingelton(){

    }

    public static ICalculator getInstance(){
        if(instance == null){
            instance = new SupportedVersionSingelton();
        }

        return instance;
    }

    @Override
    public int getPrice() {
        // calculate price logic here
        return 0;
    }
}

Використання getPrice:

public class Advisor {

    public boolean isGoodDeal(){

        boolean isGoodDeal = false;
        ICalculator supportedVersion = SupportedVersionSingelton.getInstance();
        int price = supportedVersion.getPrice();

        // logic to determine if price is a good deal.
        if(price < 5){
            isGoodDeal = true;
        }

        return isGoodDeal;
    }
}


In case you would like to test the method isGoodPrice , with mocking the getPrice() method you could do it by:
Make your singleton implement an interface and inject it. 



  public interface ICalculator {
        int getPrice();
    }

Остаточна реалізація Singleton:

public class SupportedVersionSingelton implements ICalculator {

    private static ICalculator instance = null;

    private SupportedVersionSingelton(){

    }

    public static ICalculator getInstance(){
        if(instance == null){
            instance = new SupportedVersionSingelton();
        }

        return instance;
    }

    @Override
    public int getPrice() {
        return 0;
    }

    // for testing purpose
    public static void setInstance(ICalculator mockObject){
        if(instance != null ){
instance = mockObject;
    }

тестовий клас:

public class TestCalculation {

    class SupportedVersionDouble implements ICalculator{
        @Override
        public int getPrice() { 
            return 1;
        }   
    }
    @Before
    public void setUp() throws Exception {
        ICalculator supportedVersionDouble = new SupportedVersionDouble();
        SupportedVersionSingelton.setInstance(supportedVersionDouble);

    }

    @Test
    public void test() {
          Advisor advidor = new Advisor();
          boolean isGoodDeal = advidor.isGoodDeal();
          Assert.assertEquals(isGoodDeal, true);

    }

}

У випадку, якщо ми застосуємо альтернативу використання статичного методу для реалізації getPrice (), важко було знущатися над getPrice (). Ви можете знущатися над статикою за допомогою енергетичного знущання, але не весь продукт міг би її використовувати.

Я згоден з цим визначенням:

Слово " єдиний " означає один об'єкт протягом життєвого циклу програми, тому область застосування знаходиться на рівні програми.

У статики немає жодного вказівника на об'єкт, тому область застосування знаходиться на рівні домену додатка.

Більше того, обидва повинні бути реалізовані, щоб бути безпечними для потоків.

Ви можете знайти інші цікаві відмінності щодо: Singleton Pattern Versus Static Class

Одна помітна відмінність полягає в інстанції, що поставляється з Singletons.

За допомогою статичних класів це створюється CLR, і ми не контролюємо це. з одиночними кнопками об'єкт отримує екземпляр з першої інстанції, до нього намагаються отримати доступ.

У багатьох випадках ці двоє практичної різниці не мають, особливо якщо одиночний екземпляр ніколи не змінюється або змінюється дуже повільно, наприклад, тримаючи конфігурації.

Я б сказав, що найбільша різниця полягає в тому, що синглтон все ще є нормальним Java Bean, а не спеціалізованим статичним Java класом. І через це синглтон приймається в багатьох інших ситуаціях; це насправді стратегія створення екземплярів Spring Framework за замовчуванням. Споживач може, а може і не знати, що сингтон передається навколо, він просто ставиться до цього, як до звичайного Java-боба. Якщо вимога змінюється, а одиночному замість цього потрібно стати прототипом, як ми часто бачимо навесні, це можна зробити абсолютно безперешкодно, без зміни коду для споживача.

Хтось ще раніше згадував, що статичний клас повинен бути суто процедурним, наприклад, java.lang.Math. На мій погляд, такого класу ніколи не можна передавати, і вони ніколи не повинні містити нічого, крім статичного остаточного, як атрибути. Для всього іншого використовуйте синглтон, оскільки він набагато гнучкіший і простіший в обслуговуванні.

У нас є база БД, яка встановлює з'єднання з Back end. Щоб уникнути брудних читань для декількох користувачів, ми використовували одиночну схему, щоб гарантувати, що ми маємо доступність одного примірника в будь-який момент часу.

У c # статичний клас не може реалізувати інтерфейс. Коли для одного класу екземплярів потрібно реалізувати інтерфейс для бізнес-контрактів або цілей IoC, саме тут я використовую шаблон Singleton без статичного класу

Сінглтон пропонує спосіб підтримувати стан у сценаріях без громадянства

Сподіваюся, що допоможе вам ..

1. Ледаче завантаження
2. Підтримка інтерфейсів, щоб забезпечити окрему реалізацію
3. Можливість повернення похідного типу (як поєднання лінивого завантаження та реалізації інтерфейсу)

а. Серіалізація - Статичні члени належать до класу, а тому не можуть бути серіалізовані.

б. Хоча ми зробили конструктор приватним, змінні статичних членів все одно будуть перенесені до підкласу.

c. Ми не можемо зробити ліниву ініціалізацію, оскільки все буде завантажено лише при завантаженні класу.

З точки зору клієнта, статична поведінка відома клієнту, але поведінка Singleton може бути завершена прихованою від клієнта. Клієнт може ніколи не знати, що існує лише один єдиний екземпляр, з яким він знову і знову грає.

Я читаю наступне і думаю, що це теж має сенс:

Турбота про бізнес

Пам’ятайте, одне з найважливіших правил ОО - це те, що об’єкт відповідає за себе. Це означає, що питання щодо життєвого циклу класу повинні вирішуватися в класі, а не делегуватись таким мовним конструкціям, як статичні тощо.

з книги «Об’єктно-орієнтований думковий процес» 4-е вид.

У статті, яку я написав, я описав свою точку зору щодо того, чому синглтон набагато кращий, ніж статичний клас:

1. Статичний клас насправді не є канонічним класом - це простір імен з функціями та змінними
2. Використання статичного класу не є хорошою практикою через порушення об'єктно-орієнтованих принципів програмування
3. Статичний клас не можна передавати як параметр для інших
4. Статичний клас не підходить для "ледачої" ініціалізації
5. Ініціалізація та використання статичного класу завжди важко відслідковувати
6. Реалізація управління потоком важко

1. Ми можемо створити об’єкт однокласного класу і передати його методу.

2. Клас Singleton не обмежує спадкування.

3. Ми не можемо розпоряджатись об’єктами статичного класу, але можемо однотонний клас.

Відмінність від статичного класу

У JDK є приклади як однотонних, так і статичних, з одного боку java.lang.Math- кінцевий клас зі статичними методами, з іншого java.lang.Runtime- клас синглтон.

Переваги одинарного

• Якщо вам потрібно підтримувати стан, ніж однотонний шаблон, це кращий вибір, ніж статичний клас, тому що підтримка стану в статичному класі призводить до помилок, особливо в одночасному середовищі, що може призвести до перегонових умов без адекватної синхронізації паралельної модифікації декількома потоками.

• Клас Singleton може бути ледачим навантаженням, якщо його важкий предмет, але статичний клас не має таких переваг і завжди охоче завантажується.

• За допомогою сингтона ви можете використовувати успадкування та поліморфізм для розширення базового класу, реалізації інтерфейсу та надання різних реалізацій.

• Оскільки статичні методи на Java не можуть бути відмінені, вони призводять до негнучкості. З іншого боку, ви можете змінити методи, визначені в однотонному класі, розширивши його.

Недоліки статичного класу

• Простіше написати тест одиниці для однотонного, ніж статичний клас, оскільки ти можеш передавати макетний об'єкт, коли очікується одиночний.

Переваги статичного класу

• Статичний клас забезпечує кращу продуктивність, ніж однотонний, оскільки статичні методи пов'язані на час компіляції.

Існує кілька реалізацій однотонного малюнка, кожен з яких має переваги та недоліки.

• Швидке завантаження синглів
• Двічі перевірений блокування синглтон
• Ідіомія власника ініціалізації на вимогу
• На основі перерахунку синглтон

Детальний опис кожного з них занадто багатослівний, тому я просто поклав посилання на хорошу статтю - Все, що ви хочете знати про Singleton

Існує величезна різниця між одним екземпляром статичного класу (тобто одиничним екземпляром класу, який, як буває, статичною або глобальною змінною), і одним статичним вказівником на екземпляр класу на купі:

Коли ваша програма завершиться, викличе деструктор екземпляра статичного класу. Це означає, що якщо ви використовували цей статичний екземпляр як синглтон, ваш сингтон перестав працювати належним чином. Якщо все ще працює код, який використовує цей синглтон, наприклад, в іншому потоці, цей код, ймовірно, вийде з ладу.

Різниця в моїй голові полягає в реалізації об'єктно-орієнтованого програмування (Singleton / Prototype) або функціонального програмування (Static).

Ми занадто зосереджені на кількості об'єктів, створених однотонною схемою, коли ми повинні зосередитись на тому, що в кінці ми тримаємо об’єкт. Як вже говорили інші, він може бути розширений, переданий як параметр, але головне, щоб він був повним станом.

З іншого боку, статика використовується для реалізації функціонального програмування. Статичні члени належать до класу. Вони без громадянства.

До речі, ви знали, що можете створювати одиночні статичні класи :)