Quantcast

Jump to content

» «
Photo

Too much worried about OO design

12 replies to this topic
Swoorup
  • Swoorup

    innovator

  • Feroci
  • Joined: 28 Oct 2008
  • Nepal

#1

Posted 15 January 2013 - 03:41 AM

Recently I had just learnt C++. I come from a procedural oriented programming background. I do know the structure and methodologies of C++.

The thing is that, whenever I'd try to make an program with an Object Oriented Design, I always fail to do so. I find myself worrying too much about classes, class name, member names and what member function to be kept rather than writing the actual code itself.

Even if I managed to write a class, in the end I'd not be happy with the way I designed it, and would simply try to rewrite it. This has lead to be become frustated easily writing anything in C++ because I would think of it as a bad design. I wonder how do the otherr guys do it? Why is OOP that hard to understand? O.o

SagaciousKJB
  • SagaciousKJB

    Captain tl;dr

  • The Connection
  • Joined: 21 Jun 2003

#2

Posted 15 January 2013 - 08:12 AM

I don't know, I wondered the same thing when taking a C++ class after mucking around with C already. The OO nature of things seems a bit abstract to me, having way more to do with the concept of how to write a program than the syntax or technical aspects of the code. I never really got the point of why OO programming was supposed to be more favored because it never really seemed to be that much more clear to me. I think the bigger part of it is just that it lends itself to modular designs and additions better than a procedural style does, but in my limited experience I never write anything complex enough to even need to be that modular. On the other hand I can see why it would be more favorable for large projects and especially open-source ones where keeping it open-ended and easy for individuals to modify and contribute to is a key goal.

OzzySM12
  • OzzySM12

    Hmm...

  • Members
  • Joined: 07 Nov 2004

#3

Posted 15 January 2013 - 12:42 PM

Design.

I know you probably hear people banging on about it, but simply scribbling out a rough design can really save you a lot of those problems.

If it is more than a simple script, you really have to do some sort of design before you start coding otherwise you will get so far a realize you have to or want to rewrite the whole thing.

I work with a number of large projects (mainly in PHP these days but still the same idea) and object orientated design is better. But if you don't take the time to do a quick design so you know all the requirements, you will end giving up when you hit a bit you did not consider.

Swoorup
  • Swoorup

    innovator

  • Feroci
  • Joined: 28 Oct 2008
  • Nepal

#4

Posted 15 January 2013 - 02:28 PM

I do design them. I don't know how much time should I be spending on designing though. My time spent designing is more than writing the actual code itself. But however later I feel uncomfortable with my own design later on, and would always want to start again from scratch.

I don't know but I feel that my design are always not even up to a bit of proper standard form.

However, the problem may have been arising due to the fact that I have not well known with the fact of what I am learning now(OpenGL). I am learning OPenGL at the moment and I am trying to code what I have learnt in OOP based design. What do you reckon of how should I solve my design issues, when I am learning things?

Rawra
  • Rawra

    Daedric Prince of Madness

  • Members
  • Joined: 06 Aug 2007

#5

Posted 17 January 2013 - 04:09 PM

I'll throw in my opinion, for whatever it's worth.

I would say not to worry about OO design and do it however you feel is best. I never use C++ and stick with C as I find C++ too cluttered for my own projects whereas C is a lot simpler and nicer to work with. Several times I wrote some projects in C++ and ended up re-writing them all in C due to finding all of the C++ things (private/class/etc) serving to purpose to me.

I used directX with C and it was a bit of a bitch to compile with but I now have had no problems with it.

So really, just do what you feel comfortable with and don't force yourself to do something (unless you have to)

K^2
  • K^2

    Vidi Vici Veni

  • Moderator
  • Joined: 14 Apr 2004
  • United-States
  • Most Knowledgeable [Web Development/Programming] 2013
    Most Knowledgeable [GTA Series] 2011
    Best Debater 2010

#6

Posted 18 January 2013 - 04:56 AM

Rawra, I'm guessing you've never worked on large projects. OO is pretty much a must if you are putting together a game engine, or something of similar scale. Resource management alone is a complete nightmare without it.

Swoorup, it basically comes down to practice. Don't try to force yourself to use object oriented programming. Write code in C++, but feel free to make as much of it as you feel is natural in C. If you feel that, "Hey, it'd be neat to handle this with a class," write one up. Don't worry about it being perfect. It's ok if you'll end up doing so sloppily. Just try to make it work. Odds are, in retrospect, you'll see a better way to have handled a specific aspect of it, and that's how you learn.

Barguast
  • Barguast

    Thy next foe is...

  • Andolini Mafia Family
  • Joined: 27 Jul 2002

#7

Posted 18 January 2013 - 01:20 PM

The thing about objects is that you can relate them to real-world objects. You can start thinking about things in terms of 'what is this thing', 'what does this thing need to do'. The key is keeping things simple (KISS) and know what your class needs to do, what it shouldn't be doing, etc. This is of course possible in modular, procedural programming, but object orientation encourages you to do so, and provides a good way to encapsulate functionality and conceptualise ideas.

