Related
I have inherited an anylogic model at work. It's my first contact with anylogic. There is hardly documentation, so I try to dissect the generated code to understand, what is going on.
There is one thing that appears all the time: _xjal
It appears in variable, member and method names - like _result_xjal, _value_xjal etc...
Usually it is easier to understand code when names make sense. That's why I hope, to easier understand the code, once this strange thing, that google does not know of, is deciphered.
What does it stand for?
"xj" stands for XJ-Tec (the former name of the company that develops AnyLogic).
"al" stands for AnyLogic.
"xjal" flags that this is code developed by the AnyLogic developers, i.e. it is neither standard Java code nor code from your model.
Nothing more and nothing less :)
Recently I was asked a question in an interview to design a bird flight simulator.
I went ahead and thought of strategy pattern for the simulator class and attributes like air pressure, wind velocity etc. A method would take a bird object and time and would return x,y,z coordinates.
e.g.
class Simulator
attr_accesor :bird, :air_pressure, :wind_velocity
def map_coordinates(bird, time)
...
end
...
end
and then thought about bird class:
For the bird can fly/Not fly attribute I thought about a boolean variable which would be set at initialization time. For e.g:
class Bird
attr_accessor :weight, :wing_dimension, :canfly, :height....
def initialize(weight, wing_dimension, canfly, height)
#weight = weight
#wing_dimension = wing_dimension
#canfly = canfly
#height = height
end
end
My question is from OOD point of view, it says a Bird class should use composition and use a class to encapsulate the properties required in a class. https://www.safaribooksonline.com/library/view/head-first-design/0596007124/ch01.html
So, Do I really need a class to map the canfly behavior? Can't I just have a boolean field to be initialized in this case while creating the Bird object.
Why would not that be a good design?
If not, what's the best approach and why?
In terms of OOD it's important make a comparison between association/aggregation, inheritance, composition and use. In a composition relationship the class should create object instances using the method new of the class.
Bird class has associated particular weight and height, in terms of composition a bird has two wings and a peak, which maybe can be different classes. In Wing class, wing_dimension attribute should be included as an aggregation relationship, as weight and height in bird class.
class Bird
attr_accessor :weight, :height, :rightWing, :leftWing, :peak
def initialize(weight, height)
#weight = weight
#height = height
rightWing = Wing. new
leftWing = Wing. new
peak = Peak.new
end
end
In Simulator class, for example, if you'll want to design a fly simulator, this attribute needs to be common in different classes.
To sum up, if exists an inheritance relationship between a general class, for example "Animal" with bird and fly(insect), you can make an aggregation relationship in def, and canfly as an attrinute of Animal class.
class Simulator
attr_accesor :animal, :air_pressure, :wind_velocity
def map_coordinates(animal, time)
...
end
...
end
So, Do I really need a class to map the canfly behavior? Can't I just have a Boolean field to be initialized in this case while creating the Bird object?
Why would not that be a good design? If not, what's the best approach and why?
To your first question: "Do I really need...?" That is a really good
question. In terms of Object Oriented Design, that is the very question you need to be asking yourself. In fact, that is exactly how good design decisions are made.
The fact that you also arrived at a tentative solution "Can't I just...?" means that you have identified ONE small problem that you might solve with a binary solution. bool canfly ? true : false
Let's assume, that you have looked at the big picture. You imagine that your "SIMULATOR" will have all different kinds of birds, even birds
that cannot fly, as well as those TYPICAL birds that do.
And finally, you arrive at three other, really fantastic questions.
I can't help but wonder whether or not you pulled these questions straight out of an OOA & D textbook.
1) Why would not that be a good design?
2) What would be a better design?
3) Why would the second design be better than the first
OK, I am going to try my best here. I am going to attempt to make an illustration from your approach in asking these questions, and in the way that you did. Look at the tiny footprint that all of these questions make here, in comparison to the HUGE footprint it WILL make in my post, trying to fill in all of those blanks because you have no idea how many answers those questions could generate (nor do I). That just happens to be one of the answers. Man, I hope this doesn't turn into a sprawling mess.(that's another one)
I think first, I would like to clarify one very important distinction.
The nature of these questions is not the same as the nature of the questions you would expect to find answers to in an algebra textbook. Algebra is about HOW. I discovered that the WHY
doesn't really mean anything in Algebra until you get to Calculus.
Why not this way...What way should I...How is that way better...Why is that way better...? WHY should I even care? These are the kinds of questions you find answers to in a philosophy textbook. They are the appropriate kind for OOD as well because OOD is more of a philosophy than it is a "soft science." It is my opinion, and others hold that opinion, but some think otherwise. Does that sound concrete?
Interestingly enough, that is a term used in OOD to differentiate a derived class from an Abstract class or an Interface. It is the result, but it is NOT the design. In my opinion, understanding that first is as important, if not more, than any concrete design that some might try to pass off as a good answer.
Let me ask a question also. Would you rather have your tiny footprint in your code-base or my HUGE footprint there? Because you may do what you want, that is your choice. However, let me just point something out that might change your mind. I can create an Interface lets say, and I
might call it something like this.
public Interface IEveryPossibleFlyingOperationYouOrAnyoneElseMightImagine{}; And you would probably say: That is a ridiculously long and over descriptive naming convention you have there!!! To which I would reply: Yes, but you can't even imagine how many things that Interface covers....And besides, I only ever have to write it once, because then I can do this...
IEveryPossibleFlyingOperationYouOrAnyoneElseMightImagine fly;
Then I would put that tiny little fly (also an insect that just happens to fly by the way.) in my code-base. Then, I would close it up, and HOPEFULLY never have to open it again.
Furthermore, everything that belongs to that Interface, which you know nothing about, because it has been abstracted away, and loosely coupled with other things like it, for the purpose of possible future extension, will never break your code base. How could it? It's a tiny little fly.
You see how long this answer is, and it only scratches the surface of what you are actually asking here I assure you.
Now, I will try to give you something a little more concrete, though it will not be nearly enough to satisfy all of what you are asking here.
OOP, in general, is about a lot of things, this one thing, that I hope makes at least some sense, is a principle. If that principle is learned and followed, you will never have my footprint in your code-base.
The big mystery of what is behind that interface is something that your client will never have to even know about, but I assure you that the way it is put together makes it extremely versatile and adaptive, because I built it according to tried and proven principles and patterns that other people way smarter than me figured out.
Even they don't know all of the possibilities of this paradigm because there are too many to count. They don't care anyway because they are busy solving other design issues by mixing and matching principles and patterns solving really complex problems very simply.
Also, get this, the next time you set out to design something you can put that tiny little fly in that and use it there too, and there will ever be, only one place to go to maintain and improve all that is behind that tiny little fly.
I know this is probably not the answer you were looking for, or maybe you get it already, which would be awesome. It took me forever just to figure out what the hell an object even was...but once it clicked, with the help of a really smart professor, who showed me what I tried to show here; oh..
and a book called Gang of Four; then I was able to begin, and I only wish I understood it all too.
I think if you go back and look at that article, you will be able to figure out what the other answers are, I only answered the easy one(or tried). I looked at it, and all of the information is there. It might be that you just need to look at it in a slightly different way, but you will get it if you really want to know.
I'm sorry, but that is the best I can do, and be honest at the same time. If anyone tries to tell you HOW is the answer, instead of WHY, don't listen to them, because the likely don't understand it either, but not because it's hard. It would be because they didn't start out asking the right questions like you did here. I wish you well and hope that someone else comes along who can maybe explain it better than me. +1) For asking all the right questions!
Suppose the grammar is given, how to design the code generation process?
start(res) ::= template. { **how to write stuff here?? Is it true there will only be
one correct way to write this? And Let's suppose the programming language is also given** }
This is a pretty broad question, with many books an articles written on it. The general heading you're looking for is Syntax directed translation, and the classic reference is the Dragon Book
I'm writing some documentation and I just can't find the right word. Let say my class is called Writer and some people will be using it. How should I name objects that use the class (or instances of) I'm documenting?
Users of Writer class? - Program is not "a user".
Consumers of Writer class? - Sounds like somebody will eat it.
Callers or Writer class? - Sounds good for methods only.
There must be a correct word for this and I should feel stupid for asking but please, help.
Edit: just to clarify, I'm thinking about the code (not programmer) that is calling and using the class or instance of it (well, maybe I'm thing in code to much...)
I will prefer user anyway, even it is not a end-user. When you write documentation for your code the target audience is a programmer that will use your code. That programmer and their programs are users of your code.
How about "Client"?
First of all, know that there are no stupid questions, just stupid answers.
An End-User (the developer in this case) would be the user of the class.
Consuming is a verb related to aquiring resources.
Indeed calling is for functions.
Well, in the classic book Thinking in Java 2nd edition, there are two ways of using a class: by composition or by inheritance.(yes, this bit is also important)
I don't remember the exact words, but the summary would be sort of like this:
composition - you create a new object from which the target class instance would be referred.
inheritance - you create a new class that inherits (extends) the target class, provided that class is able to be inherited from.
For the exact terminology, I would say it really doesn't matter that much.
But if you want just describe the case where a new instance of such a class is created, you could say some actor (user) instantiates a new object of this class.
Hope this helps.
Edited : the terminology really depends if you think it is the user or the user's code that makes use of the target class.
I've created an interface called Initializable, but according to Dictionary.com this is not a word. Searching Google only gives about 30k results and they are mostly API references.
Is there another word to describe something that can be initialized (which is a word)?
Edit:
Thanks for the questions about it being in the constructor, that may be a better way. Right now they are static classes (as static as can be in Ruby) that get loaded dynamically and have some initilization stuff to do.
Technical people create new words all the time. (see example below) But this isn't a case of creating a new word. This is a case of a "derivation". You have take a perfectly good word ("initialize") and added a perflecty good derivative suffix to it ("able"). The resulting word initializable is a derivative word.
In short, if something can be initialized, it is initializeable. Just like it can be runable, or stopable.
Now, I don't think it will be long before a grammar Nazi points out the error of my ways here. But English is rich and expressive language. A word doesn't have to be listed on "dictionary.com" for it to be valid. Nor even on m-w.com (which I believe is a better site).
One of my favorite books is Garner's Modern American Usage. Its a great book and is more than a dictionary - it is a reference and guide on how American English is used.
"Atomic" is a good example of a word we use in software development all the time that is somewhat of a "made up" word. In a development context something that is atomic either happens, or does not happen - it cannot be divided into separate operations. But, the common definition for this word doesn't take this usage into account.
Bah! Here is a better one.... "Grep" Not in the dictionary - but yet, a perfectly good word. I use it all the time
How about -
interface ICanBeInitialized
or...(and I had a little xmas drinky...so sorry)
interface ICanHazInitialization
I think the question --- other than the pedantic one about the word, which I'll mention below --- is what the behavior you intend to identify by this "Initializable" tag might be.
It's not an uncommon style to write a private method init() in, eg, Java to do complicated initialization; since that code may be needed in several places (what with copy constructors, clone operations and so on) it's just good form. Its less common, but a valid thing to so, to have a "Forward" class that is constructed, but that is waiting for some asynchronous operation in order to be fully initialized (eg, the Asynchronous Completion Token pattern). So it's not necessarily so that this should be just in the ctor, but I'm curious what the actual behavior you want would be.
On the word, English is a somewhat agglutinating language, like German: there are grammatical rules that construct works from base words and ther syllables in patterns. one of those is the one here, "Initial" -> "initialize" => "initializable". Any native speaker will recognize "initializable" as something that has the property of being able to be initialized. So it is a value word, but one they don't have in the dictionary for the same reason that don't have separate entries for the plurals.
I see nothing wrong with making up a word for an API-like thing if the invented word is clear.
I think worse words than Initializable have been invented - such as 'stringize' and 'RAII' (I nkow it's not a word, but it's still a term that's used often, and makes me cringe every time - even though the concept is doubleplusgood).
The problem I might have with Initializable is that it sounds like an interface that does what a constructor should be doing.
If Google gives back API references for "Initializable", it seems to me like a valid name for an interface, even though it might not be a valid English word. There's nothing wrong with using a made-up word, as long as it's descriptive.
The only thing I get confused about is classes are typically able to be initialized through their constructor. How does your interface provide functionality not available through the use of a constructor? The answer to this question may provide a more descriptive name than simply "Initializable". (i.e. in what way is it initializable?)
If Initializable most clearly describes what the interface is about, I wouldn't care about trying to find another word just so it is a valid English word. As long as it's not a UI string, the priority should be in naming clarity not validity of the word in the English language.
Yes, it's fine. Programming terms don't have to be in the dictionary. Dictionary.com also doesn't like "Serializable", and we all know that one's OK.
Yes. Don't let the lack of an existing word spoil your creativity if the meaning is clear
For those questioning the use of initialize - you may want to put constructor logic in a void method so to avoid race conditions when constructing weakly coupled classes through factories.
Example Factory:
public static T CreateSingleInstance<T>(string providerName, string sectionName)
{
//create the key
ProviderKey key = new ProviderKey(providerName, typeof(T));
//check key
if (!_singletons.ContainsKey(key))
{
object provider = _singletons[key] = CreateInstance<T>(providerName, sectionName);
IInitializable initializableProvider = provider as IInitializable;
if (initializableProvider != null)
initializableProvider.Initialize();
}
return (T)_singletons[key];
}
Example Implementation Constructors that would cause a race condition
public class Class
{
public Class()
{
Factory.CreateSingleInstance<OtherClass>(null, null);
}
}
public class OtherClass
{
public OtherClass()
{
Factory.CreateSingleInstance<Class>(null, null);
}
}
To echo what other's have said, it's valid English since English, like many languages, is formulaic and you're just applying a valid linguistic formula. Looks like there's precedence in what you're doing. The SQL Server team thinks what you're doing is valid since they came up with the same IInitializable Interface (see here). It looks something like this:
public interface IInitializable {
public void Initialize (IServiceProvider serviceProvider);
}