Везде классы и объекты объясняются через простые примеры, но что если у меня стоит задача разработать для автопарка систему учета выхода автобусов на линии, где будет осуществлена запись в файл данных. Куда входят: дата выхода на линию, время выхода, марка автобуса, его городской номер, номер маршрута, ФИО водителя и т.д. На простых примерах все ясно и понятно, но как быть вот с этим, что здесь будет являться классом? Я предполагаю, что это будет просто объект под названием Info, который содержит в себе все эти данные(поля), но не совсем уверен в этом.
В том, чтобы разбить большую задачу на классы, сильно помогает база данных. Проводя нормализацию таблиц, вы проектируете почти полностью подходящие для вас сущности.
Но если начать с проектирования кода, то смотрите: класс Info это слишком общее название. У вас всё - info.
Должен быть класс Driver который содержит информацию о водителе(если водитель не выделен в класс Person). Есть класс Bus, который знает про марку авто. Возможно, он будет содержать list of drivers - с инфой о том, кто обычно управляет этим авто, а может вам нужен driver - ссылка на один объект класса Driver, если нужно знать, кто управляет автобусом именно сейчас.
Направление понятно?
Да, так понятнее намного. А вот у меня еще стоит целью реализация сохрание информации в текстовый файл. Мне нужно создавать метод, в который я буду передавать данные для сохранения в каждом классе или это должно быть реализовано отдельным классом, который возьмет нужные поля у классов и сохранит в файл? Отдельным классом будет удобнее, но будет ли это правильно с точки зрения ооп?
dezzcore, это правильный вопрос. Дело в том, что классов Driver, Bus - недостаточно чтобы сделать приложение. У нас (ориентируясь на Doctrine) принято называть такие классы 'сущностями'. Но, кроме сущностей, в приложении есть классы, которые знают, какие процессы происходят с вашими сущностями (т. н. Бизнес логика).
Например RouteManager который будет реализовывать метод attachDriverToRoute(Driver d, Route r)
...
Который будет знать, что делать (например создавать сущность DriverRouteEntity и сохранять её в таблицу)
Или DriverRegistrator который будет добавлять в автобус водителя который будет им управлять (или управляет сейчас)
dezzcore, за сохранение как раз должен отвечать отдельный класс. Он должен принимать уже готовую для вставки информацию например сериализованный json, или список sql запросов
Ведь когда вы придёте к тому что надо вставлять в базу а не в файл, придётся переписать каждый класс, а так только один
Проводя нормализацию таблиц, вы проектируете почти полностью подходящие для вас сущности.
Ммм. Вот есть у меня сущность продукт, как мне нормализация поможет понять, ProductTitle и ProductDescription я должен использовать, или запихнуть их в одну сущность Product?
Евгений Ромашкан, если они находятся в одной таблице products как столбцы title и description, то в одну сущность. Если они разнесены на products, product_titles, product_descriptions (например, для локализации, интернационализации или других нужд) - то это разные сущности - ProductEntity, ProductDescriptionEntity, ProductTitleEntity.
Decadal, мм. А как сущности связаны с таблицами с БД? Почему стоит их делать такими же?
Что если у меня две базы и в них они по разному хранятся? Что если в моделях на чтение и запись у меня по разному продукты выглядят?
И ещё, раз сущности зависят от базы, вы не ответили на изначальный вопрос - вот я нормализую базу мне title и description в одну таблицу ложить или несколько?
Евгений Ромашкан, для автора вопроса он вполне несет конкретику. А вы задаете вопросы не для того, чтобы получить ответы, поэтому склонны видеть то, что хотите увидеть.
Decadal, К сожалению автору вопроса эта информация поможет лишь сформировать урывочное и вряд-ли верное представление о теме вопроса, и ложное ощущение что он что-то понял. Впрочем... Как и любая другая информация собранная по крупицам со всяких статей а интернете и сомнительных источников типа хабра и тостера.
Другое дело, что если бы dezzcore действительно хотел разобраться в вопросе приложил бы хоть немного усилий вместо того чтобы лезть на Тостер с глупыми вопросами
Евгений Ромашкан, полагаю, вы заносчивы) кто есть вы, чтобы говорить, какой вопрос глупый, а какой умный? Советую пользоваться алгоритмом - отвечайте на умные вопросы и молчите на глупые. Обижать незнакомых людей невежливо
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;
}
}
Max Goncharenko, отношение многие к одному: на одной линии может быть несколько автобусов, если на оборот то несколько линий ссылаются на один автобус. Но можно список автобусов поместить в Line.
Ascar, а как можно реализовать вывод ошибки в другом классе? Т.е у меня есть поле дата и свойство. И у меня есть проверка строки, на наличие точки в 3 символе. Мне надо чтобы в вин форме выводилось сообщение о том, что нет точки, но как мне правильно передать об этом сообщение в вин форму?(согласно ооп) Или нужно строить проверку значений непосредственно в самой форме, а не в классе линии?
class Line{
{
private string date;
public string Date
{
get{ return date;}
set
{
if (value.IndexOf(".") == 2)
{
date = value;
}
}
}
