Still hardly any games, why entity systems suck, and why 4k is good

Encapsulation through access modifiers is less important when you have separation of interface and implementation. If you access a class only through its interface, everything that isn’t on the interface is already effectively hidden. Proper OOP means any subclass has to be substitutable for its superclass, but only for its public members. Private and protected have more to do with giving subclasses an interface contract – or in the case of private, a lack thereof. As inheritance is more de-emphasized these days, encapsulation is also less of a byword in OOP than it used to be. It’s still not going away anytime soon.

Things like type systems, and oh, compilers owe their existence to egghead computer scientists who thought there was a better way than the current practice.

I simply find it patronising at best, and at worse, a huge inconvenience. And all wrapped up in a lovely waste of time which could have been spent solving the actual problem that needed solving.

Cas :slight_smile:

Reading this reminded me of this one here: link

In a large corporate environment, with different teams, and low communication, the encapsulation makes sense.

Especially if teams build different elements of the businesslogic, and some jars are reused over
years, and get maintainance.

There you need a way to hide logic, simply to prevent cheap custom hacks, that will break the system if
other components are updated later.

Java is not mainly designed for making games, but rather for corporate use-cases.

It simply take the coder the brains to understand that those are different envoronments, requiering different approaches.
There is no single best practise.

Lets use the function dirtfactor.
Where
Dirtfactor = projectsize * teammembers * code_dirtiness

So the dirtfactor should be kept at a constant, optimal level
And code_dirtiness needs to be lower in large, multiple developer teams
And high in small rapit prototypes

Actually, java was originally designed and intended for embedded systems, like software for cars and toasters.

My toaster has 2 buttons.
Never saw a JVM there.

And anyhow, those are actually examples of industrial projects, where the same applies.
(where different modelgenerations with customizations have to be developed,
hacking this together for each iteration would also increase the costs for the QA)

And yet, there are these massive software projects built up from PHP and JavaScript and Ruby and other scripting horrors and it turns out they didn’t need encapsulation to do it. Who knew?

Cas :slight_smile:

Well quite a few of these projects have hit walls. I know a few that are dumping entire code bases and starting again because its become impossible to maintain and impossible to hire new blood that can get anywhere in year (sorry NDAs).

Encapsulation is not a bad thing any more that 100% purely functional programing style is a bad thing. Its a tool and/or a style that can help solve problems. Big projects don’t fit inside anyone’s head, and even if your the sole developer it is easy to forget what is what. Encapsulation lets you tell others and yourself that you don’t need to see whats inside. You don’t need to go back over it you can look at just the outside. For the most part my code does work like this and i don’t need to dive into the internals. I almost never consult the java library source, but use the api documentation extensively.

Later if you do need to you can always add a public. Its not the end of the world. Java nor C++ forces encapsulation (unlike pure functional programing). Neither does C of course even if you want it too, yet the Linux kernel is written with a high degree of encapsulation. The “many simple programs do one job and well” is even a form of encapsulation.

I have seen my enemy, and he is me. Encapsulation helps me save me from myself.

The interesting thing to note about these complete rewrites is that I’ve seen exactly the same thing happen in any language in any project. The teams change slowly over time and eventually all projects end up in a bit of a mess and some genius has the bright idea of rewriting it whether it needs it or not. My conclusion is thusly: encapsulation has no measurable effect on code entropy, readability or maintainability, and that if an engineer gets left in charge of making management decisions sooner or later the irresistable urge to tinker with things pointlessly gets the better of them.

There may be some super wiz-kids out there who manage to keep stuff sane for longer but eventually everything succumbs. It should be one of those Laws.

Cas :slight_smile:

[quote]Dummy Interfaces: Write an empty interface called something like “WrittenByMe”, and make all of your classes implement it. Then, write wrapper classes for any of Java’s built-in classes that you use. The idea is to make sure that every single object in your program implements this interface. Finally, write all methods so that both their arguments and return types are WrittenByMe. This makes it nearly impossible to figure out what some methods do, and introduces all sorts of entertaining casting requirements. For a further extension, have each team member have his/her own personal interface (e.g., WrittenByJoe); any class worked on by a programmer gets to implement his/her interface. You can then arbitrarily refer to objects by any one of a large number of meaningless interfaces!
[/quote]
I found that on the site : How to write unmaintainable code :).

It makes me think about Entity System or code design of some programmer.

[quote]Too Much of A Good Thing™: Go


myPanel.add( getMyButton() );

private JButton getMyButton()
{
   return myButton;
}

That one probably did not even seem funny. Don’t worry. It will some day.
[/quote]
Another one relevent to this topic

[quote]Wrap, wrap, wrap: Whenever you have to use methods in code you did not write, insulate your code from that other dirty code by at least one layer of wrapper. After all, the other author might some time in the future recklessly rename every method. Then where would you be? You could of course, if he did such a thing, insulate your code from the changes by writing a wrapper or you could let VAJ handle the global rename. However, this is the perfect excuse to preemptively cut him off at the pass with a wrapper layer of indirection, before he does anything idiotic. One of Java’s main faults is that there is no way to solve many simple problems without dummy wrapper methods that do nothing but call another method of the same name, or a closely related name. This means it is possible to write wrappers four-levels deep that do absolutely nothing, and almost no one will notice. To maximise the obscuration, at each level, rename the methods, selecting random synonyms from a thesaurus. This gives the illusion something of note is happening. Further, the renaming helps ensure the lack of consistent project terminology. To ensure no one attempts to prune your levels back to a reasonable number, invoke some of your code bypassing the wrappers at each of the levels.
[/quote]

