An Intro to Tornado book mentions a "frob object" and search engines are not being terribly yielding, so I hope this is a worthwhile question.
I'm seeing a lot of references to Flicker frobs and read that:
Etymology
It was adopted by the community of computer programmers which grew out of the MIT Tech Model Railroad Club in the 1950s, and allegedly among the oldest existing words in hacker jargon.
Noun
frob (plural frobs)
(jargon, MIT) Any small device or object (usually hand-sized) which can be manipulated.
Hand me that frob there, will you?
So in relation to application and web development, is a "frob object" just any small object that can be manipulated? For example:
class SomeFrob(object):
holder = "something mutable"
frob = new SomeFrob
frob.holder = "mutated"
From what I can tell, they are just using the word Frob as a substitute or placeholder for a more specific name. The reason is that the name of the method or class isn't important, the concepts contained within are.
This is the same as calling a class Foo or Bar. Now, as to why they use Frob instead of the extremely common name of Foo is beyond me.
The only reference to Frob in the context of Tornado I can find is in a book titled Introduction to Tornado. So I wouldn't worry about it too much. The author likely just wanted to be a bit different.
Related
My understanding of "factory-related" design patterns and their OOP-implementations has always been pretty simple.
A "Factory method" is a method inside a class that has an interface (or an abstract class) as a return type and constructs objects implementing this interface based on some internal logic.
A "Factory" is a class that only contains factory methods
An "Abstract factory" is an interface (or an abstract class) that only contains factory methods
But I recently stumbled upon Wikipeda articles on the subject (Factory, Abstract factory) that made me somewhat confused, especially about what a "Factory" is in OOP.
Here are several quotes:
A subroutine that returns a "new" object may be referred to as a "factory", as in factory method or factory function.
Factories are used in various design patterns
The "Abstract factory pattern" is a method to build collections of factories.
A factory is the location of a concrete class in the code at which objects are constructed
which arouse some questions:
(1)&(2) Does this mean that a factory is not a class or an object, but a piece of logic?
(2) Is "Factory" not a pattern itself?
(3) What does "collection" mean here? Is it just a way of saying "you can have several factories that implement the same interface (which is an abstract factory)"?
(4) What???
Can anyone clarify what this means? Is my initial understanding of factories incorrect?
Look at this wiki which says:
In object-oriented programming (OOP), a factory is an object for
creating other objects – formally a factory is a function or method
that returns objects of a varying prototype or class from some
method call, which is assumed to be "new".[a] More broadly, a
subroutine that returns a "new" object may be referred to as a
"factory", as in factory method or factory function. This is a basic
concept in OOP, and forms the basis for a number of related software
design patterns.
So to answer your questions specifically:
(1)&(2) Does this mean that a factory is not a class or an object, but a piece of logic?
No, it means that you can create other objects using an object(factory).
(2) Is "Factory" not a pattern itself?
There are different design patterns out of which factory pattern is one. So when you are creating objects using a factory then that patter of creating other objects is "Factory pattern"
I think you generally have it right. But, people don't like general, so it's the specifics where things go pear-shaped.
There a few things to consider:
Wikipedia is sometimes woefully bad on technical subjects because they are trying to get to a single answer where different domains or programming languages may use the terms slightly differently. Not only that, many people are not skilled at technical writing and forget that Wikipedia is for the masses, not a graduate-level computer science theory class. As such, they tend to overly focus on minutiae or use language more complicated than necessary. So, don't worry about Wikipedia. And, although there is an edit history, no real names tend to be attached to these and no one really cares who wrote which words, so no one is that motivated to do that well. Having expressed that quite cynical opinion of the whole endeavor, reading the Talk pages are very interesting, in a Cunningham's Law sort of way.
(2) The name "Factory" is a pattern, but remember that patterns are general ideas, not implementations. Different languages may employ the same idea in different ways, and those different ways may not agree. A particular language or community starts to use the term in the way most meaningful to them, however, despite what anyone else thinks. That idea may show up in bare, procedural logic; classes; objects; or whatever the tool provides.
Design Patterns (the book(s)) are generally describing shortcomings in tools. They also aren't really design patterns in the way the authors think they are. Mark Jason Dominus has a wonderful talk on this, "Design Patterns" Aren't. His basic idea is that the Gang of Four misunderstand Christopher Alexander in that they (accidentally) prescribe solutions rather than promote the idea of a locally-relevant architectural language. So, the Gang of Four patterns become reified in languages almost exactly as the described single possible solution. Readers then force those patterns as a globally-relevant language completely disconnected from what you personally are trying to build, then argue about what it all really means out of any sort of context using extremely ill-suited examples that don't matter to what anyone is trying to build. There's no reason your recommendation engine and someone's first person shooter should have the same architectural language other than your tool forcing it on both of you. FWIW, paying attention to Mark Jason Dominus is a very good professional development move. His Higher-Order Perl is one of the best programming language books I've read and certainly better than anything I've written. He knows a lot of different languages (and languages that are very different) and thinks very deeply about things.
In (3), the term "collection" is unfortunate because we tend to use that to mean a set of things that co-exist at a particular time in the same container (box, book, whatever). I think they are trying to suggest that the abstract factory is a template for future factories that cannot be presently enumerated, which is a fancy way of saying that we can use it to build factories we don't even know about yet.
In (4), the term "location" is unfortunate. An abstract factory is a way of producing concrete factories, which is a way of producing objects.
I'm curious to know if any of the Cocoa frameworks contain an initializer that might be mistaken for dealing with a human being. Obvious methods, (although I don't know if or where they exist) are initWithAge, or initWithName.
Are there any really clever sounding Cocoa initializers that may be applicable to people?
Edit:
I'm certainly not asking about the new operator. This is the kind of question you might get at a trivia event, but I'm absolutely serious about this. It can be answered objectively and definitively. Are there any cleverly named Cocoa initializers that can be understood to refer to people?
So, I think you're asking this:
Is there an established convention for initializing an object that describes a person?
So, the first thing I would do is grep through the framework headers looking for references to "person":
$ cd /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk/System/Library/Frameworks
$ grep -r 'Person\b' . | edit
(Yes, I default to looking in the Mac SDK. Looking in the iOS SDK will be left as an exercise to the reader)
This results in 381 hits for me, mostly duplicated information. But there are a couple of interesting hits:
ABPerson from AddressBook.framework
EKParticipant from EventKit
PSAuthor from PubSub
Unfortunately, none of these results have an initializer, because they're all mainly for interacting with existing Person objects, not for creating new ones. The exception is -[ABPerson(ABPerson_vCard) initWithVCardRepresentation]. That's probably not helpful.
So we need to keep digging. How else might we describe a person? "People"? "Member"? "Individual"? "Customer"? All of these would be pretty good things to look for.
And then I remembered that there's this obscure framework buried deep inside the OS X SDK that no one ever really talks about, called Collaboration.framework:
The Collaboration framework is a set of Objective-C classes that allows developers to monitor identities and their attributes. (reference)
That looks promising! And indeed, looking in here there's really interesting class: CBIdentity. A CBIdentity "is used for accessing the attributes of an identity". There are a bunch of different ways to create an identity, but I like this pattern, and I would recommend doing it like this:
An "MBIdentity" class would define ways to canonically identify a person. So you could have -initWithSocialSecurityNumber: or -initWithName: or -initWithBirthLocation:time:, etc. The purpose of this class would be to establish a collection of attributes that are sufficient to identify an individual.
Your "MBPerson" class would then have an -initWithIdentity: method that takes an MBIdentity. The Person would then take on the characteristics of its composed Identity.
I suppose the important thing to realize here is that there are many ways to establish identity (and hence many properties/initializers on an MBIdentity). But once you've established an identity, only one Person has that identity (and so your Person class only has an initWithIdentity: method).
Strange question... erm...
initWithKind: // nice, nasty...
initWithUser: // username
initWithColor: // black, white
initWithStyle: // cool, geeky
initWithTitle: // Dr
initWithSize: // big, small
composed versions
initWithTitle:#"Dr" message:#"You are crazy"
initWithTitle:#"Your Honour" style:#"serious" handler:#"wife"
although these are from BlockKit so they might not count...
This is the basic scenario:
A method returns a class of type A, but after looking at the internal workings of the code it is found safe to assume that it actually returns B (a subclass of A). Is it then valid to do something like this? Or would you highly discourage it because it is accessing protected data (at least):
Assume that you do not maintain this code that implements the method as well. I.e, your software could ship with a different implementation of this (well established) method.
A returnedData = executeMethod();
if(returnedData instanceof B)
{
((B)returnedData).someFunctionNotExposedThroughAIsItProtected();
//Use it as B, safe but non OOP and accessing protected functionality?
}else
writeAFallBackOfSomeSort();
The key point is the if(returnedData instanceof B): if such a statement exist, it is proven that the returned object is a B (which in turn also includes A), so using B public method is safe.
In pure OOP sense this is not "elegant", but it is often the pragmatic way to go.
Think a while: a Dog is an Animal, but is unlikely that Animal has a do-nothing bark method, otherwise -for completeness- it must have all methods for all possible animals may have, thus making Animal a sort of "God Object" (a well known anti-pattern).
It is more pragmatic once you've got an Animal, ask it to bark only after you recognized it is a Dog. You can have then more Dog subclasses (representing different dog races) barking differently, but bark belongs to Dogs, not Animal in general.
The problem now becomes: is it correct to suppose an Animal could be a Dog? If you can check it, why not!
Use OOP as a technique where convenient, not as a religion to serve.
Consider also that the answer can change depending on the language used and on what feature it has around objects and the way it define what a "object" is. Where no runtime dispatch exist (or where runtime dispatch is single and you need multiple) this can be even a well established method.
It most certainly is discouraged.
A method of an API declares a specific return type because that's what the API developer decided to declare. It creates a contract essentially saying "expect this type and nothing else". If the API developer didn't want to expose another type, (s)he probably had a good reason for that.
The internal implementation of the method should, in the general case, never concern you. The API developer can change it at any time, and in this case you are the one responsible for the consequences, not her/him.
Granted, your workaround is OK, as long as the sole contents of writeAFallBackOfSomeSort() is not
private void writeAFallBackOfSomeSort() {
//TODO: I'll implement this later
}
.
I was reading an article written by an ASF contributor, and he briefly mentioned that an "old Java trick" to deep clone an object is to serialize it and then deserialize it back into another object. When I read this I paused, and thought "hey, that's pretty smart." Unfortunately neither deep cloning, nor serialization, were the subject of the article, and so the author never gave an example of what he was talking about, and online searches haven't pulled back anything along these lines.
I have to assume, we're talking about something that looks like this:
public class Dog implements Serializable
{
// ...
public Dog deepClone()
{
Dog dogClone = null;
try
{
FileOutputStream fout = new FileOutputStream("mydog.dat");
ObjectOutputStream oos = new ObjectOutputStream(fout);
oos.writeObject(this);
oos.close();
FileInputStream fin = new FileInputStream("mydog.dat");
ObjectInputStream ois = new ObjectInputStream(fin);
dogClone = (Dog)ois.readObject();
ois.close();
return dogClone;
}
catch(Exception e)
{
// Blah
}
}
Provided that I might be off a little bit (plus or minus a few lines of code), is this a generally-accepted practice for deep cloning an object? Are there any pitfalls or caveats to this method?
Are there synching/concurrency/thread-safety issues not addressed?
Because if this is a best-practices way of deep cloning objects, I'm going to use it religiously.
This is one common practice for deep-clonging. The drawbacks are:
It is generally slow to do a serialization/deserialization. Custom cloning is faster.
It only clones serializable objects, obviously
It is difficult to know what you serialize. If your dog has an upwards pointer to some larger structure (pack of dogs), cloning a dog may clone a hundred other dogs if you don't pay attention. A manual clone of Dog would probably simply ignore the pack reference, creating a new individual dog object with the same properties, perhaps referencing the same pack of dogs, but not cloning the pack.
Thread safety is not different from doing a manual clone. The properties will most likely be read sequentially from the source object by the serializer, and unless you take care of thread safety you may clone a dog that is partially changed while cloning.
So I'd say it is probably not advisable to use this all the time. For a really simple object, making a simple manual clone/copy-constructor is simple and will perform much better. And for a complex object graph you may find that this runs the risk of cloning things you didn't intend to. So while it is useful, it should be used with caution.
By the way, in your example I'd use a memory stream rather than a file stream.
As you may have guessed from the question - I am right at the beginning of the Obj-C journey.
I'm hoping that someone out there knows of some diagrams that depict the relationship between classes, objects and methods - and that they're willing to share.
The problem I'm having is that just looking at code in a textbook doesn't completely explain it - for me at least.
Thanks for reading!
Regards,
Spencer.
No diagrams, but this is the tutorial I wish I'd read before I started:
http://www.cocoadevcentral.com/d/learn_objectivec/
Simple English, all the basic concepts.
Classes are just like classes in any language. They are descriptions.
Objects are like nouns. They are an instance of a class. That is, if you had a description of a generic book (the class) and you made a thesaurus based on that description, the thesaurus would be the object.
Methods are more or less functions. If the objects are nouns, then the messages are verbs.
[ScienceBook getTableOfContents]; //this would like return a table of contents.
Here, the object ScienceBook is being sent a getTableOfContents message (method). So now, the science book would theoretically find, format and return the table of contents to whom ever sent the message.
To some extent, diagrams may not be that helpful to answer the questions you present.
It may help to think of things like this:
A "class" provides the prototype or definition for some thing. For example, a "Person" or a "Car". A common synonym for "class" is "type".
An "object" is a concrete example or instance of a class. For example, you are an instance of "Person", and your car is an instance of "Car".
A "method" is a behavior, action or property of a class. However, a method is normally only meaningful in the context of an object. "Person" -> "Eat" is not meaningful, but "you" -> "Eat" is.
These are fundamental Object-Oriented concepts that are not specific to Objective-C. If you are interested in a general overview that is language-agnostic, I recommend "Object Thinking" by David West. Even though it's from Microsoft Press, it covers the concepts rather than any specific language.
I come from a fairly strong C++ background, but I can definitely remember when I started, I had a hard time grasping at the concept until I found a way to associate it with physical objects.
The word class and object you can use almost interchangeably. Think of an object as a container, like a bucket. The word bucket would be your "class". It is the name you give to the type of object you have.
A bucket has a certain purpose...to carry something. It might be water...or perhaps sand. So perhaps you want to fill the bucket. This would be something you do to the bucket, so in objective-c, this would be your method. You might write something like:
- (void) fillWith:(elementType)something;
So in this case, "something" might be something that represents and object you wish to fill your bucket with.
Your class might look like the following:
typedef enum items {
CRAYONS,
MARKERS,
SAND,
WATER } elementType;
#class Bucket {
elementType item;
}
- (void) fillWith:(elementType)something;
#end
Here's one link to some objective-c samples. Also try the apple development center.
If you're after information on Object Orientated Programming (ie the meaning of classes, objects, methods etc) then I'd advise against Objective-C. Objective-C on the Mac relies heavily on the Cocoa framework. The Cocoa framework is vast and performs a lot of 'magic' which will make it harder to understand the fundamentals of OOP.
An easier place to start would be a language used for web development. It's easier to get to the nuts and bolts of OOP with these languages.