Your approach is putting an object of the domain model (i.e., an object that represents something of the problem that your application deals with, in the case of product sales) a behavior of reading keyboard data. It would be like putting code that saves this data in the database or code that displays this data on the screen. Although they are related, this is not where they should be, because they are not behaviors of what this object represents. In a larger project this would be potentially problematic for maintenance.
Besides, your Item
confuses the concepts of Produto
(due to the field nome
) and ItemDePedido
(due to the fields quantidade
and preco
).
I suggest you model a class Pedido
which has a list of objects in a class ItemDePedido
, this with fields quantidade
and preco
(beyond is clear of a field produto
which is not the name but a reference to an object of the class Produto
, this yes can have a field nome
-- although, see the end of the text).
Do this class ItemDePedido
have a method getSubtotal()
which returns the multiplication of these first two fields quantidade
and preco
.
That method getSubtotal()
is a specialized operation (liability) that objects ItemDePedido
are able to perform on their internal state (i.e., their fields). This is more object-oriented.
And finally in class Pedido
create a method getTotal()
who traverses the list by invoking each itemDePedido.getSubtotal()
and using to calculate the total order.
Another appropriate class responsibility Pedido
would be adicionar(ItemDePedido item)
.
It is thus clear that a request item must be built (i.e., have its fields initialized) by passing the values to these fields in the constructor already previously read from a keyboard reading done externally to that class.
By the way, this class Produto
(that represents an instance of product in stock) should not be confused with DescricaoDeProduto
, which represents the generic description of the product in the store, which has no quantity in stock and remains existing even if the products come out of stock. Maybe then a product should have a product description and it should have a name.
To go deeper, see "Using UML and Standards" (3rd edition), by Craig Larman.
P.S.: All of this can be ignored and done in ways that people have put in other responses. If it is object-oriented and brings the benefits that this approach proposes, that is another story (although in part what was proposed in them by being applied here). Remembering that in the simple case it may not seem so effective, but OO was made to deal with complexity. The code may become more complex in this case but at least it is not based on arbitrary modeling or "taken from the hat".