Пользователь пока ничего не рассказал о себе

Наибольший вклад в теги

Все теги (7)

Лучшие ответы пользователя

Все ответы (6)
  • Где взять реальные примеры кода использования ооп в веб-сервисах?

    @netcore
    Есть группа людей которые не понимают в программировании ничего, но у них есть идея, понимание как работает продукт, и деньги (но это вторично)
    Назовем эту группу людей бизнес

    Продукт этого бизнеса - сайт новостей. Возьмем как пример сайт новостей, потому что это по сути тот же блог.
    Есть программист который понимает как автоматизировать действия этой идеи и оцифровать поведение продукта

    Сначала бизнес описывает боль которую решает продукт
    В чем боль? Бизнес раньше продавал газеты, а теперь хочет свою интернет газету.
    1. Они не хотят тратить деньги на печать, а просто делать посты новостей и статьи.
    2. Они не хотят платить деньги на транспортные расходы развозить газеты, а делать рассылки на электронную почту
    3. Они хотят получать обратную связь (комментарии)
    этого достаточно для примера.

    В идеале бизнес заказывает дизайн. Как это должно выглядеть.
    В идеале есть еще и пордакт менеджер который знает UML, но это влажные фантазии, по этому примем что есть бизнес и есть программист.

    Затем описываются сущности этого продукта и действующие лица в этом продукте
    Что мы можем понять из этого? Какие у нас есть сущности?
    1. пост - новость или статья на сайте.
    1.1. На этом этапе выясняем у бизнеса в чем отличие новости от статьи.
    Бизнес говорит: у новости (например) есть только одна картинка, текст.
    У статьи есть так же текст но картинок может быть несколько, так же не может быть комментариев.
    Бизнес забыл про то что в дизайне есть еще и дата, тут уже додумывает сам программист взглянув на макеты.
    В итоге у нас получается одна абстрактная модель Post и две ее реализующие: Article и News.

    public abstract class Post
        {
            protected Post(string text, int writerId)
            {
                Text = text;
                CreationDate = DateTime.Now;
                WriterId = writerId;
            }
    
            public int Id { get; set; }
            public string Text { get; private set; }
            public DateTime CreationDate { get; private set; }
            //Идентификатор писателя статьи\новости
            public int WriterId { get; private set; }
    
            //Автоматически подтягиваемая из базы модель писателя через ORM по WriterId
            public virtual Writer Writer { get; set; }
    
        }
    
        public class Article : Post
        {
            public Picture[] Pictures { get; private set; }
    
            public Article(string text, int writerId, Picture[] pictures) : base(text, writerId)
            {
                Pictures = pictures;
            }
        }
    
        public class News : Post
        {
            public Picture Picture { get; }
            
            //Массив комментариев к посту
            // private set -- говорит о том что массив инкапсулирован
            // и управлять массивом можно только через метод AddComment
            public List<Commentary> Commentaries { get; private set; }
    
            public News(string text, int writerId, Picture picture) : base(text, writerId)
            {
                Picture = picture;
            }
    
            public void AddComment(Commentary commentary)
            {
                Commentaries.Add(commentary);
            }
        }


    Далее у нас есть ролевые модели и у каждого своя бизнес логика.
    2. Подписчик - получатель новостей. Бизнес хочет что бы каждый зареганый юзер автоматически стал подписчиком. Такого в реальном мире не будет, нельзя, но для примера норм.
    3. Писатель - тот кто пишет статьи\новости.

    Две эти модели отличаются между собой только ролью и наличием у подписчика поля email. По этому приведем вот такие ООП модели

    public abstract class User
        {
            public int Id { get; set; }
            public string Username { get; private set; }
            public string Role { get; private set; }
            
            protected User(string role, string username)
            {
                Role = role;
                Username = username;
            }
        }
    
        public class Subscriber : User
        {
            public string Email { get; private set; }
            
            public Subscriber(string username, string email) : base(nameof(Subscriber), username)
            {
                Email = email;
            }
        }
    
        public class Writer : User
        {
            public Writer(string username) : base(nameof(Writer), username)
            {
            }
        }


    Поле пароль опущено, тут много чего опущено для простоты восприятия.

    3. Комментарий - обратная связь от юзера в посте. При чем хочу заметить от ЮЗЕРА, бизнес говорит что писать могут как и подписчик так и писатель

    public class Commentary
        {
            public int Id { get; set; }
            public string CommentText { get; private set; }
            public int UserId { get; private set; }
            
            public virtual User User { get; private set; }
            
            public DateTime CommentCreationDate { get; private set; } 
            
            public Commentary(int userId, string commentText)
            {
                UserId = userId;
                CommentText = commentText;
                CommentCreationDate = DateTime.Now;
            }
        }


    Вот - хоть и примитивно и немного неправильно (а то щас налетят пет программисты) но мы описали модели, абстрагировали одинаковые поля в абстрактные классы. Инкапсулировали поля и добавили методы которые описывают как работает класс. Инициализация полей происходит только в конструкторах. Работа с полями только с предоставленными для этого методами.

    Прошу прощения что не PHP, но C# тоже C подобный, так что проблем с чтением на уровне моделей быть не должно.

    Одна из функций ООП -- что бы программисты понимали бизнес.
    Ну и человеку прозе описывать поведение реального мира объектами и как эти объекты между собой взаимодействуют.
    Есть целые методологии разработки ПО такие как DDD, где вообще ядро кода пишется на копароративном языке и жестко соблюдаются правила названия моделей и описания алгоритмов бизнес процессов бизнеса. Код получается самодокументированным. Были случаи когда ядро по DDD писали даже на русском, потому что бизнес большой, а новичкам, кто приходил кодить в фирму, было быстрее и проще вкатиться в понимание прикладной практики бизнеса и понять по коду как бизнес устроен на разных слоях.
    Ответ написан
    1 комментарий
  • Почему In Memory Database не автогенерирует int свойство?

    @netcore Автор вопроса
    Решил по-другому в OnModelBuilding

    if (DataBase.IsInMemory())
    var autoGenIntProperties = modelBuilder.Model.GetEntityTypes()
                    .SelectMany(t => t.GetProperties())
                    .Where(p => p.ClrType == typeof(int) && p.ValueGenerated != ValueGenerated.Never);
    
                foreach (var property in autoGenIntProperties)
                    property.SetValueGeneratorFactory((p, t) => new InMemoryIntegerValueGenerator<int>(p.GetIndex()));


    Это скорее всего потому что:
    1. Ключи понятно как инкрементить, а кастомные поля нет
    2. У каждой бд реализация этого кейса разная, по этому нужно явно указывать в InMemory как отыгрывать этот кейс

    Странно что в апишке не предусмотрели этот кейс обязательного использования инкрементации при инициализации, что бы юзеры не ломали голову часами
    Ответ написан
    Комментировать
  • Какие книги подойдут новичку по языку C#?

    @netcore
    Я как делал:
    Купил справочник c# толстенный.
    Читаешь первые 4 главы как там советуют, въезжаешь, переписываешь код, понимаешь как устроен язык и синтаксис в принципе

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

    Тупо копипастишь код лишь бы заработало.

    Потом смотришь непонятные блоки кода. Что не понял - лезешь в справочник и читаешь как это устроено и работает, где то исправляешь ошибки свои.

    Далее наращиваешь боту функционал. Например показывать погоду используя сторонние сервисы, там уже поймёшь как работать с API сторонних сервисов.

    + Раз в день читаешь главу, не особо стараясь вникать. Зачем? А затем что когда в жизни столкнешься с проблемой, вспомнишь примерно как это решать и в какую сторону гуглить.

    Справочник год лежал на столе, был отличным помощником в начале пути.
    До сих пор иногда туда заглядываю
    Ответ написан

Лучшие вопросы пользователя

Все вопросы (5)