Is this a bad idea afterall, especially in a team environment?
I'd say it's at least a questionable practice that could lead to trouble, particularly in a team environment. Having worked this way for some time, you may have developed habits and understanding which avoid the potential trouble, but team members are likely not to understand your unwritten rules.
In particular, it seems like you're essentially practicing procedural programming in an object-oriented environment. The point of objects is that they contain both the data and the operations on that data. If you tell a view to draw(), for example, you don't need to tell it what to draw -- it should draw itself. If you have to tell it what to draw, you're not taking advantage of the power of OOP.
A danger of your approach is that your methods are operating not on the object's members, but on the parameters. If you pass those parameters by value, any changes to them won't be reflected in the corresponding member variables. You can solve that problem by passing by reference, but in that case your code might change member variables if that's what you pass in, but it's not obvious that that's what's happening. Worse, there's the very real possibility that the caller will pass in something other than a member variable, which really changes the meaning of what the method does.
Is it like redundant or confusing
- Redundant: definitely.
- Confusing: apparently not to you, but surely to others.
are there better ways?
Use member variables or properties instead of parameters in methods that are intended to operate on data stored within the object. Use parameters for information that's external to the object.
If you have trouble discerning which members a given method uses, try any of:
Put a comment near the beginning of the method that explains what the method does, lists the affected members, and perhaps describes any output.
Simplify your methods. I'm all for appropriate comments, but code is much nicer when you can scan the code quickly and get a pretty good idea of what's going on.
Stop worrying about it. A method should use whatever internal data it needs to do its job. Code outside the method should be more concerned with what the method does, not how it does it.