Class Coding Style -- Curiosity

Not for 'how-to' coding questions but PHP theory instead, this forum is here for those of us who wish to learn about design aspects of programming with PHP.

Moderator: General Moderators

Post Reply
User avatar
llanitedave
Forum Commoner
Posts: 78
Joined: Thu Jan 15, 2004 11:24 am
Location: Las Vegas, NV.

Class Coding Style -- Curiosity

Post 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.
User avatar
feyd
Neighborhood Spidermoddy
Posts: 31559
Joined: Mon Mar 29, 2004 3:24 pm
Location: Bothell, Washington, USA

Post 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.
User avatar
PrObLeM
Forum Contributor
Posts: 418
Joined: Sun Mar 07, 2004 2:30 pm
Location: Mesa, AZ
Contact:

Post 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!
User avatar
lazy_yogi
Forum Contributor
Posts: 243
Joined: Fri Jan 24, 2003 3:27 am

Re: Class Coding Style -- Curiosity

Post 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.
User avatar
Lord Sauron
Forum Commoner
Posts: 85
Joined: Tue Apr 20, 2004 5:53 am
Location: Tilburg, NL

Start with database design

Post 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
User avatar
lazy_yogi
Forum Contributor
Posts: 243
Joined: Fri Jan 24, 2003 3:27 am

Re: Start with database design

Post 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.
magicrobotmonkey
Forum Regular
Posts: 888
Joined: Sun Mar 21, 2004 1:09 pm
Location: Cambridge, MA

Post 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!
User avatar
Lord Sauron
Forum Commoner
Posts: 85
Joined: Tue Apr 20, 2004 5:53 am
Location: Tilburg, NL

Every programmer has his own ways

Post 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.
magicrobotmonkey
Forum Regular
Posts: 888
Joined: Sun Mar 21, 2004 1:09 pm
Location: Cambridge, MA

Post by magicrobotmonkey »

Yea, Sauron, thats a good point the diff between a library and a class... it makes your strictness make more sense
gymsmoke
Forum Newbie
Posts: 4
Joined: Wed May 19, 2004 12:20 pm
Location: Earth

Design

Post 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
fastfingertips
Forum Contributor
Posts: 242
Joined: Sun Dec 28, 2003 1:40 am
Contact:

Post 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.
Post Reply