Declare a class as attribute or implement Abstract?

Question

You have LG branded television. in this scheme I can have different types of televisions and different types of electronics (so that the system can grow and I can use it not only for the tracking of electronics, but also for textile and food tracking)

What is the most correct way to describe this situation?

Way 1

// You can be Electronic, or later a new type like Clothes, Food ...

public class Tipo {
   public int Id {get;set;}
   public string Descricao {get;set;}
}

// It can be the brand of my electronic, or later a type of Clothing or Food

public class Marca {
   public int Id {get;set;}
   public string Descricao {get;set;}
   public Tipo Tipo {get;set;}
}

// Where this item can be a Television, or a Shirt and even a Chocolate.

public class Item {
   public int Id {get;set;}
   public string Descricao {get;set;}
   public Marca Marca {get;set;}
}

That way I can notice I did the OO as general as possible, but at the time of the creation of the item It is possible to notice that products with different brands may have different attributes. for example, an electronic can have the voltage attribute, where clothes and food would not have. leading this argument in question, it is possible to say that the most correct idea would be:

Way 2

// The guys

public abstract class Eletronico {
    public int IdTipo {get;set;}
    public string DescricaoTipo {get;set;}
}

public abstract class Roupa {
    public int IdTipo {get;set;}
    public string DescricaoTipo {get;set;}
}

public abstract class Comida {
    public int IdTipo {get;set;}
    public string DescricaoTipo {get;set;}
}

// Marks where they belong to a type

public abstract class LG : Eletronico {
    public int IdMarca {get;set;}
    public string DescricaoMarca {get;set;}
}

public abstract class Samsung : Eletronico {
    public int IdMarca {get;set;}
    public string DescricaoMarca {get;set;}
}

public abstract class Versace : Roupa {
    public int IdMarca {get;set;}
    public string DescricaoMarca {get;set;}
}

public abstract class Lascote: Roupa {
    public int IdMarca {get;set;}
    public string DescricaoMarca {get;set;}
}

public abstract class McDonalds: Comida {
    public int IdMarca {get;set;}
    public string DescricaoMarca {get;set;}
}

public abstract class BurguerKing: Comida {
    public int IdMarca {get;set;}
    public string DescricaoMarca {get;set;}
}

// And now yes our items

public class TelevisaoLG : LG {
    public int Id {get;set;}
    public string Descricao {get;set;}
    public int Polegadas {get;set;}
    public int Voltagem {get;set;}
}

public class TelevisaoSamsung : Samsung {
    public int Id {get;set;}
    public string Descricao {get;set;}
    public int Polegadas {get;set;}
    public int Voltagem {get;set;}
    public bool Suporte4k {get;set;}
}

public class Camiseta : Lacoste {
    public int Id {get;set;}
    public string Descricao {get;set;}
    public int Tamanho {get;set;}
}

public class LancheWhooper : BurguerKing {
    public int Id {get;set;}
    public string Descricao {get;set;}
    public int Calorias {get;set;}
}

Thus the oo gets longer but this way it is easier to identify a smaller coupling between classes.

My doubts are:

• What is the most correct way to do it? In way 1 or way 2?
• There is a better way, if yes how?
• In way 2, the correct way is to use even the method abstract us
  types and brands? and it is possible to make a class abstract implement
  another class abstract?
• Taking into account that the Way 2 is the most appropriate and we have the following types as an example: Eletronico, Roupa, Comida. then I have a class for each one. Now the system will also working with a new guy Automobilistico so that users can use I will have to update my project creating a class Automobilistico (Type)? and generate all Tags and Items in a manner manual? Why in the Way 1 the more generic mode facilitates to create only the type Automobilistico in my database and also add tags and items to the database. Like this would stay in the Way 2?

Answer 1

Before I start I have to say what you call an attribute is actually called a field and what you are actually using is neither, is the property.

I also have to warn you that you’re trying to do something that’s not simple. It looks simple and may work at first, but the moment you use it for the real product types it may not work that well. Generalization is always complicated and only works if you have a lot of control of the situation and a deep understanding of its use. In general people do not have both, especially in business domain, own experience.

Models

Also in much of the cases that use this kind of modeling that objects pass have identity in the class itself and not in the object (second way) does not work well and I’m almost sure that is an artificial example that resembles what is shown in books, which are examples to show the mechanisms of object orientation, but are very bad at modeling real applications. So I guess you’re learning academic O that’s no use for what you actually use. If you deal with thousands of different products in stock, will you have thousands of classes? If I do this it will be the most confusing system I’ve ever seen in my life and it only works as an exercise (than not doing it even though it feels right).

Right way depends on the detailed requirements, which we don’t have. I hope you have them to make good decisions. But from what I’ve said it already indicates that the first way seems more sensible for most cases.

The correct solution seems to go through a mechanism that controls the products in a generic way and has a mechanism to deal with the specific differences, something that can be very sophisticated, but anyway it seems a case of composition and not inheritance, as almost everything we do. People learn OO and dazzle with heritage, but almost always she violates the liskov principle and causes problems.

The most I can think of, and this may be an exaggeration, is to have an abstract class Produto and some concrete that are some few types of products that have much difference as Automovel or and Eletronico. But I can only provide a solution by understanding all aspects of the problem, which would make this a very broad question.

Real solution

The code seems to have other typing problems, such as using int for voltage. This is a given descriptive and not quantitative, So it doesn’t make sense for him to be numerical just because the description only involves digits. The size got worse because it is common to use letters, and these are only two examples, almost all others are wrong too. Of course, if you’re still wearing this, I wouldn’t wear it like this. And precisely because in general these data are only descriptive and you don’t have to do any specific operation with them a generic mechanism of keeping multiple descriptions may be much more appropriate than having specific properties on objects, so it would only have a generic description set property with the famous key pair (what it is describing) and value (the description itself of that sub-property), perhaps using a dictionary that has key-value.

For me you have a case of a Produto which follows the traditional model and has a series if purely descriptive sub properties that vary according to the product. Because they are embellishments to the object they should be configured according to the product. In a database you would use a JSON, XML column, array, or string with specific format to record all this. Some people would create a string that works as a free t6ext to put all these descriptions as one thing. I don’t think it looks good, but it’s not a terrible solution in some cases.

Another way of thinking this is to have a property that is a reference to another object (or another table in the database) and then in that object would have the specific data, the difference to the previous solution is that it would have a different class for each product. It would still have many classes, but at least not many products, which would keep the data more organized having a central point of products that refer to specific objects only in the specific part, works as a paper. But that’s only true if the data should have specific functionality beyond description, I don’t think that’s the case.

If you really have this need then inheritance may not be the end of the world. But it can be complicated because it seems that I would have to make combinations of properties and I would have to reimplement some things because C# does not have multiple inheritance (the languages they have do not recommend and does not solve the problem so well)

Of course if these sub-properties need specific operations and not only will they be presented in a basic way then it starts to complicate, but then we enter the field of speculation, nothing indicates that you need this and until you have clear indication and details of how to proceed in each case better not even think about it.

Artificial problems

If the "problem" is artificial it will almost always come out wrong. Or is it inherently right because if anything was invented it can be done and be right, the hard thing is to make it sustain itself in the real world with requirements that change without its control.

To tell the truth this example is complex and without very well collected requirements and without experience the chance of this going wrong is great. It will work at first, when expanding will begin to show the problems that seems to be the one with the greatest concern, but I gave several tips of what may be the way.