Java-Gaming.org    
Featured games (81)
games approved by the League of Dukes
Games in Showcase (480)
Games in Android Showcase (110)
games submitted by our members
Games in WIP (547)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: [1]
  ignore  |  Print  
  Interface Design  (Read 459 times)
0 Members and 1 Guest are viewing this topic.
Offline Gibbo3771
« Posted 2014-03-25 12:09:40 »

Right, this is my last thread for today, all I have done is post shite.

I am feeling as if it is time I actually learn to do proper interface design, I have had a good look over LibGDX and how it is basically fully designed with interfaces. I sort of get how it works but at the same time it confuses the hell out of me.

Hit me with your best Interface Design articles, tutorials, books whatever.

I want to learn this sorcery! I shall Extend no more, I must implement!

"This code works flawlessly first time and exactly how I wanted it"
Said no programmer ever
Offline TeamworkGuy2

Junior Member


Medals: 10



« Reply #1 - Posted 2014-03-25 14:46:22 »

Hum, interface design Grin
I love interfaces, but most of what I've learned is from trial and error.
I would recommend Joshua Bloch's Effective Java book for general programming practices many of which are related to interfaces.

Online, maybe start with general design principles like:
http://en.wikipedia.org/wiki/Dependency_inversion_principle
http://en.wikipedia.org/wiki/Coupling_%28computer_programming%29
http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29

For example, it's a very helpful that InputStream and DataInput are interfaces that do not require extending and can be implemented by any class.
However, it's also very helpful that there are default implementations for these interfaces such as FileInputStream, ObjectInputStream, and ByteArrayInputStream.

It's important to balance a package, module, or API with both interfaces and default implementations (commonly preceded by the word Abstract in the Java libraries).  For example: ListModel has an abstract and default implementation, making it much more useful.

Whereas something like TimerTask is more annoying to use since it must be extended.  In my opinion, TimerTask could have been a concrete class with a constructor that took a Runnable object and ran that object instead of forcing every class that ever wanted to use TimerTask to extend it.

