I was going through some sequence diagram reference material and came across this quote from the web page UML basics
A purist would argue that an object should never send a message to itself. However, modeling an object sending a message to itself can be useful in some cases.
Can someone elaborate on this? Who are these purists?
Related
I have asked this on the Stack Exchange Graphic Design forum but that doesn't see much traffic so although this is not your typical programming question I felt I had a better chance of getting an answer here...
Is there, and if so, could somebody please point me to, an online resource for the CorelDRAW X6 Object Model? Something similar to the Object Browser within CorelDRAW, that contains a complete listing of all objects, object members, methods, properties, member function definitions, classes, etc.. I only have CorelDRAW on my work computer and I would like to be able to peruse the Object Model and see the available methods and functions and what types they take for their parameters while at home.
And while I'm at it, could somebody recommend a good online resource for VBA programming in general.
I'm very new to Akka. I'm designing a modular system in Akka, and I'm looking for a way to define an API for each module.
Normally in Java I'd write a bunch of beans and some interfaces that accept and produce those beans. From what I gather, in Akka Message types replace the beans, and there seems to be no equivalent for an Interface (or something to help the compiler enforce some "what happens when" or "what can happen when" contract).
I would welcome any advice or best practice on what is the best way to write the most coherent API. If the compiler can understand it, it's a serious bonus.
The API exposed by an Actor (or a collection of collaborating Actors) is defined by the set of message types that it accepts. My recommendation is to keep these message classes close to the Actor, e.g. as static inner classes of the UntypedActor class (for Java) or in the Actor’s companion object (for Scala). For larger actor hierarchies implementing a single interface I would recommend placing all the message classes with the “head actor” (the entry point to the hierarchy) or in a separate class that has a descriptive name and is otherwise empty. Having the as top-level classes can easily lead to name-clashes that can in Java only be resolved by using fully-qualified class names.
The compiler can currently not yet help you in avoiding the mistake of sending the wrong message to an ActorRef because that reference is oblivious to the kind of actor it represents. We are researching ways to tackle this problem, you can take a look at the TypedChannels experiment (Scala only) and later this year we will start working on a simpler solution that also supports Java (codename “Akka Gålbma”, see the roadmap).
In Object oriented programming objects communicate by passing messages, sometimes these messages can also have arguments.
I.e. A Student object can send a message to a School object asking for a list of public holidays.
My question is how these messages are different then traditional class methods? are they both same thing? and how do we show them in UML?
There is such a thing as 'message passing', you can read about it on WikiPedia but from the text you quote, I would guess they just mean a method call. Can't say more without more context.
I'm currently making a client-client approach on some simulation with objective-c with two computers (mac1 and mac2).
I have a class Client, and every computer has a instance of the "Client" on it (client1,client2). I expect that both clients will be synchronized: they will both be equal apart from memory locations.
When a user presses a key on mac1, I want both client1 and client2 to receive a given method from class Client (so that they are synchronized, i.e. they are the same apart from it's memory location on each mac).
To this approach, my current idea is to make 2 methods:
- (void) sendSelector:(Client*)toClient,...;
- (void) receiveSelector:(Client*)fromClient,...;
sendSelector: uses NSStringFromSelector() to transform the method to a NSString, and send it over the network (let's not worry about sending strings over net now).
On the other hand, receiveSelector: uses NSSelectorFromString() to transform a NSString back to a selector.
My first question/issue is: to what extent is this approach "standard" on networking with objective-c?
My second question:
And the method's arguments? Is there any way of "packing" a given class instance and send it over the network? I understand the pointer's problem when packing, but every instance on my program as an unique identity, so that should be no problem since both clients will know how to retrieve the object from its identity.
Thanks for your help
Let me address your second question first:
And the method's arguments? Is there any way of "packing" a given
class instance and send it over the network?
Many Cocoa classes implement/adopt the NSCoding #protocol. This means they support some default implementation for serializing to a byte stream, which you could then send over the network. You would be well advised to use the NSCoding approach unless it's fundamentally not suited to your needs for some reason. (i.e. use the highest level of abstraction that gets the job done)
Now for the more philosophical side of your first question; I'll rephrase your question as "is it a good approach to use serialized method invocations as a means of communication between two clients over a network?"
First, you should know that Objective-C has a not-often-used-any-more, but reasonably complete, implementation for handling remote invocations between machines with a high level of abstraction. It was called Distributed Objects. Apple appears to be shoving it under the rug to some degree (with good reason -- keep reading), but I was able to find an old cached copy of the Distributed Objects Programming Topics guide. You may find it informative. AFAIK, all the underpinnings of Distributed Objects still ship in the Objective-C runtime/frameworks, so if you wanted to use it, if only to prototype, you probably could.
I can't speculate as to the exact reasons that you can't seem to find this document on developer.apple.com these days, but I think it's fair to say that, in general, you don't want to be using a remote invocation approach like this in production, or over insecure network channels (for instance: over the Internet.) It's a huge potential attack vector. Just think of it: If I can modify, or spoof, your network messages, I can induce your client application to call arbitrary selectors with arbitrary arguments. It's not hard to see how this could go very wrong.
At a high level, let me recommend coming up with some sort of protocol for your application, with some arbitrary wire format (another person mentioned JSON -- It's got a lot of support these days -- but using NSCoding will probably bootstrap you the quickest), and when your client receives such a message, it should read the message as data and make a decision about what action to take, without actually deriving at runtime what is, in effect, code from the message itself.
From a "getting things done" perspective, I like to share a maxim I learned a while ago: "Make it work; Make it work right; Make it work fast. In that order."
For prototyping, maybe you don't care about security. Maybe when you're just trying to "make it work" you use Distributed Objects, or maybe you roll your own remote invocation protocol, as it appears you've been thinking of doing. Just remember: you really need to "make it work right" before releasing it into the wild, or those decisions you made for prototyping expedience could cost you dearly. The best approach here will be to create a class or group of classes that abstracts away the network protocol and wire format from the rest of your code, so you can swap out networking implementations later without having to touch all your code.
One more suggestion: I read in your initial question a desire to 'keep an object (or perhaps an object graph) in sync across multiple clients.' This is a complex topic, but you may wish to employ a "Command Pattern" (see the Gang of Four book, or any number of other treatments in the wild.) Taking such an approach may also inherently bring structure to your networking protocol. In other words, once you've broken down all your model mutation operations into "commands" maybe your protocol is as simple as serializing those commands using NSCoding and shipping them over the wire to the other client and executing them again there.
Hopefully this helps, or at least gives you some starting points and things to consider.
These days it would seem that the most standard way is to package everything up on JSON.
So I know a bit of C, trying to jump into ObjC for Max apps. Trying to figure out the terms and just needed a guru to humor me.
So an object could be thought of as a house that holds operations and data together.
But there may be many different objects of the same kind, called an instance. This could be thought of as a trailer park (manufactured home community) with a bunch of object homes. Not sure how to give an example of a type however.
Following same example, the methods would be the way the data in the house is manipulated?
Trying to figure these definitions out in a very simple example for my brain :)
It sounds more like you need some education on Object Oriented Programming in general rather than Objective-C specifically. Do some googling for general OOP references. Here's some basics referring to your specific question:
Object: A general term for a combination of data and related operations
Class: A specific definition of an object, i.e. NSController
Instance: A specific object created from a Class definition
So, I could have an object Controller1, that is an instance of the NSController class. This could be referred to as an "NSController object" or an instance of "NSController".
Stop using these analogies, just start playing around with tutorials and the code, you will get the hang of what everything does in no time.
In my words I would call methods a collective of instructions that you can call on with the given method name.
But really, just start writing code, the rest will come :) (no copy pasting!!)
What you're asking has little to do with Objective-C specifically, and everything to do with Object-Oriented Programming. Read up on that before diving into the new language!
I know this topic is quite old, but I thought I'd try and help out in case anyone is coming here looking for answers.
Object
Blueprint for a house. It has the plans for building a house, and it will even supply the contractors to build the house for you, but it is not the house.
Instance
This is a house. It also keeps track of all of the characteristics of the house, and as a result it can be introspective. IE: You can ask the house how many rooms it has, what its dimensions are &etc.
Method
Most every object will define methods. Methods do stuff. Following the house analogy, a method would be the mechanism that would grab the dimensions for you and print them out, or it could be something that would modify the state of the house. IE: call a plumber to fix a leaky pipe on the house.