Alright so I've learned this:

Classes have public methods that perform operations on the class's data and they hide away their implementations.

Data structures on the other hand, completely expose their implementation through properties (getters and setters) and don't usually have methods.

So my question is, let's say that I have customer data structure that looks like this:

public class Customer
   public string FirstName { get ; set; }
   public string LastName { get ; set; }
   public List<Offer> Offers { get ; set; }

I would assume this to be a data structure.

but what if later during the project, I realize that I need to add some business logic to my customer data structure?

Like a method to add new offers because there's more logic in doing so than just adding it to the list?

It seems to me that this logic would belong inside of the data structure.

What happens then? Does the data structure turn in to a class? Or into some kind of third object type that I'm unaware of?

Is this bad design?

| improve this question | | | | |
  • 6
    data structures are not what you think these are. Consider unlearning this and studying something that is less wrong instead - for example OOSC chapters 6 and 7, having solid explanation of relation between ADTs and classes – gnat Mar 18 '14 at 15:11

It is not bad design to add a method like that. This sort of thing's actually very normal when classes are in their infancy.

But classes and data structures are a little bit different than you think, and one doesn't really oppose or exclude the other at all. Most classes are data structures, and many data structures are classes. Classes have a lot more to do with the syntax of a language - they're programmed into a language directly - whereas datastructures have more to do with how you personally intend to use certain things. You tell a program what is and is not a class, but you do not generally tell a program what is and is not a data structure - you keep up with the latter yourself.

A class might involve methods - or it might not. It also might involve data - or it might not. Usually they'll involve both (especially in Java-style languages, where both are required), but this is not always true. You could even have a class with neither methods nor data.

Without getting into any of the details of OOP, a class is mostly just a collection of methods and/or data. And a class doesn't have to have public members, by the way. I've used some whose members were all either internal or private, for instance.

A data structure is a little different. It's basically a grouping of data that has been structured in some particular way for some particular purpose. This may be a class. Any time you see a class with more than one piece of data, that is generally a data structure.

Like a class, a data structure may either contain or forgo methods. Unlike a class, however, it must contain some form of data (even if the data's just a couple of "blank" variables).

You can have data structures that are not classes. For instance, imagine if you have two arrays: One is a list of people's first names, and one is a list of people's last names. And if the nth element of the first array is somebody's first name, then the nth element of the second array is that same person's last name. Even though the program and the programming language may have no idea these two arrays are connected, you do personally, just because you're keeping up with it. Even though this is not a good example of how you would usually want to set things up, this still constitutes a data structure.

I know that might have been a little long, but hopefully it'll help.

| improve this answer | | | | |
  • 4
    To give an example, a Tree data structure can be implemented using classes in Java, but in C, it would probably be implemented with arrays or maybe structs. – FrustratedWithFormsDesigner Mar 18 '14 at 15:31
  • This does help me understand, but shouldn't classes encapsulate as much of their implementation as possible? Wouldn't have having a great many getters or setters on a class "bad" ? – Darkalfx Mar 18 '14 at 16:19
  • They do need to encapsulate as much as reasonably possible. Especially in bigger classes, where most of your variables in a class are going to be specific to how that class works, not something that pertains to other classes. So just declare variables like that private and don't provide any getters or setters. This is still generally a data structure though, even if every variable is private and unexposed, as the class itself would still have access to all that data. – Panzercrisis Mar 18 '14 at 16:23
  • 1
    @Panzercrisis - So let's say in my example for the customer class above, what if I had about 10-15 properties on the object, plus all of the methods relating to the business logic of the customer. Is there ever a point where some of the public properties should maybe be split and put in a different class? Isn't a class having a crapton of properties AND methods for business logic doing too much? – Darkalfx Mar 18 '14 at 16:28
  • There's kind of a happy size for a class. Other than that, it's usually either too small or too large. Usually if it's too large, it does need to be broken into smaller classes, like you say. In the original example, there are two related variables: FirstName and LastName. There's an unrelated varialbe called Offers. So far if you try to break up this class into a couple of subclasses, it's overkill. But now if you add 15 more properties on top of it, it may or may not be overkill. If some of those properties are called Age, MiddleName, Birthdate, etc., you start to see a... – Panzercrisis Mar 18 '14 at 16:33

I would assume this to be a data structure.

Specifically, it's a record.

Like a method to add new offers because there's more logic in doing so than just adding it to the list?

Is there some important condition you need to maintain in your Offers list? e.g. It needs to stay sorted? If so, then giving the whole program free access to the list is bad. Either you turn Customer into an abstraction (a class or interface), or you turn Offers into one, but you have to control access to that list somehow. Which one should become the abstraction depends on the rest of the program and what you're trying to do.

If there's no such condition, you can simply add plan ol' functions that take the Customer record as its argument and do whatever things you need to do to it.

The bottom line is that not every user-defined type in your program is going to be an abstraction of something. Sometimes you do have plain old data objects. You do need some abstractions, and your data structures will often be used as the private members of some class, but they could also appear as arguments or return values of a class's methods, especially simple types like tuples or records.

| improve this answer | | | | |

Not the answer you're looking for? Browse other questions tagged or ask your own question.