Common interface designs that I use are the builder pattern (http://javarevisited.blogspot.com/2012/06/builder-design-pattern-in-java-example.html)
which is something like this:
1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
11  
12  
13  
14  
15  
16  
17  
18  
19  
20  
21  
22  
23  
24  
25  
26  
27  
28  
29  
30  
31  
32  
33  
34  
35  
public class Thing {
  private int id;
  private Element matter;

  public Thing(int id, Element matter) {
    this.id = id;
    this.matter = matter;
  }

  public void thingStuff() {
    // ...
 }
}

public class ThingBuilder implements Builder<Thing> {
  private int thingId;
  private Element thingMatter;

  public void setId(int id) {
    this.thingId = id;
  }

  public void setElement(Element matter) {
    this.thingMatter = matter;
  }

  @Override
  public Thing create() {
    return new Thing(thingId, thingMatter);
  }
}

public interface Builder<T> {
  public T create();
}


and the service pattern (couldn't find many good web examples, here's a general discussion about it: http://www.velocityreviews.com/forums/t302202-service-provider-pattern.html)
and it looks something like this in its most basic form:
1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
11  
12  
13  
14  
15  
16  
17  
18  
19  
20  
21  
public interface XyzService {
  // various service methods...
}

public interface XyzProvider {
  public XyzService newXyzService();
}

public class Services {
  private static final Map<String, XyzProvider> providers = new ConcurrentHashMap<String, XyzProvider>();

  public static void registerProvider(String name, XyzProvider p) {
    providers.put(name, p);
  }

  public static XyzService newInstance(String name) {
    XyzProvider p = providers.get(name);
    if(p == null) { throw new IllegalArgumentException("No provider registered with the name '" + name + "'"); }
    return p.newXyzService();
  }
}

-Adapted from Effective Design Item 1.

For example, in java.util.concurrent Executor serves the role of XyzService in our example and Executors fulfills the role of Services in our example.

Good interface design is normally about abstracting away details, such as hiding a database connection so that it could easily be replaced with a file or hiding LWJGL's rendering system so that you can easily modify it for better performance or update it when a new version of LWJGL comes out.
Online BurntPizza
« Reply #2 - Posted 2014-03-25 15:00:51 »

Good interface design is nice when it's applicable, certainly better than tangled spaghetti code, but notice one thing:
All the examples here (libGDX, java.io, service providers, Executors) are APIs, specifically public APIs.
While having a well thought-out, clearly segmented codebase is attractive, two (at least) things will become apparent: if everything you do becomes an API, you will never get anything done. I can can attest to that, as it's a bad habit of mine. Also, massively engineered codebases have a certain, different spaghetti-ness to them. I remember a recent comment by princec describing it:

Quote from: princec
There is a balance. We all start off with the best of intentions, and then... we need to get it finished.

Enterprise code is probably the worst for it. So elegantly over-engineered, usually, that most of the time nobody knows how it works anyway. But it can look quite pretty. It rarely works very well. Most of the worst code I've come across is from my days as an enterprise developer. I'm proud to say mine was some of it  Smiley

Cas  Smiley
From here

So, while one cannot be expected to know bad code from good code right off the bat, please don't get sucked into the sometimes nearly religious adoption of a certain 'style' or 'way' of programming, because it's usually never good used alone. Develop and use judgement when using these 'patterns.' See EnterpriseFizzBuzz for a hilarious example of abuse of what, when used properly and in moderation, are perfectly fine practices in OOP.
Then consider that that actually happens, and you stop laughing.

I'm sure Roquen will pop in with something if he sees this thread, I remember he has something to say about interface design.
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline Danny02
« Reply #3 - Posted 2014-03-25 15:01:04 »

I have had a good look over LibGDX and how it is basically fully designed with interfaces.

Probably not a good place to look for good design. Just my two cents.
Offline Gibbo3771
« Reply #4 - Posted 2014-03-25 15:09:49 »

I have had a good look over LibGDX and how it is basically fully designed with interfaces.

Probably not a good place to look for good design. Just my two cents.

Maybe not for a game but I mean that practically the entire library is made with Interfaces, that is what makes me think "that's cool I want to learn that!".

Every little thing I learn is a plus, since I am going to study game development getting a grasp of how API's are designed might be a good thing.


*Snip  Shocked *

Thanks for the reply, that is a lot to take in lol.

"This code works flawlessly first time and exactly how I wanted it"
Said no programmer ever
Offline Danny02
« Reply #5 - Posted 2014-03-25 16:25:27 »

When talking specifically about interfaces, yes I believe it is good practise to use them a lot. The thing is, that this forces people to do composition over inheritance which is nice. Just don't over do it(like with everything), so pls no
ISomething, SomthingImpl
all over the code-base.
Offline Roquen
« Reply #6 - Posted 2014-03-26 10:32:45 »

Of the three major class-based OO structural design choices: design-by-{inheritance, composition, interface}.  design-by-interface is the weakest under the assumption you're also being data driven.  JDK 8 significantly improves the situation but it's still the weakest.  IMHO it is still mostly appropriate for type cross cuts, which composition can also cover.  JDK-8 gives an extra option for pseudo mixins and can drop some of the boilerplate PITA.  The worst case situation for {inheritance, composition} is that the table dereference(s) must occur.  The worst case situation for interface is it must perform a dynamic look-up to figure out offsets then perform the dereferences.  It does nothing to break-up a monolithic instance data-store and still with JDK-8 additions requires the most boilerplate and artificial introduction of types.  On the flip side since we can now define method signatures a la:

1  
2  
3  
4  
5  
@FunctionalInterface
public interface SomeMethodSigDef
{
   public WhateverReturn method(WhateverParameters);
}


This is not really an interface, but a call-site definition.  That's interesting.
Pages: [1]
  ignore  |  Print  
 
 

 

Add your game by posting it in the WIP section,
or publish it in Showcase.

The first screenshot will be displayed as a thumbnail.

atombrot (25 views)
2014-08-19 09:29:53

Tekkerue (24 views)
2014-08-16 06:45:27

Tekkerue (23 views)
2014-08-16 06:22:17

Tekkerue (13 views)
2014-08-16 06:20:21

Tekkerue (20 views)
2014-08-16 06:12:11

Rayexar (58 views)
2014-08-11 02:49:23

BurntPizza (38 views)
2014-08-09 21:09:32

BurntPizza (30 views)
2014-08-08 02:01:56

Norakomi (37 views)
2014-08-06 19:49:38

BurntPizza (67 views)
2014-08-03 02:57:17
List of Learning Resources
by Longor1996
2014-08-16 10:40:00

List of Learning Resources
by SilverTiger
2014-08-05 19:33:27

Resources for WIP games
by CogWheelz
2014-08-01 16:20:17

Resources for WIP games
by CogWheelz
2014-08-01 16:19:50

List of Learning Resources
by SilverTiger
2014-07-31 16:29:50

List of Learning Resources
by SilverTiger
2014-07-31 16:26:06

List of Learning Resources
by SilverTiger
2014-07-31 11:54:12

HotSpot Options
by dleskov
2014-07-08 01:59:08
java-gaming.org is not responsible for the content posted by its members, including references to external websites, and other references that may or may not have a relation with our primarily gaming and game production oriented community. inquiries and complaints can be sent via email to the info‑account of the company managing the website of java‑gaming.org
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!