Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 8 years ago.
Improve this question
I've been searching and reading about object serialization and related subjects. However I can't think of any use-cases.
Or what is the motivation or situation in which one must use it?
Follow up question: If serialization is to save the state of an object, why is Java's object serialization necessary? Can't the object's configuration be saved in a text file and send that over network instead?
Serialization is very powerful and has multiple uses, besides the already mentioned by other users:
Sometimes you want to deep copy an object and a simple way to do it without falling into a reflection nightmare is by serializing it: How do you do a deep copy of an object in .NET (C# specifically)?
Another could be data validation. Normally when you plan to transfer objects across the wire you create an XML Schema that defines your message structure, you then generate classes from that schema which will turn into objects that you can transfer. Before sending your objects you want to serialize , for example to XML, to preserve the object state, then send that stream of data and on the other end validate your incoming XML message against the schema to make sure it is complies with your pre-defined structure and then deserialize into an object to do any object-oriented manipulation required.
Check MSDN: http://msdn.microsoft.com/en-us/library/vstudio/ms233843.aspx
Serialization allows the developer to save the state of an object and recreate it as needed, providing storage of objects as well as data exchange. Through serialization, a developer can perform actions like sending the object to a remote application by means of a Web Service, passing an object from one domain to another, passing an object through a firewall as an XML string, or maintaining security or user-specific information across applications.
Sometimes you need to store the state of an object. This article covers the topic pretty well. Quoting from the article on reasons to serialize:
Serialization provides:
a method of persisting objects, for example writing their properties to a file on disk, or saving them to a database.
a method of remote procedure calls, e.g., as in SOAP.
a method for distributing objects, especially in software componentry such as COM, CORBA, etc.
a method for detecting changes in time-varying data.
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
I am working in a Haskell project that is composed of multiple microservices. There are certain types that are needed by multiple services at the same time and therefore are defined in separate libraries that are imported by whichever needs them (each type is versioned). But there are things about it that make me uncomfortable and I was wondering which are the best practises regarding that topic. In particular:
I don't know how to handle instances of shared types. In order to avoid orphans the instances must be defined in the type's module for each of the types. But then there are instances that are not needed by all the microservices that import the package and have to be included regardless, potentially adding redundant dependencies to the microservice. An example would be a datatype T that is shared by a frontend and a backend. It has an instance of Store in order to be stored in a database that is not needed by the frontend, but still makes the frontend depend of the store package.
In order to avoid the previous issue I could introduce a wrapper every time the type has to "leave" a microservice to represent that type going through the wire. In the previous example I would have a Storable T which would have an instance for Store. This adds quite a lot of overhead to the overall development process though.
Is it even a good idea to share the types or should each microservice define its own representation of each type, so nothing has to be shared? So for a type T a microservice MA would have a representation A.T and an instance to serialise it in order to send the data to a microservice B which would decode that data into a representation MB.T.
And finally, regarding the logistical side of the matter,
What's the most convenient way to structure the project? Would a monorepo be a better choice than having separate repos/submodules?
Maybe related to the previous one, is there any way to find out automatically which microservices should be redeployed when one of the shared libraries is modified because the changes in the library affect a piece of code that is being used by the microservice?
I know I'm spitting into the wind here, but since.
these are your types for your microservices in your project;
you want to separate instances from the type definitions only as a mechanism to separate concerns and not to "open" the type definition to random instances defined all over the place;
you presumably aren't planning to release this as a general-purpose library for others where some miscreant would define an incompatible Store instance on one of your types;
then it seems reasonable to assume that your orphan instances -- despite being orphans -- can reasonably be taken as globally unique instances defined for those type/class combinations. So, this would be a justified use, if ever there was one, of -fno-warn-orphans.
The alternatives you mention for avoiding orphans (newtype wrappers and per-microservice type definitions) sound tiresome and error-prone, respectively, so much so that it seems preferable to keep the instances with the types despite the unnecessary dependencies.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 6 years ago.
Improve this question
I am trying to create a design class diagram based on the use case below:
Preconditions: User is logged in
The system presents the list of expense claims that have been authorised for payment.
The user selects an expense claim from the list.
The system shows all the items recorded under it.
The user selects one of two options: (a) to confirm the claim for payment, or (b) to review
it further.
IF option (a) is selected THEN
5.1 The system records the confirmation of payment and notifies the accounts
department.
ELSE
5.2 DO EXTEND Review Claim
END IF
How do I decide which class (between account and system) is responsible for which attributes and operations? Do I decide based on my own interpretation or is there an established method?
This is what I have so far: design class diagram
Designing a class diagram is usually something that is open to the interpretation of the person making it. Not sure about other methods of going about this, but this is how I usually approach this problem:
Identify the types of objects (i.e. classes) that exist within the scenario. These are individual items that exist within your scenario (e.g. User, ExpenseClaim, ExpenseItem). A good practice for identifying these are items that usually have pieces of data (i.e. properties) or perform a function (i.e. methods). In general, you may want to err on the side of identifying as many things as possible as the idea is that each class is supposed to do a specific thing and no more than that (you will probably revise this when carrying out the later steps). However, don't confuse objects with actors - the system is actually what the whole class diagram explains so it should never be considered as a class.
For each type of object, look at the data they contain and translate them into either properties or relations onto other types of object. Really try and limit the amount of data that each object has; if one object has a lot of properties, it is probably ripe for splitting it up into multiple objects. Taking the example of ExpenseClaim and ExpenseItem, its clear that each ExpenseClaim has a list of ExpenseItem, so you might want to link these with a composition arrow.
Now lastly look at each one and think about the things that other objects might try and do to change the data that the object has - this will probably be your methods. For an ExpenseClaim object it will probably have a confirm() method for changing the state of an isConfirmed::boolean property. Again, really try and limit the amount of functionality to the specific role that the object plays - if an object has too many functions or a function that doesn't really suit it, it probably means that there is another (new) object that will suit it better.
I am having a bit of trouble implementing the Repository pattern, due to some confusion.
As far as I can tell now, a Repository should behave like an in-memory collection of objects, so if I do say:
$users = new UserRepository(new UserMapper);
$users->findAll();
The Users repository will load and return an array of User entities. Now I can either use them for just reading data, or can update the data on any particular entity, and invoke a save() method on the Repository that will utilize the Mapper to save the loaded entities back to the data source, with the updates that have been applied.
What I am wondering is if that is a correct understanding.
Should the add() method add an entity directly to the data source, or only to the collection within the Repository?
Likewise for remove(); should this method remove an entity from the data source, or only from the Repository.
The confusion stems from the fact that some implementations I have seen in tutorials have both add()/remove() methods, alongside save()/delete() methods. Is that the correct approach?
I've been developing using DDD techniques for around 6 months now and always use the save and delete methods, the save should persist the data to your persistence layer, the delete should remove from your persistence layer.
Saying the above, there is no reason why it shouldnt add to your collection.
p.s check out the dddinphp Google Group, theres an active community purely for these questions
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 5 years ago.
Improve this question
I'm referencing a book by bennet, s et al (2002). Object-orientated systems analysis and design 2nd ed. McgraawHill:Maidenhead.
In the book when describing requirements analysis Bennet refers to three types of 'analysis class stereotypes' as a way of breaking down use case diagrams into defined classes.
The first two seem fairly straight forward : an boundary class is the terminus between the user and the system, or the system and other systems that it relies on. An entity class is the 'information and associated behaviour of some phenomenon or concepts such as an individual, a real life object, or a real life event' i.e. the data that you're trying to model or store, such as a person.
Finally, there are control classes which 'represent co-ordination sequencing, transactions and control of other objects'. This definition isn't as clear as Bennet states:
"meanwhile, the boundary class represents interaction with the user and the entity clases
represent the behaviour of things in the application domain and storage of information that
is directly associated with these things"
This rather begs the question what exactly is an application or software domain in this context? How does the control class fit in with these other two definitions?
I think this offers a best case solution :
http://epf.eclipse.org/wikis/openuppt/openup%5Fbasic/guidances/concepts/entity%5Fcontrol%5Fboundary%5Fpattern,%5FuF-QYEAhEdq%5FUJTvM1DM2Q.html
Entity objects represent the persistent information tracked by the system.
Boundary objects represent the interactions between the actors and the system.
Control objects are in charge of realizing use cases.
Modeling the system with entity, boundary, and control objects provides developers with simple heuristics to distinguish different, but related concepts.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
I'm trying to understand what a responsibility actually is so I want to use an example of something I'm currently working on. I have a app that imports product information from one system to another system. The user of the apps gets to choose various settings for which product fields in one system that want to use in the other system.
So I have a class, say ProductImporter and it's responsibility is to import products. This class is large, probably too large.
The methods in this class are complex and would be for example, getDescription. This method doesn't simply grab a description from the other system but sets a product description based on various settings set by the user. If I were to add a setting and a new way to get a description, this class could change.
So, is that two responsibilities? Is there one that imports products and one that gets a description. It would seem this way, almost every method I have would be in it's own class and that seems like overkill.
I really need a good description of this principle because it's hard for me to completely understand. I don't want needless complexity.
The 'responsibility' is defined in this principle as a reason to change. In this case the single responsibility of your class would be to import products. If the way of importing product changes, then the class should change.
The intention is to avoid having different things changing the same class at the same time. For example if your product importer class also defined its output format, it would then have two responsibilities, as likely the output format is totally unrelated to the mechanism of importing the data.
Now, that the class is huge and that getDescription() also sets a description are not a direct violation of the SRP, but of different principles. Namely, that you should avoid having huge classes (shows a lack of design) and each method should do a single thing (which would be kind of a more concrete version of the SRP.)