• Post Reply Bookmark Topic Watch Topic
  • New Topic

Class: It's all about functionality.  RSS feed

 
Sagar Dabas
Ranch Hand
Posts: 47
C++ Java PHP
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I heard : Classes are all about functionality.

But I used classes in my project for only data storage. This was the situation :

Data :
1. Subscriber -- Some attributes.
2. Newsletter -- Some attributes.
3. Group -- Some attributes.
4. Log -- Some attributes.
5. Settings -- Some attributes.

So I made classes for each and provided getter and setter functions. And for saving them I made the ArrayList of the objects of a particular type and serialized the ArrayList object.

This was the code for reading, creating and deleting the files :



By doing this my code was much shorter and flexible . Now I can add any other type if I want, ( for instance like Moderators ) without changing my present code.
I got the benefit of polymorphism too.

Do you think that was a bad decision ? Because my classes are not at all about functionalities.
Thanks
 
Campbell Ritchie
Marshal
Posts: 56581
172
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
You are right that classes encapsulate both data (attributes) and behaviour (functionality)/.
 
Sagar Dabas
Ranch Hand
Posts: 47
C++ Java PHP
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Campbell Ritchie wrote:You are right that classes encapsulate both data (attributes) and behaviour (functionality)/.


But I have only getter and setter functions as behaviour (for just accessing the data) and nothing else in those classes.
Do you think I have done it in a wrong way?
I was very proud when I came up to this solution but then I saw this statement : Classes are all about functionalities, you should not write classes without functionality.
 
Matthew Brown
Bartender
Posts: 4568
9
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
The question is, do you have any behaviour that is specific to those classes? The code you've shown is pretty simple - none of the classes need to have any behaviour beyond having attributes. So what you've done so far is fine. But what will you do when, for instance, there's some specific logic related to a Group?
 
Sagar Dabas
Ranch Hand
Posts: 47
C++ Java PHP
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Matthew Brown wrote:The question is, do you have any behaviour that is specific to those classes? The code you've shown is pretty simple - none of the classes need to have any behaviour beyond having attributes. So what you've done so far is fine. But what will you do when, for instance, there's some specific logic related to a Group?



Thanks to both of you for replying.

In the question it was not given that we have to use classes . I made this decision.

Actually the problem was just to store the data for subscribers, groups etc.

