Page 1 of 1
Class Coding Style -- Curiosity
Posted: Wed Apr 21, 2004 9:02 pm
by llanitedave
This is for those who are comfortable with putting together classes and objects. I'm just dipping my feet into putting a major class together, rewriting a login script as a Session_control class.
What kind of approach do you use when beginning the design of a functional class? Do you design the class structure and insert functions into it, or do you build the individual functions and wrap them together into a class structure?
Does it make a difference if you're building it from scratch or reworking existing code?
I'm looking for wisdom and perspective, neither of which I have of my own just yet.
Posted: Wed Apr 21, 2004 10:47 pm
by feyd
This comes from several years of game programming, so possible grain of salt involved...
I work out what I need the class to do. It should do one thing. If there's a shred of a possibility of using it again somewhere, design it in a generic fashion. Use inheritance to build specialized versions for specific tasks. Interfaces are built over any API.
Posted: Wed Apr 21, 2004 10:48 pm
by PrObLeM
I generally start from scratch and what i do 1st is write a skeleton code of the class
exactly like this
Code: Select all
class db
{
function db()
{
//constructor
}
function Query()
{
//Query code here
}
}
Then i just start making the funcitons then test and bam...done!
Re: Class Coding Style -- Curiosity
Posted: Thu Apr 22, 2004 1:32 am
by lazy_yogi
llanitedave wrote:I'm just dipping my feet into putting a major class together, rewriting a login script as a Session_control class.
As said, its better to make a class
1. simple and do just one thing
2. do it well with no errors
3. make a nice interface so its easy to be used by other objects
an object is composed of datatypes, some of which are ints, strings, floats, and some of which are user defined types (ie other classes)
So you could have your main class which has user defined datatypes (ie other instantiated classes/objects) that it delegates the work off to.
So, my point is, don't make one "major" class as you put it, make a group of small ones that each follow all 3 rules above, and interact well together to perform tasks.
Start with database design
Posted: Thu Apr 22, 2004 2:03 am
by Lord Sauron
Hi there,
In fact it is even easier. I generally start with database design by means of an object model. Every object in the object model is a class file in your source code. In fact I never make an exception. If you need an extra class, your object model is wrong. If there is a class file, which you don't use, your object model is wrong.
This is absolutely the easiest and best way to decide, what class files you need. Every class file contains one object, containing all the attributes of the database table coresponding with the class file. Every attribute has one get and one set method (=function). And finally the class file contains one load and one save method for reading and writing the object.
Like I said. If this doesn't work, it's time to go back to the drawing board.
Antonie
Re: Start with database design
Posted: Thu Apr 22, 2004 4:51 am
by lazy_yogi
Lord Sauron wrote:Hi there,
In fact it is even easier. I generally start with database design by means of an object model. Every object in the object model is a class file in your source code. In fact I never make an exception. If you need an extra class, your object model is wrong. If there is a class file, which you don't use, your object model is wrong.
This is absolutely the easiest and best way to decide, what class files you need. Every class file contains one object, containing all the attributes of the database table coresponding with the class file. Every attribute has one get and one set method (=function). And finally the class file contains one load and one save method for reading and writing the object.
Like I said. If this doesn't work, it's time to go back to the drawing board.
Antonie
That's not correct.
What if you need a clandar for appointments, then you'd make a calendar or date class. Also there are MANY applications that do not use databasees at all. As a general rule, I have a class object and a classDB for each table in the database, but always have some extra to make the other jobs simpler, such as exception class, db classes, validation classes, etc.. as well as application specific classes such as the date class example.
Posted: Thu Apr 22, 2004 6:13 am
by magicrobotmonkey
Yea, I think Lord Sauron's being a little strict with his classes....
But I like what Problem said, and that's how I usually go about it. Start with the basic framework (constructor, mutators, accessors, etc..) and build on that, building functions as you need. I usually don't plan ahead a lot, even adding variables to the class as needed, just making sure to document well as I go.
I like it when I start with a basic idea and the class grows in my head to a beautiful functioning class that does everything I need!
Every programmer has his own ways
Posted: Thu Apr 22, 2004 7:29 am
by Lord Sauron
Off course every programmer does it his own way. This is the way I do it.
For example the calander. Yeah, off course I use a class file for a calander, but I will have a database table called calandar as well. Files for validation, session and database connection are no class files, but library files. That's a big difference.
So maybe I'm a little strict, but I wrote some big applications, and I never had any structure problems, because I have always been following my object model.
Posted: Thu Apr 22, 2004 7:47 am
by magicrobotmonkey
Yea, Sauron, thats a good point the diff between a library and a class... it makes your strictness make more sense
Design
Posted: Wed May 19, 2004 12:20 pm
by gymsmoke
Coming from a data architects background, I agree with Sauron. I would start with an object model, and, by division, functionally decompose to it's lowest common denominators. That usually gives you a visual of both top and bottom. Beyond that, I try to implement a form of normalization into the mix, so that a balance of functionality is created. Beyond that, scope has always presented some small problems for me in application design. That's one area that better minds than mine have assisted me in the past.
Gymsmoke
Posted: Thu May 20, 2004 9:25 am
by fastfingertips
I'm using different methods for different SQL instructions (SELECT,UPDATE,INSERT,DELETE) because in this way i can have a high level of customisation of properties returned.
I saw that many people is using sometimes to many classes (this generates a very fragmented structure and often is harder to use). I think that the answer is somewere in the middle zone.