Есть группа людей которые не понимают в программировании ничего, но у них есть идея, понимание как работает продукт, и деньги (но это вторично)
Назовем эту группу людей
бизнес
Продукт этого бизнеса - сайт новостей. Возьмем как пример сайт новостей, потому что это по сути тот же блог.
Есть программист который понимает как автоматизировать действия этой идеи и оцифровать поведение продукта
Сначала бизнес описывает боль которую решает продукт
В чем боль? Бизнес раньше продавал газеты, а теперь хочет свою интернет газету.
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 писали даже на русском, потому что бизнес большой, а новичкам, кто приходил кодить в фирму, было быстрее и проще вкатиться в понимание прикладной практики бизнеса и понять по коду как бизнес устроен на разных слоях.
