All streams
Search
Write a publication
Pull to refresh
27
0
Хитман @DangerT

Архитектор программных систем

Send message
Код приводить не могу — NDA. Скажу вкратце — нужнь было бизнес-объект включить в дерево в пользовательском интерфейсе. Конечно проникновение UI в бизнес-слой — это грубейшая ошибка проектирования, но так надо было. Такая специфическая задача была — обертку невозможно было использовть. Да еще и для организации взаимодействия с UI использовался MVVM. Так вот существовал класс, реализующий полностью функционал узла дерева — TreeNodeBase. И был некий LinqEntityBase класс. Задача изящно решалась бы если было бы возможно: Product: LinqEntityBase, TreeNodeBase. А на деле пришлось: Product: LinqEntityBase, ITreeNode + паттерн Декоратор.
Ну это будет не совсем то. Дело в том, что при наследовании, если вы захотите переопределить в другом классе некий статический метод или свойство — вам придеться воспользоваться модификатором new. А это синтаксически будет совсем не то же самое что перегрузка.
Черт… Совершенно забыл за несколько лет забвения Делфи… Что такое «методы класса» — пример краткий можно?
В моей практике уже есть как минимум два сценария, в который множественное наследование было бы КРАЙНЕ желательным. И вы не поверите, к каким ухищрениям пришлось прибегнуть, чтобы это обойти.
Можно — но никто не мешает расширить его функционал в производных классах.
Совершенно верно. Хотел привести в конце этот вариант, но не стал. Хотелось написать более «академическую» статью без деталей имплементации .NET 4.0.
Это ограничения любого CLI-совместимого языка платформы .NET — С#, VB .NET и пр.
Честно говоря не задумывался ранее о совместимости с Java :)
Спасибо за интересную информацию! С интересом прочел.
Кстати а что вы имели ввиду под «инрерфейсом»?
Синглтон — это чудесное спасение :)

Статья выглядит именно так? Самое интересно что я такой цели не преследовал :)
А работу с многопоточносю я НАМЕРЕННО не стал рассматривать :) Так как, во-первых очень спать хотелось, а во вторых, думаю все вменяемые разработчики уже давно используют Double-Checker для синхронизации доступа к экземпляру синглотона. Например, так:
public class Singleton<T> where T : class
{
    // ...
 
    public static T Instance
    {
        get
        {
            if (_instance == null)
            {
                lock (_locker)
                {
                    if (_instance == null)
                    {
                        _instance = CreateInstance();
                    }
                }
            }
 
            return _instance;
        }
    }
}
Вы видимо недопоняли зачем нужен код, использующий поиск конструктора. Предложенный вами вариант будет работать только если класс-синглтон объявлен так:

public class Session : Singleton<Session>
{
    public Session()
    {
    }
 
    public bool IsSessionExpired()
    {
        return false;
    }
}


В противном случае вы получите на этапе компиляции 'ConsoleApplication1.Session' must be a non-abstract type with a public parameterless constructor in order to use it as parameter 'T' in the generic type or method 'ConsoleApplication1.Singleton'.
Ну а поскольку вы будете вынуждены сделать конструктор открытым — возможно будет создать много экземпляров этого класса. Какой же это синглтон?
Согласен. Но иногда некоторые объекты очень удобно делать синглтонами если это не вступает в конфликт с общей архитектурой системы. Ну напрмер некий менеджер сессий SessionManager, репозитарий словарей DictionaryRepository и т.д.
Я хотел раскрыть данный вопрос именно в ньюансах некоторых сценарияев использования.
Индусы бывают во много крат хуже китайцев — я имел опыт общения с индусами внутри одной большой компании, на которую работаю сейчас (небольшой спойлер :). Поэтому говорю, основываясь исключительно на собственном опыте. Тупее быдлокодеров я не видел. А на работу их берут часто из-за diversity.
Кстати очень понравился ваш сайт. И, да — действительно не хватает скриншотов. Я специально полез под кат в надежде «пощупать» скрины, а тут… :(
ААааааа! «Школоло»! :)))

* дожевываю свои тапки *
Я читал как-то один юмористический рассказ о том, как один священник взгрел подобного мошенника на 80 долларов (пруфлинк не получилось нагуглить). Там веселая ситуация была — нигерийца поимели его же собственным методом :)))
Отличная статья, приятный стиль изложения. Но проверьте пожалуйста текст на орфографию — очень режет глаза в некоторых местах: «по этому» например. Думаю вы просто спешили, когда набирали — ничего страшного со всеми случается :)

Information

Rating
Does not participate
Location
Россия
Registered
Activity