I'm looking at the publicly available model "210 King - Autodesk Toronto.rvt" which I upgraded from 2016 to 2018 (original 2016 version here). When I select a stairs object in the model, it has an "Actual Tread Depth" in the Properties Panel.
I want to access this tread depth in the API. In the sample project that ships with Revit, the stairs are of class Autodesk.Revit.DB.Architecture.Stairs (derived from Element) which has an ActualTreadDepth property. But in this model, the stairs are all just objects of class Element. Casting them to Stairs throws an exception.
Two questions:
How can I access the tread depth?
Why aren't these of class Stairs? (I'm new to the Revit API)
You can access parameter values directly on the Element class. There is no need to cast to Stairs. That makes no difference whatsoever to the parameter access.
If you are new to the Revit API, please take a look at the getting started material. That will answer this question in more depth, and many others as well.
The answer to your 'why' question will help much, I'm afraid... historical reasons, the Revit BIM paradigm, underlying product features, you name it... There are often several different ways to represent objects in Revit. Element is the catch-all base case, as you have noted.
If the model you are working with was created using Element to represent the stairs, they may not have the property you are looking for. In that case, you may have to resort to other means to determine a useful value, e.g., (pretty complex) geometrical analysis.
Related
I'm having an issue with naming of my types, generally it applies to all of my projects.
I'm working with CQRS and many times i have different layers of my application that refer to similar 'context' of a data.
For example i have a Player context which is spread across query model, write model, domain model etc.
Basically my question is that if some class/struct/data type is referring to specifically 'Query' type, should i name it as PlayerQuery or QueryPlayer.
From my understanding the 'PlayerQuery' implies that it is a query of a player data, on the other hand 'QueryPlayer' implies some kind of 'Query' behavior.
It has been quite a while when i started coding but i still struggle with properly naming things.
It feels like the 'PlayerQuery' is better approach here.
Are there any books or online resources where i could tackle this issue?
Thanks much
It has been quite a while when i started coding but i still struggle with properly naming things.
A great quote that is relevant here 😋 :
There are only two hard things in Computer Science: cache invalidation
and naming things.
-- Phil Karlton
You are having this problem because you are trying to approach the problem with a CRUD mindset, whereas CQRS (or CQS) advocates focusing on the actual interaction. Even when different parts of the application share player context, the reason for its usage will be different.
As examples, you will be:
Querying for a paginated list of players
Asking for a single player's detail
Saving an individual player's data
Bulk-updating an attribute in multiple player details
In each of these interactions, you should take the interaction itself as a cue to name the Query/Command/DTO object.
So the data class names could be:
PlayersList
PlayerDetailForQuery
PlayerDetailForSave
PlayerDetailsForBulkUpdate
An improvement would be to suffix each class name with the type of object:
PlayersListParams
PlayersListResult
PlayerRow (or) PlayerItem (or) PlayerDetail
PlayerEvent
PlayerSpecification
The best implementation would be to combine the interaction with the type of object:
FetchPlayerListParams
FetchPlayerListResult
GetPlayerDetail
BulkUpdatePlayerParams
SavePlayerCommand
PlayerSavedEvent
The most important thing is, once you choose a convention (like Detail instead of Item or Row), be consistent in its usage all over the code.
In my previous question I was trying to achieve the idea of ordering the classes. Although the example I presented wasn't appropriate.
So here is the situation I want to ascribe by UML class diagram:
In ODT document I have something called figure. The figure is comprised of two atomic elements: image and title(of the image). The standard allows me to put the title, either on top of the image or bellow the it. Although In my application the title will always be beneath the image like this:
So in my case I want to submit the (more specific) information that the title must be beneath the image (although the standard does not obligate so). Thus I came up to the idea of making order in my class diagram (this is first, then this, then this, etc...). Because in my case that matters.
Here is my despaired attempt:
Is there any approach to present that information through a UML Class Diagram?
In the UML meta-model, there are meta-elements called Class and Property. An instance of a Class meta-element (e.g., called Figure) may own instances of a Property meta-element. Each instance of a Property meta-element has a type (e.g., Image and Figure). Both of the instances of the Property meta-element in your model are unnamed, which, unfortunately, makes it difficult to refer to them. Nonetheless, all of the instances of the Property meta-element that an instance of the Class meta-element owns are ordered. When you create a property in a UML tool, you generally add it to the end of an ordered list.
In your diagram there are two unnamed properties that are already ordered (implicitly, based on which you created first in the tool). This order can be seen and changed in a UML compliant tool. Here is an example UML model:
I strongly recommend you name all your properties, as I have done in my example model. For example, I named them title and image, starting with a lower-case letter. Among other benefits, that way you can see which is which more easily when you reorder them.
Here is a specification window in a professional tool called MagicDraw, where you can drag properties into the order you like:
You could change the order to say that the image comes before the title.
P.S., in an analysis model, if this ordering is a rule that's important in the problem domain, I would actually show an explicit association between Image and Title having association ends called something like comes before and comes after.
I'm modeling an app which will let users look for real estate properties. So it's going to be a website where users will be able to look for rentals and sales on houses, flats, castles, grounds, shops, parkings, offices. According to that, I'm hesitating in the class diagram. Should I generalize all the type of real estate properties, written above, from the class RealEstateProperty or should I just associate to it a class TypeOfRealEstate, knowing that the type "Ground" for example can be as well a real estate property as the ground of a property like a House or a Castle. Also a parking can be a real estate property as well as a parking of a House.
Anyone has an idea of what's the best way to do that ? Thanks in advance.
It depends of what features of different RealEstates your system has to implement. A class's features include attributes, methods and associations.
If all your potential RealEstates have same features, for example ID, type, price, date and responible agent, and you don't need to firther differenciate among them, than the associated type will do the work. Model RealEstateType as an Enum (or even class, if you expect to add new types) and associate it to a single RealEstate class.
If different RealEstates, on the another extreme, need to have different features, you will need to inherit those from the base abstract class. For example, Ground have an attribute "area", while building has "number of floors". Even methods can be different, or associations.
Following your example, you would like to link Ground to House. This is much cleaner in the second version - just an association between Ground and House class. In one-class version, you would have to link the RealEstate with itself and add spacial restrictopns (very "ugly" design).
In summary, try to think about the features of different RealEstates and make your RealEstate hierarchy based on their differences.
You can end up with a single class or several dozens of them. :) Try to keep this hierarchy as simple as possible (less classes), but enough to mark their different features clarly.
After some confusion with mixing use case and class diagrams, managed to clear some doubts and come up with the following class diagram. Felt more comfy with this than use case. Hope am not wrong. Would like some feedback on any errors and improvements on it. Thank you.
Question:
A new library has books, videos, and CDs that it loans to its users. All library material
has a unique identification number and a title. In addition, books have one or more authors,
videos have one producer and one or more actors, while CDs have one or more artists.
The library maintains one or more copies of each library item (book, video or CD). Copies of all
library material can be loaned to users. Reference-only material can only be loaned for a
maximum of two hours and can’t be removed from the library. Other material can be loaned for
up to two weeks. For every loan, the library records the user, the loan date and time, and the
return date and time. For users, the library maintains their name, address and phone number.
Draw a class diagram for the description above.
Class Diagram: link to diagram
Don't use notes for multiplicities 1..*. Edit associations or their ends instead and write it there.
Write multiplicities on ends, not in the middle of the line.
Arrows should be subscribed by names of attributes.
Libraries can have many Videos, books, CD's and so on. So, there multiplicities should be in both ends.
No arrows on the line is the same as arrows on both ends. Check it on the right sides.
Write attributes inside blocks when they are of types not present on the diagram. If they are not, put their names on the opposite ends of the associations, near arrows.
You should use some empty diamonds on the left side.
You should decide the multiplicity of the producer.
Divide Title from Copy. And maybe, from Edition.
Don't mix plural and singular - hold to some system. I use plurals only for collections, but you needn't take it, of course. Plurals in class names are senseless - all classes apart from singletones have many instances.
You don't need toconnect library to CD and Video - they are merely subsets of Books. And books already are connected. The same with three lists in the Library block.
Loan should be connected to Book.
According to standards, loan() is a constructor of the class Loan. It can't be in another class.
Well this time the question I have in mind is what should be the necessary level of abstraction required to construct an Aggregate.
e.g.
Order is composed on OrderWorkflowHistory, Comments
Do I go with
Order <>- OrderWorkflowHistory <>- WorkflowActivity
Order <>- CommentHistory <>- Comment
OR
Order <>- WorkflowActivity
Order <>- Comment
Where OrderWorkflowHistory is just an object which will encapsulate all the workflow activities that took place. It maintains a list. Order simply delegates the job of maintaining th list of activities to this object.
CommentHistory is similarly a wrapper around (list) comments appended by users.
When it comes to database, ultimately the Order gets written to ORDER table and the list of workflow activities gets written to WORKFLOW_ACTIVITY table. The OrderWorkflowHistory has no importance when it comes to persistence.
From DDD perspective which would be most optimal. Please share your experiences !!
As you describe it, the containers (OrderWorkflowHistory, CommentHistory) don't seem to encapsulate much behaviour. On that basis I'd vote to omit them and manage the lists directly in Order.
One caveat. You may find increasing amounts of behaviour required of the list (e.g. sophisticated searches). If that occurs it may make sense to introduce one/both containers to encapulate that logic and stop Order becoming bloated.
I'd likely start with the simple solution (no containers) and only introduce them if justified as above. As long as external clients make all calls through Order's interface you can refactor Order internally without impacting the clients.
hth.
This is a good question, how to model and enrich your domain. But sooo hard to answer since it vary so much for different domain.
My experince has been that when I started with DDD I ended up with a lots of repositories and a few Value Objects. I reread some books and looked into several DDD code examples with an open mind (there are so many different ways you can implement DDD. Not all of them suits your current project scenario).
I started to try to have in mind that "more value objects, more value objects, more value objects". Why?
Well Value objects brings less tight dependencies, and more behaviour.
In your example above with one to many (1-n) relationship I have solved 1-n rel. in different ways depending on my use cases uses the domain.
(1)Sometimes I create a wrapper class (like your OrderWorkflowHistory) that is a value object. The whole list of child objects is set when object is created. This scenario is good when you have a set of child objects that must be set during one request. For example a Qeustion Weights on a Questionaire form. Then all questions should get their question weight through a method Questionaire.ApplyTuning(QuestionaireTuning) where QuestionaireTuning is like your OrderWorkflowHistory, a wrapper around a List. This add a lot to the domain:
a) The Questionaire will never get in a invalid state. Once we apply tuning we do it against all questions in questionaire.
b) The QuestionaireTuning can provide good access/search methods to retrieve a weight for a specific question or to calculate average weight score... etc.
(2)Another approach has been to have the 1-n wrapper class not being a Value object. This approach suits more if you want to add a child object now and then. The parent cannot be in a invalid state because of x numbers of child objects. This typical wrapper class has Add(Child...) method and several search/contains/exists/check methods.
(3)The third approach is just having the IList exposed as a readonly collection. You can add some search functionality with Extension methods (new in .Net 3.0) but I think it's a design smell. Better to incapsulate the provided list access methods through a list-wrapper class.
Look at http://dddsamplenet.codeplex.com/ for some example of approach one.
I believe the entire discussion with modeling Value objects, entities and who is responsible for what behaviour is the most centric in DDD. Please share your thoughts around this topic...