Правильный способ перемещения общих свойств

Question

У меня есть набор свойств около 20 из них, которые мне нужны в двух разных сущностях (классах) для иерархической системы переопределения.

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

Но это не сработает, поскольку у меня также есть более общие свойства, общие для всех объектов. Поэтому я уже наследую все сущности. И эти 20 свойств не являются общими для всех объектов (только два - три из них). Таким образом, я не могу добавить эти 20 свойств в существующий абстрактный класс.

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

Любая идея? Каков правильный способ сделать это? В ближайшем будущем у меня могут быть более общие свойства для нескольких объектов. Итак, что мне делать, чтобы сохранить согласованность между общими свойствами без повторного посещения и повторной записи общих свойств в каждом из объектов?

Answer 1

Наследовать свой класс «обычных настроек» из класса «общая сущность». Затем выведите классы настроек из общего класса настроек.

class common_entity {} 

class common_settings : common_entity {} 

class settings : common_settings {} 

class entity : common_entity {} 

Answer 2

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

Посмотреть этот пример кода

public class Person 
{ 
    public string Name { get; set; } 
} 

public class Company 
{ 
    public string Name { get; set; } 
} 

И только потому, что мы считаем, что оба класса разделяют Name собственность, мы должны создать базовый класс:

public class Entity 
{ 
    public string Name { get; set; } 
} 

public class Person : Entity 
{ 
} 

public class Company : Entity 
{ 
} 

Я бы окончательно определить базовый класс сущностей потому что любой объект должен иметь уникальный идентификатор, но не для Name. И если подмножество сущностей должно иметь Name, я бы определил interface, который бы или не был реализован конкретными объектами. Позже я спрошу объекты, реализуют ли они данный интерфейс (т. Е. obj is IWhatever или var whatever = obj as IWhatever).

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

Просто проверьте, что вы сказали:

У меня есть набор свойств около 20 из них, которые мне нужно в двух различных объектах

Итак, вы два классов который должен реализовать 20 свойств, и вы почесываете голову только потому, что можете определить interface, и вам нужно будет реализовать его в этих двух классах?

Перейти к interface подход! Разве Visual Studio не имеет генерации кода реализации интерфейса?

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