Как правильно выделить объект и класс в ООП?

Question

[dezzcore]

Везде классы и объекты объясняются через простые примеры, но что если у меня стоит задача разработать для автопарка систему учета выхода автобусов на линии, где будет осуществлена запись в файл данных. Куда входят: дата выхода на линию, время выхода, марка автобуса, его городской номер, номер маршрута, ФИО водителя и т.д. На простых примерах все ясно и понятно, но как быть вот с этим, что здесь будет являться классом? Я предполагаю, что это будет просто объект под названием Info, который содержит в себе все эти данные(поля), но не совсем уверен в этом.

Answer 1

[Decadal]

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

Но если начать с проектирования кода, то смотрите: класс Info это слишком общее название. У вас всё - info.

Должен быть класс Driver который содержит информацию о водителе(если водитель не выделен в класс Person). Есть класс Bus, который знает про марку авто. Возможно, он будет содержать list of drivers - с инфой о том, кто обычно управляет этим авто, а может вам нужен driver - ссылка на один объект класса Driver, если нужно знать, кто управляет автобусом именно сейчас.
Направление понятно?

Comments

[dezzcore]

Да, так понятнее намного. А вот у меня еще стоит целью реализация сохрание информации в текстовый файл. Мне нужно создавать метод, в который я буду передавать данные для сохранения в каждом классе или это должно быть реализовано отдельным классом, который возьмет нужные поля у классов и сохранит в файл? Отдельным классом будет удобнее, но будет ли это правильно с точки зрения ооп?

[Decadal]

dezzcore, это правильный вопрос. Дело в том, что классов Driver, Bus - недостаточно чтобы сделать приложение. У нас (ориентируясь на Doctrine) принято называть такие классы 'сущностями'. Но, кроме сущностей, в приложении есть классы, которые знают, какие процессы происходят с вашими сущностями (т. н. Бизнес логика).
Например RouteManager который будет реализовывать метод attachDriverToRoute(Driver d, Route r)
...
Который будет знать, что делать (например создавать сущность DriverRouteEntity и сохранять её в таблицу)

Или DriverRegistrator который будет добавлять в автобус водителя который будет им управлять (или управляет сейчас)

[Decadal]

dezzcore, за сохранение как раз должен отвечать отдельный класс. Он должен принимать уже готовую для вставки информацию например сериализованный json, или список sql запросов

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

[Ascar]

Decadal, если вы совмещаете с базой, то создайте сразу сущности EF. А оставлять или нет value objects на ваше усмотрение.

[dezzcore]

Decadal, Хорошо, спасибо вам

[Ascar]

dezzcore, можно еще отметить ответ как правильный

[Евгений Ромашкан]

Проводя нормализацию таблиц, вы проектируете почти полностью подходящие для вас сущности.

Ммм. Вот есть у меня сущность продукт, как мне нормализация поможет понять, ProductTitle и ProductDescription я должен использовать, или запихнуть их в одну сущность Product?

[Decadal]

Евгений Ромашкан, если они находятся в одной таблице products как столбцы title и description, то в одну сущность. Если они разнесены на products, product_titles, product_descriptions (например, для локализации, интернационализации или других нужд) - то это разные сущности - ProductEntity, ProductDescriptionEntity, ProductTitleEntity.

[Евгений Ромашкан]

Decadal, мм. А как сущности связаны с таблицами с БД? Почему стоит их делать такими же?
Что если у меня две базы и в них они по разному хранятся? Что если в моделях на чтение и запись у меня по разному продукты выглядят?

И ещё, раз сущности зависят от базы, вы не ответили на изначальный вопрос - вот я нормализую базу мне title и description в одну таблицу ложить или несколько?

[Decadal]

Евгений Ромашкан,

https://www.doctrine-project.org/index.html
https://hibernate.org/
вперед

[Евгений Ромашкан]

Decadal, Эти инструменты я и так знаю, лишь хотел намекнуть что ваш ответ не несёт абсолютно никакой конкретики )

[Decadal]

Евгений Ромашкан, для автора вопроса он вполне несет конкретику. А вы задаете вопросы не для того, чтобы получить ответы, поэтому склонны видеть то, что хотите увидеть.

[Евгений Ромашкан]

Decadal, К сожалению автору вопроса эта информация поможет лишь сформировать урывочное и вряд-ли верное представление о теме вопроса, и ложное ощущение что он что-то понял. Впрочем... Как и любая другая информация собранная по крупицам со всяких статей а интернете и сомнительных источников типа хабра и тостера.
Другое дело, что если бы dezzcore действительно хотел разобраться в вопросе приложил бы хоть немного усилий вместо того чтобы лезть на Тостер с глупыми вопросами

[Decadal]

Евгений Ромашкан, полагаю, вы заносчивы) кто есть вы, чтобы говорить, какой вопрос глупый, а какой умный? Советую пользоваться алгоритмом - отвечайте на умные вопросы и молчите на глупые. Обижать незнакомых людей невежливо

[Евгений Ромашкан]

Decadal, это публичный ресурс, и к сожалению на этот вопрос будут натыкаться и другие люди.

Answer 2

[Ascar]

Ваши доменные объекты будут примерно такими:

class Bus{
    public string Model {get;}
    public string Number {get;}    
    public Driver Driver {get;}   
    public Line Line{get;}
    public Bus(string model, string number, Driver driver, Line line){
        Model = model;
        Number = number;
        Driver=driver;
        Line=line;
    }
}

class Driver{
    public string Name {get;}    
    public Driver(string name){
        Name = name;        
    }
}

class Line{
    public DateTime GoTime {get;}
    public string Number {get;}    
    public Line(DateTime goTime, string number){
        GoTime = goTime;
        Number = number;
    }
}

Comments

[Max Goncharenko]

тут скорее Line владеет Bus, а не наоборот

[Ascar]

Max Goncharenko, отношение многие к одному: на одной линии может быть несколько автобусов, если на оборот то несколько линий ссылаются на один автобус. Но можно список автобусов поместить в Line.

[Max Goncharenko]

Ascar, да, я про список. Так просто будет читабильнее

[Ascar]

Max Goncharenko, более того если автор решит написать EF code first, то ему придется делать список.

[dezzcore]

Ascar, а как можно реализовать вывод ошибки в другом классе? Т.е у меня есть поле дата и свойство. И у меня есть проверка строки, на наличие точки в 3 символе. Мне надо чтобы в вин форме выводилось сообщение о том, что нет точки, но как мне правильно передать об этом сообщение в вин форму?(согласно ооп) Или нужно строить проверку значений непосредственно в самой форме, а не в классе линии?

class Line{
  {
        private string date;

        public string Date
        {
            get{ return date;}
            set
            {
             if (value.IndexOf(".") == 2)
                {
                    date = value;
                }
            }
           
            
        }

[Ascar]

dezzcore, выбрасывайте исключение в самом классе, валидируйте до присваивания значения. Но лучше используйте DateTime.
Валидация:

if(DateTime.TryParseExact("31.12.2001", "dd.MM.yyyy", 
        System.Globalization.CultureInfo.InvariantCulture,
        System.Globalization.DateTimeStyles.None, out DateTime dt)){
        Line.Date = dt;
       }

class Line{
  {
        private DateTime date;
        public DateTime Date{get;set;}
}