Code/Interface Seperation

[Ryan Marcus]

Alright, I have a question for all you people who know what your doing...

... Do you believe in separating your code from your interface?

By this I mean a series of classes that make functions more and more specific.. As in a PacketSocket class to a RawData socket, to a bnetsocket, or a ShellSocket to a ShellFunctionClass. (When I say class, I mean a class. Not a fake VB module.) I do because I like reusing code, and I quickly make a change at the base of similar classes without changing each one...

Others argue that coding "right in the UI" is easier, faster, and better because you can customize your code... I would rather have a "Whisper" event then have to parse the packet right there in the UI..


Thoughts? Comments? Ideas? Questions? Sandwiches?

[Sidoh]

Alright, I have a question for all you people who know what your doing...

... Do you believe in separating your code from your interface?

By this I mean a series of classes that make functions more and more specific.. As in a PacketSocket class to a RawData socket, to a bnetsocket, or a ShellSocket to a ShellFunctionClass. (When I say class, I mean a class. Not a fake VB module.) I do because I like reusing code, and I quickly make a change at the base of similar classes without changing each one...

Others argue that coding "right in the UI" is easier, faster, and better because you can customize your code... I would rather have a "Whisper" event then have to parse the packet right there in the UI..

Organization is Godly.

Sandwiches?

Great idea!  I'll be back in a few minutes.

[rabbit]

VB has classes.  Don't assume things.

[Ryan Marcus]

I knew that... I met that using modules did not count as separation.

[MyndFyre]

VB has classes.  Don't assume things.

VB has classes, but not class, and is not object-oriented.

[Warrior]

Alright, I have a question for all you people who know what your doing...

... Do you believe in separating your code from your interface?

By this I mean a series of classes that make functions more and more specific.. As in a PacketSocket class to a RawData socket, to a bnetsocket, or a ShellSocket to a ShellFunctionClass. (When I say class, I mean a class. Not a fake VB module.) I do because I like reusing code, and I quickly make a change at the base of similar classes without changing each one...

Others argue that coding "right in the UI" is easier, faster, and better because you can customize your code... I would rather have a "Whisper" event then have to parse the packet right there in the UI..


Thoughts? Comments? Ideas? Questions? Sandwiches?

Well coding (in VB) I seperate all code which is reuseable into a class module and static code as in code that does things that need no abstraction (like conversions, and other simple things) go in regular modules.

Now in PHP I make all of my bulk functions in a single file or if I'm programming OOP I make them a bunch of classes which extend the core. To display the UI it would pass through the template handler then the feed from each page which would then write to the page itself.

[Sidoh]

x86] link=topic=3024.msg29404#msg29404 date=1127573826]
Now in PHP I make all of my bulk functions in a single file or if I'm programming OOP I make them a bunch of classes which extend the core. To display the UI it would pass through the template handler then the feed from each page which would then write to the page itself.

That's a rather common technique.

[iago]

Separating interface and processing is one of the basic things you learn that you have to do if you want to program anything that's a reasonable size.  Visual Basic is very hard to do that in, it greatly encourages mixing up interface/processing. 

When you program a project, think about this: if you wanted to change it to a console interface, or remote interface, or a different graphical interface, how much code would you be replacing? If you would have to replace code that has nothing to do with the interface, then you have a problem. 

[Ryan Marcus]

Separating interface and processing is one of the basic things you learn that you have to do if you want to program anything that's a reasonable size.  Visual Basic is very hard to do that in, it greatly encourages mixing up interface/processing. 

When you program a project, think about this: if you wanted to change it to a console interface, or remote interface, or a different graphical interface, how much code would you be replacing? If you would have to replace code that has nothing to do with the interface, then you have a problem. 

Amen.

[Warrior]

Exactly, having all of the essential code wrapped around other functions which the UI can call fourth would make switching whatever UI you use a snap. :)

[Tuberload]

And Object Oriented Programming was born.

[Warrior]

Hello world.

[Ryan Marcus]

Neither my tech teacher or I think that putting code into a module counts as UI separation.

It really ticks me off when I look at converted VB source code and they have all of there controls (PushButtons, Sockets, etc.) "forward" to a module, and then that module calls that socket DIRECTLY.

I was talking to the guy that wrote MikeBot, first complaining that there where swear words in his comments, and we started discussing programming. His idea of UI and code separation was to have modules do all the "processing".

NO NO NO NO!

Correct me if I am wrong, but to correct way to do things involves a class hierarchy. For example, you would have a class called PacketSocket, which would use other classes such as PacketBuilder and PacketBuffer to pass a packet in an event. Then, you could create 2 sub-classes, rawbnetsocket, and rawbnlssocket. There, you handle all the connection information. For example, in the BNLS socket, you would have a method called "SendCDKey" which would trigger an event that included (or just returned) the hashed CDKey. Then you could sub-class rawbnetsocket to have methods such as Whisper, SayText, etc.

So many people use the module method, I figure there has got to be a reason, but I just can't find one!

[Warrior]

Exactly. Have a core bot class which then invokes independant socket classes and stuff.

[rabbit]

In my most recent bot (not released or even working quite yet), I've gone through painful lengths to class just about everything.  I even control the form from a main class.  I've broken it down a lot farther than I ever have, but I doubt I will even finish this thing.