I've wondered this in many different situations, so here I come, looking for the experts knowledge.
Let's say I have to model something that requires a collection. A simple example: an application that stores famous quotes along with their author and a set of tags or keywords. The user should be able to enter a tag or keyword and get matching quotes for it.
My question is: do I really need a class that contains my collection of quotes? Something like this:
Or would this also be correct?
I'm asking this in the more abstract way possible (after all, UML should never depend on the implementation).
I've always thought the second example (just 1 class) was incorrect, but now I'm thinking that maybe the user can press a button on some interface and that button executes some code that gets a quote stored somewhere, and the second example would also be correct?
Basically, should I always have a collection stored somewhere, even if the storing class does nothing else but just store the collection (and provide the methods to access it)?
I definitelly prefer only one class, if there is no strong reason to have another container class (especially on abstract conceptual level). Then I add the collection methods as static functions. A separate container class would only bring more complexity, more dependencies and doubts like yours. :) Doubts often indicate the lack of a real need. When you really need something, you know it.
Here an example with some explanations. I find it simple, clear, elegant and abstract, meaning non-restrictive, easy to transform to any implementation you like:
When it comes to relationships of this class to other class, then you actially have your collection, without introducing new class. This diagram shows two examples. "Other class" actually sees a collection "quotes" which is ordered, like Vector. "One more class" also has a collection of Quotes with different characteristics.
Later on implementation level you can implement it directly like this or eventually adding a Factory or Container class, according to concrete, implemention resctrictions and special reqs.
Related
To prioritize the engineering effort around Requirements in a defined way, I came to the idea to use the information already added for the FMEA.
For this I have created a Stereotype named fmeaRelevant (will be named better later), which has several Tags.
My target now is to first calculate the averages of all of these Tags and then from these the average RPN, which is again a Tag.
For this, I have already created a ConstrainedProperty, which has the respective ConstrainedParameters and Constraints.
BindingConnectors are created between the ConstrainedParameters of the ConstraintProperty and the Tags of the Stereotype.
The Stereotype is assigned to my Requirements.
However, Open ConstraintView ... does not show me anything.
Is there anything I am missing?
P.S.: I am not sure how to provide something like a source code snippet for model content. If one makes a proposal in a comment, I will add this.
You used binding connectors between stereotype properties and constraint parameters? That should not be possible, since they are on different levels. The parameters are on the model level and the stereotype properties are on the language level.
Of course, Rhapsody sometimes allows strange things, so it might well be, that there is a way to get it running.
The RPN relates to an actual hazordous situation. Your model describes this situation and all values relating to the situation should therefore be value properties of the FMEAitem. This element would be defined in a library. By the way, this is how it's done in the new RAAML-specification, which might be a useful reference.
Trying to get my head around the best way to build my applications.
Current app is based around an Opportunity; a log of potential work with fairly typical properties like Project Manager, Fee, Start Date blah blah blah.
One of the properties is Stage which up until now I have kept as a string (Won, Lost, No-Go etc.). I'm getting the urge to convert it to a class of its own although for now it will only have one property: Name, which is a string. I'm pretty sure at some point in the future the Stage object will have other properties though.
Is it crazy/overkill to create a class for the Stage property now?
It is much easier to add additional properties to an existing Class than to convert a Property to a Class in the future so if you think you may need to convert it I would say just do it.
Depends of what you see in the future for this class. If you see that it will be extend then why not? but you can always have a string and then when necessary create a class and replace it. hope it helps
There is a concept called YAGNI (You Aren't Gonna Need It) that says: Don't look too far into the future. Unless a Stage class is useful right now, just use a string property.
If you find out that you need a Stage class at some point in the future, adding it in later shouldn't be much more effort than it is now. And if you find out that you DON'T need it, than you just saved some time, and reduced the complexity of your design.
Some reading about this YAGNI principle:
http://www.xprogramming.com/Practices/PracNotNeed.html
http://c2.com/cgi/wiki?YouArentGonnaNeedIt
http://codebetter.com/jeremymiller/2009/02/17/a-quick-example-of-yagni-simplest-thing-possible-in-action/
I'm comming from the java world, and i'd like to know if there's anything that can help me understand the properties of abap development objects.... something like reflection.
Knowing that everything that goes on in ABAP is persisted somewhere inside a database, i'd like to know how would i go about finding out HOW and WHERE an object is saved.
For instance, i'd like to know if there are any functions that enumerate the fields of a structure, or enumerate the properties of an object, or if there's no such thing (but the properties still exist obviously), then what table would be holding those (so that i can create my own functions, or classes)
Also any other discoverability tricks that you know are good... I know this question is a little generic, but since i'm new to abap, i don't really know what to ask :P
Thx, you guys rule.
If you're looking for something like reflection, take a look at RTTI. This cvers the runtime structure of most of the stuff you'll come across. If you want to find out what's going on underneath the surface of the cevelopment tools, just turn on the SQL trace (ST05), open the object in question in an editor and check what tables are accessed...
It is hard to answer your question, maybe it would be easier, if you split it up in multiple questions with some specific task you want.
Some topics I remember (please verify it, I can't check it in the moment if I remember correct):
DDIC-objects are stored in tables with DD*.
Tables (and there properties) are stored in dd02l, dd02t includes the texts. dd03l contains the fields. dd04tl contains the texts of data element.
But it will not help you, if you add something to this tables. The database in background will not get the definitions.
If you want to create some dynmaic magic you may take a look to the field-symbols and assign-command.
I was just writing a small asp.net web page to display a collection of objects by binding to a repeater, when this came to mind.
Basically the class I've created, let's call it 'Test', has a price property that's an integer data type (ignore the limitations of using this type, I'm just using it as an example). However I want to format this property so it displays a currency and the correct decimal places etc.
Is it best practice to have a function within the class that returns the formatted string for the object, or would it be better to have a function in the back end of my web form that operations on the object and returns the formatted string?
I've heard before that a class should contain all it's relative functions but I've also heard that presentation should be kept in the 'presentation layer' in my N-tier app.
What would be the best approach in my situation? (and apologies if I haven't explained this clearly enough!)
Thanks!
In my opinion, both options are valid from an OO point of view.
Since the value is a price (that just happens to have the wrong data type), it makes sense to put the formatting into the data class. It's not something that's specific to the web interface, and, if you develop a different kind of user interface, you are very likely to require this formatting again.
On the other hand, it's a presentation issue, so it also makes sense to put it into the presentation layer.
For general OOP stuff, the object should not be exposing implementation details. I choose to interpret this as "avoid setters and getters when possible".
In the context of your question, I suggest that you have a getPriceDisplay() method that returns a string containing the formatted price.
The actual implementation of the formatting is hidden in the implementation details. You could provide a generic function for formatting, use some backend call, or something else. Those details should make no difference to the consumer of the 'Test' object.
Though it's not an OOP approach, in my opinion, this is a good time for an extension method. Call it .ToCurrency() which has the format of the currency...this could be taken from the Web.Config file if you wanted.
Edit
To elaborate, I would simply call .ToString("your-format") (of course this could be as simple as .ToString("C") for your specific question) in the extension method. This allows you change the format throughout the UI in one place. I have found this to be very useful when dealing with DateTime formats in web applications.
Wouldn't .ToString("C"); do the job? This would be in the presentation layer I would imagine.
I know that you can create new classes in R, but why would you want to? I've thought of two reasons:
You can use the is. function to test whether an object belongs to a particular class (classifications of objects)
To only allow certain classes of entries into slots of an object (e.g., only a string for the surnmane and only a number for a zip code in the person class).
I haven't thought of situations where these benefits couldn't be achieved fairly easily by other means or when they'd really be useful.
I hope that this isn't too open ended and more concrete examples how one might use defining classes would be great. Thanks for any thoughts.
Its called Object-Oriented programming. Look it up, but in short:
Objects encapsulate behaviour - eg the behaviour of the 'print' method for a class is specific to that class. You can then keep the code for that method on that class separate from other code. You then only have to tell your users to "print" the thing - which is something they already do - and they get a nicely custom printed version of your thing, without having to use a special print function, like "printMyThing(thing)".
Objects inherit behaviour from their parent classes - eg the 'formula' method for the glm class falls back to the formula method for the lm class (not sure if this is true, but its just for illustration.
In short, its a Good Thing.