Ye' old general discussion board. Basically, for everything that isn't covered elsewhere. Come here to shoot the breeze, shoot your mouth off, or whatever suits your fancy. This forum is not for asking programming related questions.
diG1tY wrote:When would it be appropriate to use classes and objects?
Always
Also I disagree with this, it would be inappropriate if the entire program was shorter than 10 lines and was never going to be maintained. It would also be inappropriate for implementing low level algorithms, close to machine code, or in environments where the overhead of using the syntax outweighs it's benefits.
And also yeah I guess theres no difference in adding data to behavior or visa versa. The key point is you very rarely have a class that is just data, or just behavior.
jshpro2 wrote:Also I disagree with this, it would be inappropriate if the entire program was shorter than 10 lines and was never going to be maintained.
There is no such thing as code that is never going to be maintained. Even if you said code that is never going to be used, then I still would not agree because you could learn while you were designing and coding. You forget that you learn every time you code.
jshpro2 wrote:It would also be inappropriate for implementing low level algorithms, close to machine code, or in environments where the overhead of using the syntax outweighs it's benefits.
I assume that we are talking about PHP here. In situations where performance is the major criteria then you may want to choose a compiler that produces the fastest code. That still may not preclude OO -- for example the increasing use of Python as a systems language.
jshpro2 wrote:And also yeah I guess theres no difference in adding data to behavior or visa versa. The key point is you very rarely have a class that is just data, or just behavior.
I think there is a huge difference between thinking of programs as DATA+code instead of as CODE+data. It is one of the most important concepts in software development.
There is no such thing as code that is never going to be maintained. Even if you said code that is never going to be used, then I still would not agree because you could learn while you were designing and coding. You forget that you learn every time you code.
Procedural code can be maintained and maintained well, let's not get too extreme. You can also learn a thing or two designing a maintainable program without the comfort of OO design.
OO programming is a very useful methodology as I know you are both aware of. I still hold the opinion that complete beginners (as the OP claims to be) should get familiar with the basics of structured programming before jumping into OOP, design patterns and higher level concepts. You need a learning curve for programming like anything else.
pytrin wrote:I still hold the opinion that complete beginners (as the OP claims to be) should get familiar with the basics of structured programming before jumping into OOP, design patterns and higher level concepts. You need a learning curve for programming like anything else.
I'm not sure it's true. I started programming with Procedural Programming and when the moment of going to OOP had come I had many difficulties to understand why I should use it. I can remember some of my arguments (C/C++):
- an object is simply a structure with function pointers;
- methods are just functions with "this" always passed as an argument to them;
- my "methods" in my structure are always virtual - one can always assign a new pointer to a function in a instance;
- .... etc.
OOP and PP have too different approaches for solving a problem (the whole one, not just parts of it).
There are 10 types of people in this world, those who understand binary and those who don't
Could you elaborate what that difference is? Or at least clarify what you mean? When I think of data I think of properties, code I think of methods. In a well designed system almost every class should have both, are these concepts not transitive? Isn't it a dichotomy? whats it matter what I call it ( data+ code or code + data? )
josh wrote:Could you elaborate what that difference is? Or at least clarify what you mean? When I think of data I think of properties, code I think of methods. In a well designed system almost every class should have both, are these concepts not transitive? Isn't it a dichotomy? whats it matter what I call it ( data+ code or code + data? )
I think there is a huge difference conceptually. Perhaps I should have written it DATA->code and CODE(data). Most important is to think of the Domain Model first when approaching a software problem. But there are so many bad practices that naturally flow from thinking code first. The questions you hear from procedural, often self-taught, programmers often give me the impression that they really don't understand the problem. They are just applying little code patches here an there to the data as it comes to them. The evolution that happens is that they unlearn those bad habits and learn methodologies that open up the Domain to them.
I would almost say that you should learn patterns and data modeling first with a skilled programmer entering the code for you so you can see the results. Once you start to understand the way of the data then you can touch the keyboard.
I don't think data is the right word - maybe domain of the problem.
The logic used in application I would say is more important than the data itself - it defines the domain area. The specifics of the data are less interesting than the processes and logic that drives the application. Logic in software manifests itself as code. So I'm not really seeing your point...
We agree that "the data are less interesting than the processes and logic that drives the application." But I think the data is more important. It is there before the code runs and it there after the code ends. The data is the point. Applications are just convenient data viewers. Though you do express the problem for me. Programmers are attracted to the interesting part, which in my opinion is the less important part.
Again I have to disagree. The logic / code defines the type of data it handles (more specifically in OO - using classes), which is much more relevant to us as developers than any specific data. Does it really matter if that user object has a name proerty = 'John'? I think that defining a name property as data structure is more important than the data itself. Ideally, we would like our logic to handle all instances of the same type the same - isn't that what we are striving for? encapsulation and code reuse? going to more abstract structures instead of concrete implementations?
Applications are not data viewers, but active participators. The data is manipulated, transformed, requested, persisted and more. It is our role as developers to build the structure that handles that data. The data itself is the client / end-user responsibility.
I would also argue that the problem and the solutions are the important part as well as the interesting part. Isn't that what software development is all about? isn't that what we get paid to do? there are specific positions that handle data (you can call them managers, content creators, etc), but those are not us.
When I said data I did not really mean only specific values.
You say we are paid for the code. I say we are paid for the user experience and the accounting department being able to bill credit cards. I think we just disagree on this.
Thanks for clarifying. We are both saying the same thing I think. Objects allow you to bind code with your data, instead of passing data to the code. Saying object's properties are "like" global variables with scope wouldn't please most seasoned developers, but would be a crude way for a beginner to grasp one of the design problems OO solves.
We are paid for the code. Plain and simple. We won't be paid for long for the code if it doesn't complete the requirements it was commissioned for.
I also don't know another way to accomplish the things you said without code...