[MUD-Dev] [TECH] [ObjC] : programming languages - Obj-C as opposed to Java

[Kwon Ekstrom]

From: "Brian Hook" <bwh at wksoftware.com>
> At 04:01 PM 8/16/01 -0600, Kwon Ekstrom wrote:

>> I've never used objC so I can't say anything about how things are
>> handled with it, but it sounds like you're java code suffered
>> from poor design rather than language problems.

> This is often the argument used to defend C++, but usually stated
> in the form "If you're having problems, it's probably because you
> don't know what you're doing".  Which is often true, however
> "knowing what you're doing" is a rather moving target, even with
> C++.  If you read

> For me, C++'s primary problem is that it's greatest strength -- a
> nearly agnostic view on language/framework design and
> implementation idioms -- undermines its ability to be used by
> large teams.  Take 10 class hierarchies written by 10 different
> programmers, and you will see 10 radically different ways of doing
> the same things.  This can become a mess, especially with large
> collaborative projects where various team members may not
> particularly enjoy the idioms established for that team, project
> or company.

Yeah, that's where good documentation is a must.  I really enjoy the
generated java docs, but even so, it requires a fair amount of the
programmers time to document classes properly.

>> I try to define constants on interfaces, and attempt to use more
>> or less unique naming of constants (because of multiply interface
>> inheritance).  You can then modify the interfaces for a pretty
>> similar affect to modifying constants in header files.

> I'm a bit confused about the above -- can you rephrase that or
> provide an example?

Sure can, I'll even expand to include abstract classes to define
default implementations to increase code reuse.  In java you only
have single inheritance, but you can implement multiple interfaces,
so they are a handy way to define details that may need to be
changed later.  Also the ability to type an object as an interface
is a big help to reuse code.

Now if you don't need to extend another class, you can extend an
abstract class which defines the code to handle a default
implementation.  This gives you a single point to write multiple
changes (it also helps if you have to change an interface later
since you can just define it in the abstract class and the changes
will show up on any child classes)

Interfaces also serve as enforced reminders, if you add a method to
an interface, any class that implements it must define the new
methods.

For an example, I have my list code, which extends java.util.List
and defines additional behavior such as filtering, multiple
retrieval, and output to another list.  The class heirarchy looks
something like:

  java.util.List -> org.Aaern.AaernList -> org.Aaern.genericList

With a variety of lists extending genericList for specific details.
I have a hasName interface defined that items with a name implement
such as Creature and Item (item and creature seem more descriptive
to me and are hopefully easier to understand for someone trying to
use my code)

So org.Aaern.hasNameList would extend org.Aaern.AaernList (with
interfaces you can have multiple inheritance, I don't use it here
but I do for my Token interface which is the basis for Room,
Creature, and Item... this further allows me to reuse code)

The interface gives me a single access point for the details such as
methods and constants, but I use an abstract class to provide a
single access point for implementation details with unique
requirements being modified later.  As a rule, my abstract classes
define protected methods to handle areas that I think are most
likely to be modified in the future.  You can then override those
methods to save work.

>> As for other things such as methods and fields, I prefer the fact
>> that java objects are stored in a single place.

> That's my point, and maybe your earlier statement which I didn't
> quite grok clarifies this.  In Java, your interface and
> implementation are equally "exposed" to the public, so performing
> a "make" will possibly force a fairly significant rebuild even if
> you're only changing an implementation, not an interface.

Hrmm, I don't see how it would force a significant rebuild since the
JVM loads the classes into memory upon startup.  Allowing you to
only recompile the classes you edit (unless you're adding methods to
an interface which requires all implementing classes to define that
method)

> Physically separating interface and implementation into separate
> files seems, to me, to be a very good thing.

*nod* That's the reason sun developed the interface system I think.
Additionally I create alot of interfaces to handle a small aspect of
what I need and have the major classes (Creature, Room, Item for
example) implement specific interfaces, this allows me to reuse code
for everything but the most specific cases.  Since Creatures and
Items have names for example, I have a "hasName" interface to handle
retrieving and comparing names.  One of my list interfaces allows
you to retrieve objects based on the name, so I can use those lists
for both creatures and items.

> If I spend some time doing my GMUD-In-A-Box, it will likely rely
> on a plethora of tools developed using Obj-C/Cocoa on OS X.  High
> quality tools are the key to fast and effective content
> generation, and I would argue that proper tools and technology can
> radically affect a game's design philosophy.  For example, if you
> can whip up a new "zone" in a week, that changes how you can view
> your game's life cycle vs. requiring 6 months to release a new
> zone.

*nod* I'm developing a text based mud, but one of the things I'd
like to write is a servlet that communicates with the mud to allow
building on the web page.  A fair amount of what slows building I've
noticed is confusion about the builder commands, and a web form
seems like an idea way to simplify the work.  It's a familiar
interface, but it can be setup to handle things quite easily.

Anyway, I have a complex interface scheme, I'd probably have to draw
it up or show the java docs to really explain it, my class heirarchy
is otherwise flat.  But I tend to use interfaces to define specific
details to allow me to reuse more code.  I hope this answered some
of your concerns without bringing up more... heh.

-- Kwon Ekstrom

_______________________________________________
MUD-Dev mailing list
MUD-Dev at kanga.nu
https://www.kanga.nu/lists/listinfo/mud-dev