So I used classes for this purpose. But somewhere I have read that we should not write classes without functionalities ( may be it's an OO principle).

Am I violating the principle or Is this a bad design ? What would you suggest ?

Please reply and thanks again.
 
Matthew Brown
Bartender
Posts: 4568
9
  • Likes 2
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Well, I wouldn't say that all classes must have functionality. I'd personally say that was misleading. I often write classes that are as you describe - for example, Data Transfer Objects (where their only purpose is communication between different layers of an application). I think a more useful way to look at it is "all functionality should be in a class". Specifically, any functionality should be in the most appropriate class. That's the object-oriented approach.

Writing classes without functionality might be an indication that you're not following OO practices. But it might not - it depends what functionality is actually needed. Having it in the wrong place is the problem.
 
Jeff Verdegan
Bartender
Posts: 6109
6
Android IntelliJ IDE Java
  • Likes 2
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Sagar Dabas wrote:
In the question it was not given that we have to use classes . I made this decision.


Well, you can't write a Java program without at least one class.

Actually the problem was just to store the data for subscribers, groups etc.

So I used classes for this purpose. But somewhere I have read that we should not write classes without functionalities ( may be it's an OO principle).

Am I violating the principle or Is this a bad design ? What would you suggest ?


Just by having some classes that are nothing but data holders? No, that by itself is not a violation of OO and not inherently a wrong approach. But it's also impossible to say it's a correct approach. More context is needed for that, but most likely, for the scope and scale of your program, it could be reasonable, but it may depend on whether your instructor has set certain more specific requirements.

As for "we should not write classes without functionalities," that's only partly true, and, again, more context is needed.

One common mistake for beginners in OO0--whether they're brand new to programming or have programmed in other idioms previously--is that they tend to make a lot of classes that do nothing but hold data, and then a very small number of classes that do nothing but operate on the data in the other classes--often all inside one big main() or a big main() and a few other big, static methods in that class. This is what the "don't write a class without behavior" advice is about.

It's not that we should never have a class without behavior. Rather, if we find that most of our classes are just data holders, and most of the work is a separate "functional" piece of code that just operates on these classes' data, then we're not using OO for what it's meant for and good at. Some problems don't necessarily lend themselves well to rigidly sticking to OO principles, especially exercises in beginner level courses. However, whenever you find yourself writing code that gets some data out of an object, and then manipulates or operates on the data, you should be asking yourself, "Would it make more sense for the object that 'owns' this data to be doing this operation?
 
Sagar Dabas
Ranch Hand
Posts: 47
C++ Java PHP
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Matthew Brown wrote:Well, I wouldn't say that all classes must have functionality. I'd personally say that was misleading. I often write classes that are as you describe - for example, Data Transfer Objects (where their only purpose is communication between different layers of an application). I think a more useful way to look at it is "all functionality should be in a class". Specifically, any functionality should be in the most appropriate class. That's the object-oriented approach.

Writing classes without functionality might be an indication that you're not following OO practices. But it might not - it depends what functionality is actually needed. Having it in the wrong place is the problem.


Thanks Matthew Brown. The book must be emphasizing "proper functionality", not "without functionality". Thanks for clearing up my doubt.
 
Winston Gutkowski
Bartender
Posts: 10575
66
Eclipse IDE Hibernate Ubuntu
  • Likes 2
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Sagar Dabas wrote:In the question it was not given that we have to use classes . I made this decision.

Good decision. Java is an Object-Oriented langauge, so solutions usually work best when they're based on classes.

However, I agree with Matthew that what you've actually created are DTOs, rather than real-life Objects.

Take, for example, a Subscriber: In the real world there's likely to be a bunch of actual business logic related to something called a 'Subscriber'. For example:
1. Accounting.
2. A newsletter, sent on a regular basis.
3. Offers.
4. Preferences.
5. The things s/he "subscribes" to.
And none of your code does anything to tackle or regulate that stuff.

So, for what you needed, it sounds like you've come up with a decent solution (and well done for that); but DON'T expect that that's where it ends.....no sirree Bob.

One other point for you: resist the urge to simply bang out getters and setters for everything in your classes. It may seem like it gives you a lot of flexibility, but in fact it works against encapsulation - which is one of the cornerstones of OO - and tends to lead to procedural code. Personally, I blame the "Bean" mentality for them.

As a first stage, I'd say: get rid of your setters...or at the very least the ones you don't actually need. Setters (especially public ones) are inherently dangerous because they give anyone the right to change your object - not a good thing in our security-conscious post-911 world. I suspect you'll also find that many of your getters don't actually need to be public either.

For further reading, you might want to have a look at this article. Some of it may be a bit over your head at the moment, but the message is important:
1. Write code that reflects business requirements.
2. Don't write code for anything other than (1), even if it means foregoing "catch-all" solutions that look nice on the surface.
In my experience, it's the second of those that marks the master programmer from the merely adequate.

Another thing to think about: the best programmers I know spend most of their time off the computer. It's tough when you're learning and you're racing to get things done, but coding is actually a very small part of the programming life. Understanding is what's important.

HIH, and again, well done for what you got so far.

Winston


 
Sagar Dabas
Ranch Hand
Posts: 47
C++ Java PHP
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Jeff Verdegan wrote:

Just by having some classes that are nothing but data holders? No, that by itself is not a violation of OO and not inherently a wrong approach. But it's also impossible to say it's a correct approach. More context is needed for that, but most likely, for the scope and scale of your program, it could be reasonable, but it may depend on whether your instructor has set certain more specific requirements.

As for "we should not write classes without functionalities," that's only partly true, and, again, more context is needed.

One common mistake for beginners in OO0--whether they're brand new to programming or have programmed in other idioms previously--is that they tend to make a lot of classes that do nothing but hold data, and then a very small number of classes that do nothing but operate on the data in the other classes--often all inside one big main() or a big main() and a few other big, static methods in that class. This is what the "don't write a class without behavior" advice is about.

It's not that we should never have a class without behavior. Rather, if we find that most of our classes are just data holders, and most of the work is a separate "functional" piece of code that just operates on these classes' data, then we're not using OO for what it's meant for and good at. Some problems don't necessarily lend themselves well to rigidly sticking to OO principles, especially exercises in beginner level courses. However, whenever you find yourself writing code that gets some data out of an object, and then manipulates or operates on the data, you should be asking yourself, "Would it make more sense for the object that 'owns' this data to be doing this operation?


Thanks for the advice and explanation Jeff. Actually the project was quite big than this and it is just the data for the program.
 
Sagar Dabas
Ranch Hand
Posts: 47
C++ Java PHP
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Winston Gutkowski wrote:
Sagar Dabas wrote:In the question it was not given that we have to use classes . I made this decision.

Good decision. Java is an Object-Oriented langauge, so solutions usually work best when they're based on classes.

However, I agree with Matthew that what you've actually created are DTOs, rather than real-life Objects.

Take, for example, a Subscriber: In the real world there's likely to be a bunch of actual business logic related to something called a 'Subscriber'. For example:
1. Accounting.
2. A newsletter, sent on a regular basis.
3. Offers.
4. Preferences.
5. The things s/he "subscribes" to.
And none of your code does anything to tackle or regulate that stuff.

So, for what you needed, it sounds like you've come up with a decent solution (and well done for that); but DON'T expect that that's where it ends.....no sirree Bob.

One other point for you: resist the urge to simply bang out getters and setters for everything in your classes. It may seem like it gives you a lot of flexibility, but in fact it works against encapsulation - which is one of the cornerstones of OO - and tends to lead to procedural code. Personally, I blame the "Bean" mentality for them.

As a first stage, I'd say: get rid of your setters...or at the very least the ones you don't actually need. Setters (especially public ones) are inherently dangerous because they give anyone the right to change your object - not a good thing in our security-conscious post-911 world. I suspect you'll also find that many of your getters don't actually need to be public either.

For further reading, you might want to have a look at this article. Some of it may be a bit over your head at the moment, but the message is important:
1. Write code that reflects business requirements.
2. Don't write code for anything other than (1), even if it means foregoing "catch-all" solutions that look nice on the surface.
In my experience, it's the second of those that marks the master programmer from the merely adequate.

Another thing to think about: the best programmers I know spend most of their time off the computer. It's tough when you're learning and you're racing to get things done, but coding is actually a very small part of the programming life. Understanding is what's important.

HIH, and again, well done for what you got so far.

Winston





I think I should bookmark this thread.

EDIT : Hmmm...

Thanks again Everyone. Keep on posting .
 
Winston Gutkowski
Bartender
Posts: 10575
66
Eclipse IDE Hibernate Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Sagar Dabas wrote:Thanks again Everyone. Keep on posting .

<brazen point-touting>
If you like 'em, mark 'em up (just click the +1 icon on the post).
</brazen point-touting>

What do you think we do this for...our health?

Winston
 
Jeff Verdegan
Bartender
Posts: 6109
6
Android IntelliJ IDE Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Winston Gutkowski wrote:
What do you think we do this for...our health?


I do it because my parole officer says it counts toward my community service.

Of course, he also said that about giving him back-rubs.
 
Winston Gutkowski
Bartender
Posts: 10575
66
Eclipse IDE Hibernate Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Jeff Verdegan wrote:I do it because my parole officer says it counts toward my community service.
Of course, he also said that about giving him back-rubs.

Shiazu man, that's the thing. Get good, they show you how to do the Vulcan death-grip.

Winston
 
Sagar Dabas
Ranch Hand
Posts: 47
C++ Java PHP
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Winston Gutkowski wrote:
Sagar Dabas wrote:Thanks again Everyone. Keep on posting .


What do you think we do this for...our health?

Winston


No..... but for our health I know that you are a good person like Jeff or Matthew or Campbell or anyone on this forum.
 
Winston Gutkowski
Bartender
Posts: 10575
66
Eclipse IDE Hibernate Ubuntu
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Sagar Dabas wrote:No..... but for our health I know that you are a good person like Jeff or Matthew or Campbell or anyone on this forum.

I'm an old Systems Admin, and one of the first things I was taught by an old hand was:
There are two basic paradigms to security:
1. That which is not specifically denied is allowed.
2. That which is not specifically allowed is denied.

The first is difficult (very difficult), but will win you friends from all the people who are supposedly doing "harmless" things.
The second may well get you fired; and even if it doesn't, it won't win you any friends. But the system will be as secure as you can make it.

I'm an ornery cuss, so I chose the 2nd; and it's never proven me wrong yet. And I like to think that I program as I administer.

Keep it simple: don't give access to anything that you aren't forced to.

Winston
 
Aditya Jha
Ranch Hand
Posts: 227
Eclipse IDE Java Spring
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Although folks have given some effective replies on this thread, I would just put my 2 cents.

It is right to suspect that there is a potential OO loss when we are using classes with just attributes and classes with just behaviour. OO Guru, Martin Fowler, raises this question on the effectiveness of such a design in one of his books. If you think about it, it is quite similar to structures and functions (working on those structures) in C, respectively.

This gives rise to another style of design called "Domain Driven Design". By no means I'm qualified enough to explain the concept in a few lines, but I suggest you google it. It's definitely worth a read while delving into such a subject.
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!