Code design

I'm trying to make better structured code, and I have this sort of love hate relationship with OO. Well mostly hate, but it's what I know so it's also what I use.

There's one problem I'm always coming back to and I've yet to solve; Is it ok to use classes to lump code? I know a hardcore old-schooler would scream no, but does it in any way hurt? Say I have this small operation which requires a state but I really don't want to pass it around as data and I shouldn't have more than one of it, do I make it a class or a module or whatever you'd call it?

Somehow it feels better to make it an object, perhaps mostly because again, it's what I'm used to. If the tiny system requires dynamic data, I can blame not deleting the object rather than not shutting down the system. If it's all static, then I still get the feeling that "here it is, right here!", if you know what I mean.. Actually if I make all the member variables and methods static, is there really any difference at all? So if it's not static, is there any difference other than that the state will be lumped as an object on the heap instead?

At the same time it hurts to think that there's an object out there.. which is simply not an object at all.

OP here, I know I made some thought error towards the end there, I was just thinking about my particular case. Of course the one object could also be statically allocated and thus not even reside on the heap.

just use structs

>>3
With all due respect, you're a fucking moron.

no, use namespaces

>>5
I'm aware of my options, thank you. Please try to justify your answer.

>>6
justify my anus

You're afraid of being locking in by static data and you shouldn't be. The problem is one of language features. If you could generalize on a type level without having to write loads of boilerplate code, you wouldn't even be thinking about this.

In the end, using a statically allocated class or singleton is no different from just using a namespace or plain C globals. As a much more hardware near guy, I don't really have the choice, since the only two languages that are useful on a microprocessor are C and ASM. If you want to make it a class, just avoid virtual methods, since those will create vtable lookups. You're not gaining anything though.

an important thing is to make sure you sanely scope your variables. for example, javascript offers an elegant way to do this:

(function () {
  var x = 10;
  (function () {
    var x = 20; // this does not modify the existing `x'
    (function () {
      var x = 30; // nor does this modify either of the previous two; you can keep on doing this as deep as you need
    })()
    // `x' will be 20 again
  })()
  // `x' will be 10 again
})()

>>9
C++ does it more elegantly though.


  int a = 30;

  []() {
    int a = 5;
    char wut[] = "wut";
    printf("%d\n%s\n", a, wut);
  }();

  //puts(wut); //error: not declared in this scope
  printf("outside: %d\n", a); //30

>>9
You have to use functions to nest scopes? Why is JavaScript so retarded?
{
  int x = 10;
  {
    int x = 20; // this does not modify the existing `x'
    {
      int x = 30; // nor does this modify either of the previous two; you can keep on doing this as deep as you need
    }
    // `x' will be 20 again
  }
  // `x' will be 10 again
}

>>9,11

Hell, even FFOC gets it right!

do
  local x = 10
  do
    local x = 20 -- this does not modify the existing `x'
    do
      local x = 30 -- nor does this modify either of the previous two; you can keep on doing this as deep as you need
    end
    -- `x' will be 20 again
  end
  -- `x' will be 10 again
end

OOP has little to offer outside GUI programming. I've seen perfectly good procedural code turned into absolute nightmare in an attempt to move towards OOP. It doesn't help that everyone's OOP concepts and implementations differ greatly. If you ask two developers on how to best tackle a problem using OOP, you'd get three different answers. The problem stems from OOP's proponents insistence on objectifying anything and everything. You will then end up with a kingdom-of-noun code base.

The truth of the matter is, business layers are made out of business rules and these rules can be perfectly modeled using functions, modules and basic data structures. There is absolutely no reason to use objects. In fact, it is counter-productive to express these rules and constraints using classes and objects. If you insist on using them, you will spend a lot of time just thinking about what to name your classes, what responsibilities they ought to have, what mechanism do they use to interact with each other and so on and so forth instead of just making a function/procedure and get it over with. You will then begin a slow but sure path to depression, fighting and cursing your tools instead of working with it. I could give you examples if you're interested.

>>13
-1 downgoated

  Tremendous Faggot
  163k •31 •320 •628
  100% accept rate

>>14 care to explain yourself? I think he's being reasonable

Objects are just black box abstractions with mutable state.

Some split code in small modules. Others split data in small structs. OO does both, if necessary.

Objects are good when you need more than one.

In degenerate cases like this, OOP doesn't give any benefits. Just do what works.

>>13
OOP has little to offer outside GUI programming.
Does it? I still have to find a simple, no-bullshit GUI library.

>>18
HTML+JS.  And I'm not even trolling.

>>13
examples would be appreciated.
Also clarification of "business rules" and how it relates to software. I think I've heard this term in one of the software engineering classes I took, but those were so fuzzy and weird that I didn't bother to learn much. I get a feeling it has mostly to do with dull in-house infrastructure blah for "large corporation X which normally has nothing to do with software" while I'm more interested in software which reaches out to people.

>>18
Gtk+ seems to work just fine, albeit it has some spurious "pixels of padding" type parameters everywhichplace.

>>19
i wish you were trolling but this is my recommendation too.

>>19,22
But that requires a huge, bloated VM ("web browser").

>>23
This might surprise you, but the overhead of loading a webpage (when others are open) is far smaller than that incurred by starting a separate GUI application.

>>23
They're gonna have a web browser open while running your product whether you make use of it or not.

>>24
This might surprise you, but the overhead of loading a Common Lisp program (when others are loaded) is far smaller than that incurred by starting a separate SEPPLES application.

>>26
>Implying people have Common Lisp programs loaded

>>26
Only if you load both programs inside the same virtual machine.  Otherwise, it's futile.

>>24,25
If you don't count the libraries, then a standard webpage requires far more resources (for example, it's written in HTML, which requires these slow, bloated parsers and complex internal representations), especially if the developer is trying to recreate the desktop application look.
Then there is JavaScript, which is horrendously slow even when JITted.
Also, what if the users don't have a web browser open? What if they have JS disabled? What if they want an actual, separate application?

>>29
What if all the users have is a pencil and paper?

>>30
What if the user doesn't understand THAC0?

>>31
Oh man what I wouldn't do for a THAC0 right now!

>>32
just go to your local THAC0 BH3LL

>>19,23,25,28-29
How do you communicate with a web page without starting up a server? Then there's that overhead.

>>34
The code runs in the web browser, dummy.

>>34
It's a lot less overhead than a standalone GUI app.

>>36
You're forgetting the browser itself is a ``GUI app''.

>>37
Certainly you aren't this stupid.

It's a lot less overhead than a standalone C++ framework-based GUI app.
FTFY

OVERHEAD MY ANUS