I suspect you're just used to procedural programming and will grow to like OO as you use it more and more. As others have said, design is an important stage which if skipped will turn an OO project into a horrible mess.

Rawra
  • Rawra

    Daedric Prince of Madness

  • Members
  • Joined: 06 Aug 2007

#8

Posted 18 January 2013 - 03:10 PM

Hi K^2: Nope I haven't worked on big projects - largest of mine was a basic 3D Modeler at around 5k lines. I have heard that OO is very useful for large projects however

Gangsta-NL
  • Gangsta-NL

    Street Cat

  • Members
  • Joined: 10 Aug 2008

#9

Posted 20 January 2013 - 02:27 PM

Object oriented programming is a great way for developing, modifying and understanding code. Especially mid to large projects should be written in object oriented.

I have been in a large web development project which did not use this programming paradigism. It was hard to fix errors, change things in the website and also understand the code. Small bugs were harder to solve.

Always go for OOP!

The only way to understand OOP is by actually practising it. Making mistakes and learn from them. Look at well known (good written) open source code which uses OOP and learn from it.

Swoorup
  • Swoorup

    innovator

  • Feroci
  • Joined: 28 Oct 2008
  • Nepal

#10

Posted 24 January 2013 - 02:15 PM

Hey guys, whats up again.

ATM I am learning OpenGL and I would like to turn the code into object-oriented design. From what I know, it is often stressed that objects can be related to real-world and thats what I am trying to do now. I was wondering what you guys would come up with, if you were to turn the following code into object-oriented design.

CODE

//Copyright (C) 2010-2012 by Jason L. McKesson
//This file is licensed under the MIT License.



#include <algorithm>
#include <string>
#include <vector>
#include <stdio.h>
#include <glload/gl_3_2_comp.h>
#include <GL/freeglut.h>


GLuint CreateShader(GLenum eShaderType, const std::string &strShaderFile)
{
GLuint shader = glCreateShader(eShaderType);
const char *strFileData = strShaderFile.c_str();
glShaderSource(shader, 1, &strFileData, NULL);

glCompileShader(shader);

GLint status;
glGetShaderiv(shader, GL_COMPILE_STATUS, &status);
if (status == GL_FALSE)
{
 GLint infoLogLength;
 glGetShaderiv(shader, GL_INFO_LOG_LENGTH, &infoLogLength);

 GLchar *strInfoLog = new GLchar[infoLogLength + 1];
 glGetShaderInfoLog(shader, infoLogLength, NULL, strInfoLog);

 const char *strShaderType = NULL;
 switch(eShaderType)
 {
 case GL_VERTEX_SHADER: strShaderType = "vertex"; break;
 case GL_GEOMETRY_SHADER: strShaderType = "geometry"; break;
 case GL_FRAGMENT_SHADER: strShaderType = "fragment"; break;
 }

 fprintf(stderr, "Compile failure in %s shader:\n%s\n", strShaderType, strInfoLog);
 delete[] strInfoLog;
}

return shader;
}

GLuint CreateProgram(const std::vector<GLuint> &shaderList)
{
GLuint program = glCreateProgram();

for(size_t iLoop = 0; iLoop < shaderList.size(); iLoop++)
 glAttachShader(program, shaderList[iLoop]);

glLinkProgram(program);

GLint status;
glGetProgramiv (program, GL_LINK_STATUS, &status);
if (status == GL_FALSE)
{
 GLint infoLogLength;
 glGetProgramiv(program, GL_INFO_LOG_LENGTH, &infoLogLength);

 GLchar *strInfoLog = new GLchar[infoLogLength + 1];
 glGetProgramInfoLog(program, infoLogLength, NULL, strInfoLog);
 fprintf(stderr, "Linker failure: %s\n", strInfoLog);
 delete[] strInfoLog;
}

for(size_t iLoop = 0; iLoop < shaderList.size(); iLoop++)
 glDetachShader(program, shaderList[iLoop]);

return program;
}

GLuint theProgram;

const std::string strVertexShader(
"#version 330\n"
"layout(location = 0) in vec4 position;\n"
"void main()\n"
"{\n"
"   gl_Position = position;\n"
"}\n"
);

const std::string strFragmentShader(
"#version 330\n"
"out vec4 outputColor;\n"
"void main()\n"
"{\n"
"   outputColor = vec4(1.0f, 1.0f, 1.0f, 1.0f);\n"
"}\n"
);

void InitializeProgram()
{
std::vector<GLuint> shaderList;

shaderList.push_back(CreateShader(GL_VERTEX_SHADER, strVertexShader));
shaderList.push_back(CreateShader(GL_FRAGMENT_SHADER, strFragmentShader));

theProgram = CreateProgram(shaderList);

std::for_each(shaderList.begin(), shaderList.end(), glDeleteShader);
}

const float vertexPositions[] = {
0.75f, 0.75f, 0.0f, 1.0f,
0.75f, -0.75f, 0.0f, 1.0f,
-0.75f, -0.75f, 0.0f, 1.0f,
};

GLuint positionBufferObject;
GLuint vao;


void InitializeVertexBuffer()
{
glGenBuffers(1, &positionBufferObject);

glBindBuffer(GL_ARRAY_BUFFER, positionBufferObject);
glBufferData(GL_ARRAY_BUFFER, sizeof(vertexPositions), vertexPositions, GL_STATIC_DRAW);
glBindBuffer(GL_ARRAY_BUFFER, 0);
}

//Called after the window and OpenGL are initialized. Called exactly once, before the main loop.
void init()
{
InitializeProgram();
InitializeVertexBuffer();

glGenVertexArrays(1, &vao);
glBindVertexArray(vao);
}

//Called to update the display.
//You should call glutSwapBuffers after all of your rendering to display what you rendered.
//If you need continuous updates of the screen, call glutPostRedisplay() at the end of the function.
void display()
{
glClearColor(0.0f, 0.0f, 0.0f, 0.0f);
glClear(GL_COLOR_BUFFER_BIT);

glUseProgram(theProgram);

glBindBuffer(GL_ARRAY_BUFFER, positionBufferObject);
glEnableVertexAttribArray(0);
glVertexAttribPointer(0, 4, GL_FLOAT, GL_FALSE, 0, 0);

glDrawArrays(GL_TRIANGLES, 0, 3);

glDisableVertexAttribArray(0);
glUseProgram(0);

glutSwapBuffers();
}

//Called whenever the window is resized. The new window size is given, in pixels.
//This is an opportunity to call glViewport or glScissor to keep up with the change in size.
void reshape (int w, int h)
{
glViewport(0, 0, (GLsizei) w, (GLsizei) h);
}

//Called whenever a key on the keyboard was pressed.
//The key is given by the ''key'' parameter, which is in ASCII.
//It's often a good idea to have the escape key (ASCII value 27) call glutLeaveMainLoop() to
//exit the program.
void keyboard(unsigned char key, int x, int y)
{
switch (key)
{
  case 27:
   glutLeaveMainLoop();
   return;
}
}


unsigned int defaults(unsigned int displayMode, int &width, int &height) {return displayMode;}

int main(int argc, char** argv)
{
glutInit(&argc, argv);

int width = 500;
int height = 500;
unsigned int displayMode = GLUT_DOUBLE | GLUT_ALPHA | GLUT_DEPTH | GLUT_STENCIL;
displayMode = defaults(displayMode, width, height);

glutInitDisplayMode (displayMode);
glutInitContextVersion (3, 3);
glutInitContextProfile(GLUT_CORE_PROFILE);
#ifdef DEBUG
glutInitContextFlags(GLUT_DEBUG);
#endif
glutInitWindowSize (width, height);
glutInitWindowPosition (300, 200);
int window = glutCreateWindow (argv[0]);

glload::LoadFunctions();

glutSetOption(GLUT_ACTION_ON_WINDOW_CLOSE, GLUT_ACTION_CONTINUE_EXECUTION);

if(!glload::IsVersionGEQ(3, 3))
{
 printf("Your OpenGL version is %i, %i. You must have at least OpenGL 3.3 to run this tutorial.\n",
  glload::GetMajorVersion(), glload::GetMinorVersion());
 glutDestroyWindow(window);
 return 0;
}

if(glext_ARB_debug_output)
{
 glEnable(GL_DEBUG_OUTPUT_SYNCHRONOUS_ARB);
 glDebugMessageCallbackARB(DebugFunc, (void*)15);
}

init();

glutDisplayFunc(display);
glutReshapeFunc(reshape);
glutKeyboardFunc(keyboard);
glutMainLoop();
return 0;
}


K^2
  • K^2

    Vidi Vici Veni

  • Moderator
  • Joined: 14 Apr 2004
  • United-States
  • Most Knowledgeable [Web Development/Programming] 2013
    Most Knowledgeable [GTA Series] 2011
    Best Debater 2010

#11

Posted 24 January 2013 - 10:52 PM

The best thing I can recommend is learning a bit of DirectX 9 or 11. It's not the best example of how this can be done, but it's a descent one.

Swoorup
  • Swoorup

    innovator

  • Feroci
  • Joined: 28 Oct 2008
  • Nepal

#12

Posted 25 January 2013 - 05:31 AM

Hmm, whats wrong about OpenGL?

K^2
  • K^2

    Vidi Vici Veni

  • Moderator
  • Joined: 14 Apr 2004
  • United-States
  • Most Knowledgeable [Web Development/Programming] 2013
    Most Knowledgeable [GTA Series] 2011
    Best Debater 2010

#13

Posted 25 January 2013 - 02:59 PM

Support on Windows machines is kind of iffy. But that's not why I mentioned DirectX. If you want to understand how to build a rendering system with OO philosophy in mind, it's worth spending a bit of time learning DirectX simply because it is built entirely around OO programming. Rather than just make calls to initialize certain features, you would request a corresponding object to be created and interface with capabilities via that object. Furthermore, most tutorials are written in a similar manner, with even the simple examples running via OO model.

Basically, it will give you a better idea on how to write your own rendering code with OO in mind, be in in DX or OGL, much better than any set of explanation and advice somebody can give you over the forum.




1 user(s) are reading this topic

0 members, 1 guests, 0 anonymous users