Hi i have a question in java that i cant finde an answer in by google soo wanted to ask here.
If i have a Class (lets say Car) and a method(paintToBlack(stuff goes in))
And i need to “paintToBlack(stuff goes in)” lets say a million of cars ,should i add a method to a car?
Or
Should i create a Class “Painter” with a method “paintToBlack(stuff goes in)”
Then instantiate Painter painter = new Painter(Car car);
and use painter.paintToBlack(stuff goes in) For each car in list (lets say a million of “car” objects)
What will consume more PC ?
If a create a method in a Class will it increase object size ?
If i use to do in a second way i’m going into some hide roks? like i tranfer data each time soo consume more CPU ?
Object size is more about RAM ,while transfer data of "car"to “panter” is more about CPU…
Does this goes even or a quantity might justify one of solutions?
Why don’t you implement it and test it for a million cars and count the number of seconds it takes?
fyi: general java programming questions is discouraged in this forum. I suggest using Java in General Forum at JavaRanch
Either way makes no real difference. As far as adding a method goes, the JVM loads the bytecode for a class once. Every call to a method of that class goes to the same bytecode. It doesn’t matter if you have 1 instance of that class or 1 million instances, the memory used to store the class’s code is the same so it makes no difference where you declare the method to paint the car.
When you pass an object to a method, you’re not passing a copy of it you’re passing a reference to the same object. The car’s “data” is not being transferred to the painter, a reference to the car is being passed. Making a Car.paint() method takes exactly the same amount of memory and CPU as making a Painter.paintCar() method. Even if this were not true, the difference would be so tiny that it would make no practical difference which one you used. (Besides - this is a micro-micro-micro optimization. Don’t try to optimize unless you first have code that runs too slow and you profile it to identify the problem. Also, modern CPUs/RAM are so powerful that any differences of memory/CPU in code styles such as this would be immeasurably small.) Use whichever one fits your design best.
Creating a ‘Painter’ object for every car takes more time than directly calling a method in the ‘Car’ class. If i correctly understood your question, i think the first method is the best.
You could create an ‘Paintable’ interface and let ‘Car’ implement it, if you think you’ll need different types of object to be painted.
One could also argue that having a good starting point is better than fencing yourself in over time with bad ideas that you then can’t optimize when it starts to run slow as everything depends on it being exactly as it is. 
Thnx for your answers
This is definitely true. Starting from a good design is critical - without a good design you can forget about extending or optimizing it later, and you’ll lose tons of time debugging crappy code and hating your life.
I was recently working on the internals of a bytecode interpreter written in Java. After happily designing and coding up a new (and much cleaner) bytecode dispatch mechanism, I ran a simple benchmark with JMH. Much to my dismay, that benchmark took ~7.5 seconds to do the same task that a few other scripting languages I compared with took ~0.04 seconds to complete. Profiling this code showed that a horrendous amount of time was being spent in repeated reflective method lookups. Take 2 cached method lookup results, and the same benchmark ran in ~0.18 seconds (slower than the other scripting languages but in the ballpark at least). However, VisualVM showed nasty GC activity because I was allocating temporary arrays with each bytecode dispatch. Take 3 cached those arrays too, and now my interpreter runs quickly-ish and produces no extra garbage. Since the internals of the interpreter were cleanly designed, those changes were fairly quick and easy to put in place. Lesson learned: write clean and well-designed code that does its job well first, then benchmark, profile, and optimize the portions that yield unacceptable performance later. I had guessed where I thought it would have trouble when I re-wrote it, but after lots of time on this project and on the redesign I was still 0/2 on correctly predicting the performance hits.
This is true, but depending on what’s in the constructor of the hypothetical ‘Painter’ class the difference will only be a very small handful of nanoseconds. Java allocation for new objects is very, very, very fast (significantly faster than typical C/C++ malloc/new). I think that the ‘Painter’ class approach is likely to be a cleaner design in the long run, but I’d be quite surprised if performance was ever an issue (assuming ‘Painter’ doesn’t require any significant resources).