[quote]No Secrets!: Declare every method and variable public. After all, somebody, sometime might want to use it. Once a method has been declared public, it can’t very well be retracted, now can it? This makes it very difficult to later change the way anything works under the covers. It also has the delightful side effect of obscuring what a class is for. If the boss asks if you are out of your mind, tell him you are following the classic principles of transparent interfaces.
[/quote]

[quote]Static Is Good: Make as many of your variables as possible static. If you don’t need more than one instance of the class in this program, no one else ever will either. Again, if other coders in the project complain, tell them about the execution speed improvement you’re getting.
[/quote]

[quote]And That’s Final: Make all of your leaf classes final. After all, you’re done with the project - certainly no one else could possibly improve on your work by extending your classes. And it might even be a security flaw - after all, isn’t java.lang.String final for just this reason? If other coders in your project complain, tell them about the execution speed improvement you’re getting.
[/quote]
Lol someone told me exactly that once because I was arguing that putting everything final was a bad idea…

[quote]Eschew The Interface: In Java, disdain the interface. If your supervisors complain, tell them that Java interfaces force you to “cut-and-paste” code between different classes that implement the same interface the same way, and they know how hard that would be to maintain. Instead, do as the Java AWT (Advanced Windowing Toolkit) designers did - put lots of functionality in your classes that can only be used by classes that inherit from them, and use lots of “instanceof” checks in your methods. This way, if someone wants to reuse your code, they have to extend your classes. If they want to reuse your code from two different classes - tough luck, they can’t extend both of them at once! If an interface is unavoidable, make an all-purpose one and name it something like “ImplementableIface.” Another gem from academia is to append “Impl” to the names of classes that implement interfaces. This can be used to great advantage, e.g. with classes that implement Runnable.
[/quote]
Everyone love awt :slight_smile:

ok just 2 last one

[quote]Subclass With Abandon: Object oriented programming is a godsend for writing unmaintainable code. If you have a class with 10 properties (member/method) in it, consider a base class with only one property and subclassing it 9 levels deep so that each descendant adds one property. By the time you get to the last descendant class, you’ll have all 10 properties. If possible, put each class declaration in a separate file. This has the added effect of bloating your INCLUDE or USES statements, and forces the maintainer to open that many more files in his or her editor. Make sure you create at least one instance of each subclass.
[/quote]
:)!

[quote]Globals, We Can’t Stress These Enough!: If God didn’t want us to use global variables, he wouldn’t have invented them. Rather than disappoint God, use and set as many global variables as possible. Each function should use and set at least two of them, even if there’s no reason to do this. After all, any good maintenance programmer will soon figure out this is an exercise in detective work, and she’ll be happy for the exercise that separates real maintenance programmers from the dabblers.

Globals, One More Time, Boys: Global variables save you from having to specify arguments in functions. Take full advantage of this. Elect one or more of these global variables to specify what kinds of processes to do on the others. Maintenance programmers foolishly assume that C functions will not have side effects. Make sure they squirrel results and internal state information away in global variables.

Local Variables: Never use local variables. Whenever you feel the temptation to use one, make it into an instance or static variable instead to unselfishly share it with all the other methods of the class. This will save you work later when other methods need similar declarations. C++ programmers can go a step further by making all variables global.
[/quote]
Indeed that is good practice.

PHP and Ruby don’t support your argument. Both have private/public/protected, and both offer more ways to modularize your code. Especially Ruby with it’s mixins, blocks, lambdas and it’s meta-programming abilities.

As for JS, I personally find the lack of access modifiers an issue, and have had to use code practices to make it easier to navigate. For example I just never access fields directly from outside, because I have no idea if it’s meant to be public or private. Does it really matter? Yes! With any large code base it’s easy for small changes to cause bugs, and knowing that nothing else is touching this bit of code right here, is a HUGE advantage.

The simple fact is that there are plenty of language features out there that don’t get used, and if people didn’t find accessors useful, then they would be one of them.

Select field -> Write Access in Workspace

Cas :slight_smile:

It’s clear you haven’t really worked on a large codebase with a big team of typical software engineers. You cannot rely on other engineers doing the right thing and in fact have to work VERY hard just stop them from doing idiotic things. My life would be a living hell without access modifiers, they are essential for many reasons.

They protect your code from being abused, without them you couldn’t make any assumptions about any of your member variables ever. You would have to synchronize everything and null pointer check everywhere. They give massive hints as to how your code was designed and how it should be used and modified. Sure someone can just come along and make your internal member variable public but they will be wary of doing so and will likely check to see if this is what they should be doing.

Of course I have seen this taken to it’s extreme (especially in web-server frameworks for some reason) and it’s not pretty either. I saw a brilliant analogy to it with trying to buy a hammer http://discuss.joelonsoftware.com/default.asp?joel.3.219431 .

At the end of the day you need to remember it’s about simplicity as Einstein once said “Make things as simple as possible, but not simpler.”. Access modifiers essentially generate a layer of simplicity for other people to use, you just need to be careful about going too far.

Ha. I’ve been thinking of that Einstein quote, along with Antoine de Saint Exupéry’s:

(edit: And also “A goal without a plan is just a wish”)

LOL. You really ought to find out more about me.

Cas :slight_smile:

Why are you guys flaming access modifiers in the first place? Is it hard or time-consuming to pick the right one and write it?

I also like another Einstein quote, which somehow seems very apt for this thread.

[quote]A clever person solves a problem. A wise person avoids it.
[/quote]
It’s on that CodeWisdom feed I linked to earlier today btw ;D