classes, true purpose of

If variables store current state and methods implement behaviour and classes are basically a collections of methods grouped logically together ... i wonder how to better structure my classes content.

Say job is to take a look at 'n' files, read them into memory, do something and make a report - knowing that i will have to be reading more and more files in the future for other purposes, should i be placing method that actually reads a file and returns its contents into it's own utils.java class in my own com.mac.utils package so i can import it later into the main one?

In the industry, is this how things are done, or perhaps, you just make a local copy of that utils java and place it into the main package? To dwell more on this example a little bit - i don't know what type of return data my later code will need, so some overloading may be in order.

Am i thinking in the right direction? Please advise

Let me add that my current role in the organization has to do with supporting a large number of distributed applications. What this means is that master collection of tools is set to grow substantially over time. This means reusability is a must. And that begs the question, what should be reused? Should i concern myself with making a collection of reusable classes in my group's package com.group.utils?

Thanks for reading,
mac

Quote:

---

Originally Posted by mac

If variables store current state and methods implement behaviour and classes are basically a collections of methods grouped logically together ... i wonder how to better structure my classes content.

Say job is to take a look at 'n' files, read them into memory, do something and make a report - knowing that i will have to be reading more and more files in the future for other purposes, should i be placing method that actually reads a file and returns its contents into it's own utils.java class in my own com.mac.utils package so i can import it later into the main one?

In the industry, is this how things are done, or perhaps, you just make a local copy of that utils java and place it into the main package? To dwell more on this example a little bit - i don't know what type of return data my later code will need, so some overloading may be in order.

Am i thinking in the right direction? Please advise

---

You're halfway there; there is an important 'rule of thumb' that says 'code to the interface, not to the implementation'. To accomplish that task design interfaces first and try to make them 'fit' your use cases; just define what needs to be done, not how they should do it (of course you can keep that in the back of your mind but don't let it influence your interface design).

Next, if you're certain that implementations of those interfaces can do the job, implement the classes. If an interface A depends on an interface B make an implementation of A depend on interface B, not an implementation thereof.

Don't make your interfaces too general or you'll end up with implementations of that interface that can be best described as 'God classes' or 'Swiss Army knifes'. You don't want to maintain those molochs.

But first of all: practice and study because designing interfaces is something that swings you back and forth between generalizations for the sake of it to the need to get something implemented. Finding a balance between those two opposing forces is the thin line you have to walk.

kind regards,

Jos