ndimo
@ndimo

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

Здравствуйте!
Для личного опыта разрабатываю некую программу. Язык программирования выбрал C#. И начал сперва строить бизнес логику программы в диаграмме UML. Получилось вот как-то так (данная диаграмма не корректна, то есть примерный шаблон который подлежит к дальнейшей коррекций и дополнений. Примерно 1/3 часть программы):
b0faa0c975774cda9bcc540f6f7d3561.jpg
После этих набросок у меня возник странное ощущение?! Так как у меня нет опыта разработки и моделирования проектов, задался такими вопросами: "А все ли правильно я делаю?", "Правильно ли я строю диаграмму?", "Тут надо больше использовать наследование классов или же агрегацию классов?", "Нормально ли создавать в каждом классе куча экземпляров других классов?", "Не режет ли потом данная программа по производительности ПК с такими количеством уровнями классов?", и тому подобные вопросы.

Набросал несколько кодов по данной диаграмме. Создание и инициализаци экземпляров класса получилось как-то так. После увиденного мне совсем страшно стало :D (тоже подлежит к дальнейшей коррекций):
55e2151a17de4017b363fd04b3b89510.png
Как видите, у меня образовался куча вопросов на которые не могу получить ответов. Прошу опытных разработчиков раскритиковать меня, ответить на вопросы и дать советов на будущее! :D

К сожалению тег спойлера не нашел.
  • Вопрос задан
  • 722 просмотра
Пригласить эксперта
Ответы на вопрос 5
angrySCV
@angrySCV
machine learning, programming, startuping
конечно не правильно. Откуда вообще эта вера в то что всё можно делать правильно?
вы не можете создавать новый продукт сразу правильно, большинство вещей вы только в процессе реализации можете понять, как сделать лучше. Поэтому позвольте себе ошибаться, не бойтесь ошибаться, ошибайтесь, исправляйтесь и развивайте продукт.
Ответ написан
Комментировать
@Beltoev
Живу в своё удовольствие
- Методы?
- Не, не слышал

А если точнее:
Company c = new Company();
c.SetInfo("Travel", "Touristic company");

Address address = new Address();
var idCountry = address.AddCountry("Name");
var idCity = address.AddCity(idCountry, "City");
address.AddOffice(idCity, "Main office", "Street", "Email", ... );

Contact contact = new Contact("website", address);
c.AddContact(contact);

Tour tour = new Tour("China", "Hong Hong");

c.AddTour(tour);
...


Набросок грубый, но суть того, как было бы правильнее, думаю, передает доходчиво
Ответ написан
@VanKrock
А тут вложенность и не нужна.
Вот у вас есть сущность Компания (Company) в вашей компании разве есть страны? Нет, у нее есть офисы (Office)
А у офисов уже есть адрес (Address) какой то конкретный и на все остальные ему как бы пофиг поэтому вложенность тут не нужна, она понадобится при заполнении например чтобы показать dropbox пользователю, для этого сделайте AddressDataBase какой-нибудь со вложенностью адресов. И у обычно если много офисов, то у них указывают контактные данные

то есть
class Company
{
    public List<Office> Offices {get; set;}
    public string Description {get; set;} //Тут описание вашей компании: год основания там и все такое.
    public Contacts GlobalContacts {get;set;} //Глобальные контакты для всей компании
}

class Office
{
    public Address Address {get; set;}
    public List<Employee> Employees {get; set;}
    public List<Tour> Tours {get;set;}
    public Contacts Contacts {get;set;}
}

class Address
{
    public string Country {get;set;}
    public string City {get;set;}
    public string Street {get;set;}
    public string HouseNumber {get; set;}
}

class Tour
{
    public string Country {get; set;}
    public string City {get; set;}
    public Hotel Hotel {get; set;}
}


class Hotel
{
    public string Description {get;set;}
    public Address Address {get; set;}
    public List<Image> Images{get; set;}
}


Ну и конечно сделайте конструкторы.

Инициализация офиса будет такой

var office = new Office(
                new Address(country, city, street, houseNumber), 
                new List<Employee>(),
                new List<Tour>(),
                new Contacts { Email = "office@mail"} 
                );
Ответ написан
Nipheris
@Nipheris Куратор тега C#
"Нормально ли создавать в каждом классе куча экземпляров других классов?", "Не режет ли потом данная программа по производительности ПК с такими количеством уровнями классов?"


А вы поймите, что если вас беспокоит приведеннный вами код, вам надо не о сколько о классах думать, и не о производительности, сколько о функциях и методах. Зелим Бельтоев уже хорошо намекнул вам об этом, я скажу еще раз словами: то, что ОБЪЕКТОВ много и между ними сложные связи - это НОРМАЛЬНО. Самое главное, что у вы должны уметь ограничивать - сложность и объем связей в КОНКРЕТНОМ участке кода. Пока вы понимаете, ЧТО у вас написано в конкретном методе, и КАК это себя ведет (причем, это понимание не расходится с рельностью) - вы все делаете правильно. Это важнейший критерий. Производительность это тоже фактор, но я даже не могу себе представить, насколько сложную структуру классов нужно изобрести, чтобы она реально мешала тому же CLR исполнять код. Реально узкие места по пр-ти возникают в алгоритмах с высокой алгоритмической сложностью, таких мест обычно мало (если они вообще есть, в бизнес-приложениях в 99% случаев все упирается в IO, или в необходимость побольше кэшировать на клиенте), и они целенаправленно оптимизируются.
Ответ написан
Сам искал хорошие уроки по этой теме, но не нашел таковых (что бы в полном объеме все на пальцах показывали :D ).
Читайте msdn -> Руководство по разработке библиотек классов

Правила именования
Описывает правила именования типов и членов в библиотеках классов.

Правила разработки типов
Описывает правила по использованию статических и абстрактных классов, интерфейсов, перечислений и структур.

Правила разработки членов
Описывает правила разработки и использования свойств, методов, конструкторов, полей, событий и операторов. В данном разделе также описываются лучшие методики разработки.

Разработка с обеспечением расширяемости
Описывает правила по проектированию расширяемых библиотек.

Правила разработки исключений
Описывает правила по проектированию, генерации и обработке исключений.

Правила использования
Описывает правила использования массивов и атрибутов, а также правила реализации операторов равенства.
Ответ написан
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы