Dark Wish

[davisdude]

Wow, looks great! Can't believe I missed this the first time you posted it. Keep up the good work

[slmjkdbtl]

I despise Java style rigid OO and the associated syntax. I now believe that getX() and setX() is the creation of the devil, the devout followers are confused souls that need saving. I also hate the word 'manager', which should be banned from programming and the general workplace too.

Hi I'm new to game dev and wish to improve my code, can you elaborate a little bit more on this? Thank you!

[drunken_munki]

Cheers all for the comments, I will post more in due time.

I despise Java style rigid OO and the associated syntax. I now believe that getX() and setX() is the creation of the devil, the devout followers are confused souls that need saving. I also hate the word 'manager', which should be banned from programming and the general workplace too.

Hi I'm new to game dev and wish to improve my code, can you elaborate a little bit more on this? Thank you!

Hard to express in short, but I can only proceed with heavy warning that this is opinion and some will disagree.

Start here with Mike Acton, don't mind the Hawaiian shirt:

https://www.youtube.com/watch?v=rX0ItVEVjHc

The real meat what I like to chew on is at 11.50 mark onwards to understand the differeing opinions between engineers and "why we do what we are doing" i.e. badly... because some people don't understand the problem correctly and therefore can not provide a decent solution.

The rest of the talk offers a good explanation of data-oriented design, a useful approach to solving problems. What I like is the raw explanation of what you are supposed to be doing as a software engineer and how this is a stark contrast to the modern 'software developer' slang that usually accompanies strict OO languages such as JAVA. A software engineer is supposed to create the solution that the hardware guys could not solve, and as such the solution is based on some description of the hardware and the requirements/objectives of the system.

In general this topic provides a strong rebuttal versus the object-oriented methodology that became fashionable over the last 15 years. The marketing spiel of OO is that is helps you create better, cleaner code and that is closer resembles 'life'... what ever that means. It turns out, we figured out that is mostly garbage and hyperbole used to sell OO books in the 2000's. When I started computer based classes back in 2005, OO and the huge cluster-fuck that is the 'system analysis waterfall' methodologies that they were hammering into our poor brains. Turns out that's all crap too, you simply can not solve a problem by a linear path of analysis -> design -> construction -> testing without 1) vastly underestimating the problem, 2) overestimating the effectiveness of the solutions 3) without missing deadlines, 4) and going over budget. The human brain can not plan for everything or know what is the correct path without actually getting your hands dirty at some point, to get a better idea of the problem. Not that these methods were strictly anything to do with OO but, you know, worth mentioning.

Entire languages built around OO have created 'code smells' that create a gaping chasm of things that you used to be able to do, so in turn the 'design pattern' book sellers came along to sticky-plaster these issues away, creating complex, confusing and non-reusable code. Thus completely destroying the point of what OO was supposed to be in the first place.

A site with a collection of sources on this topic is here:
https://content.pivotal.io/blog/all-evi ... g-bullshit
Though excuse the candid explanation and opinionated tone.

So a good example of a code smell is the getX() and setX() example. When used correctly, no problem, i.e. for a data container class it makes sense. However proper OO code is supposed to not be data containers, otherwise why wouldn't you just write this container in the data driven approach?

The term is 'mutator method':
https://en.wikipedia.org/wiki/Mutator_method

Though in reality, the problem I have with these is when they are used incorrectly, which is most likely 95% of the time.

A small article that started this rebuttal:
https://www.javaworld.com/article/20737 ... -evil.html

...and set fire to the entire internet.

A good extension to the topic was this article:
http://www.yegor256.com/2014/09/16/gett ... -evil.html


In my own words: the problem is mostly because of bad training, and the comfort of writing code in OO when in reality most of the time a developer is writing a data container for the wrong reasons, when they should be creating a living object.

Take the bad 'bank account' example:

Code: Select all

public class account () {
  private int id;
  private double balance;
 
  public double getBalance() {
    return balance;
  }

  public void setBalance(double b) {
    balance = b;
  }
}

This code would made no sense what so ever. Besides the get and set having no correct use in this case, the problem with this code is that in reality it is no different to:

Code: Select all

public class account () {
  public int id;
  public double balance;
}

Without the fluff and messy structure. Sure it's still terrible code, but at least it is readable. The getX and setX simply provide nothing, apart from the possibility of abuse by putting in hidden actions such as:

Code: Select all

public class account () {
  private int id;
  private int pin;
  private double balance;
 
  public double getBalance() {
    return balance;
  }

  public void setBalance(double b, int pincheck)  {
   if pin == pincheck {
      balance = b;
    }
  }
}

Now it is even more of a mess. All because of this habbit that coders have.

A slightly better way:

Code: Select all

public class account () {
  private int id;
  private int pin;
  private double balance;
 
  public double getBalance() {
    return balance;
  }

  public boolean withdraw(double amount, int pincheck) {
   if pin == pincheck {
     if balance - amount > 0 {
        balance = balance - amount;
        return true;
     }
    }
    return false;
  }

  public boolean deposit(double amount, int pin) {
   if pin == this.pin {
      balance = balance + amount;
      return true;
    }
  }
}

At least now we have the correct method in place to extend this code.

Oh but wait, now lets create an 'account manager' class to organise our collection of data containers... and now I stop. Because we have fallen into the design trap that the code is what drives this system, and not the data.


Lastly, more reading:

https://www.youtube.com/watch?v=QM1iUe6IofM

I just discovered this video and it hits home some more truths about the OO and software engineering, and was a very well explained presentation.


Another short but useful two videos on this:

https://www.youtube.com/watch?v=_xLgr6Ng4qQ

https://www.youtube.com/watch?v=GKYCA3UsmrU