I'm confused about academy's question "Which data types do support data inheritance?"
After I've listened to all the videos and read all the documentation about this chapter I still get error on this question.
I tried to answer with Blocks and Object Bricks as documentation mentioned, but still get an error.
MickSt is right, all except Field Collections.
The academy videos are in most cases very confusing, at least to me. What helps is to practice yourself with some custom classes. Create an instance of a custom class with all those data types and then create a child instance. You will quickly see which types get inherited and which don't.
every data type does, except fieldcollections
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.
I have done a web site project in PHP using mySQL at school, which was not object oriented but that was in a manner on which I want to display my content. Then I changed the same project into object orientated classes where I use same CRUD queries in functions of that classes and they interact with a DBWrapper class. Or can say, I just cut the php content and pasted it into the functions and and call that functionality through object. that all was done without documentation. But now i am making a project in .net with documentation how ever its a web based app actually and i have the idea of getting data from database trough queries and o of course c# is different but CRUD is something which is similar in any language. so as i had decide first this thing will display and from thing the next this thing will display etc. about codding than how should i know my class diagram is the same as what i am getting and what that actually is. because i will connect both classes as i wnt to display . and plus is Do we write object of other class as an attribute of second class if that is going to use in it.
Most class diagrams I've seen and made include only the business model entities. Most of the time UML diagrams are used to communicate and document the workings of the system. I like to think of them as pseudo-code.
Please refer to this other question as well: https://softwareengineering.stackexchange.com/questions/190429/what-classes-to-put-exactly-in-a-class-diagram
However, if you feel your implementation ended up with a lot of helper classes then it's probably good to review your system's structure to make sure you are coding "object oriented". Actually making the class diagram is supposed to help you realize what you can improve.
I suggest you also take a look at design patterns. This link might be useful, as you mention experience with C# http://www.dotnettricks.com/learn/designpatterns
A diagram I made in the Microsoft Paint program to better understand PHP Objects.
Ok, so I have been reading up on php objects recently and they are becoming quite confusing the more i get into interfaces and encapsulations. I also seem to be confusing classes and objects, but now I am fairly certain that (as my diagram shows) Classes are actually "bigger" than objects, if you will- that objects are just new instances (or occurrences) of a class. I am aware of the crudeness of my drawing, but can anyone out there tell me if i am on the right track? I also referred to "interface" between properties and methods because, as i understand it, interface is the process by which methods (or functions within an object) can alter properties in some way. Correct me if i'm wrong.
In the book I'm reading "Learning PHP, MySQL & JavaScript: with Jquery, CSS, and HTML5" by Robin Nixon (5 Stars), I was given an example on creating and interacting with an object. I tried to alter the code (which was originally created to deal with 'Users' on a social media network) to instead echo out to the browser that 2 objects in the "Married" class would be Maj Kanaan, the Husband ($object1) and Wife Kanaan, his Wife ($object2), but with 3 properties: first_name, last_name, and title (husand or wife). However after trying several different things i came to believe that arrays should be used in this situation or at least the __construct method, but i am missing something big here. Can anyone help? Please and thank you. I really have no code to post as an example because everything i tried was way off so i just deleted it all. All i have in my feeble explanation. Hope someone is able to work with that. Thanks again!
-your friend Maj
"Classes are actually "bigger" " not certain where you are going with that but no. Quoting a title a professor forced on one of my early programming classes "Objects have class". Classes describe objects, objects are instances (actual manifestations of) classes. Classes are just a blueprint that don't do anything at all. Objects don't exist without that blueprint. You might find Differences between object and class in php useful.
Interfaces are actually templates for classes. A class can implement an interface. It's not really a go between methods and properties, but defines a set of properties and methods that a class that implements it should have defined. Most of the time one wouldn't need to use an interface unless you are working with libraries or similar shared code.
I read many articles, and saw a lot of images and I can't answer the question whether objects of View classes or DB classes should be contained on the sequence diagram or it should be more generalized?
All classes that are going to relevant to the design of the operation contained within the sequence should be there.
By making too many things generalized you risk missing important detail. I tend to include references in my sequences from the UI element all the way to the DB. If you are worried that the View and the DB are not fixed and using concrete refs will make your disgram incorrect. This shows that the design will need a close look! Maybe the contract between the view and the middle tier and the DB and middle tier needs to be better defined. Then all you have to do is include references to the contract in a general diagram and further detail in seperate diagrams for each implementation.
You can see the depth that many go to in this intro.
Remember, UML is supposed to be about good communication of ideas/designs. Do what conveys all the iformation that is needed in the simplest way possible!
Im new to working with Domain Models so forgive me for asking an elementary question.
If a Domain Object has a 1-many relationship with another Domain Object but logic that uses the first object works with only a subset of that objects related objects, what is the best way to expose this subset?
For example, say a Person is related to many Orders but some external logic needs to examine only the "Dispatched" Orders associated with a Person. Should the Person have a DispatchedOrders property, along with other properties for other subsets (such as CompletedOrders etc) or is this bad design? Assume for performance reasons I cant filter the objects in memory and must use SQL to pull back only the subset I'm interested in.
Thanks
If you're using SQL to find the set you're interested in, you're in a perfect world. Relational queries are all about finding that sort of thing. Find the perfect query, and then just figure out what the class of the result tuples are, i.e., an object for each result tuple, and process them appropriately.
In your example, you want a set of "Dispatched Orders", which whatever person information necessary attached to each one.
I think you have the right idea - DispatchedOrders would tell me precisely what collection of object you are returning to me. As Curt said, you are in good spot as you can use SQL / stored procedure to fetch your data.
One caveat - be sure that the domain matches the business process and is not an interpolation of you understanding of that process. That is - why does a person have primacy over an order and what corner are you painted into when you construct other objects. Does a line-item contain an order as well, and does this lead to object bloat? Discussions with your client should help shape the answer.
Rob Conery of SubSonic fame has a good discussion of these types of issues. It's worth listening to.