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 9 years ago.
Improve this question
I remember reading (or hearing) somewhere a few years back that classes must have either an operation, an attribute and an operation, or at least an attribute as a mandatory requirement -- not empty. What I'm asking is whether it's a violation of the Software Engineering rules to have an empty class, or a class with either attributes or operations without the other.
I just want to make sure so that my class diagrams are correct for my project.
Thank you.
You can certainly have a class with attributes but no operations and vice versa.
As for a class with no attributes and no operations - Most (all?) OO languages would allow this, but of course such a class wouldn't be terribly useful except perhaps as a base class of some sort.
Engineering is all about breaking the rules and thinking outside the box.
An empty class, without properties (attributes, etc) or methods (operations, etc) is simply that: an abstract datatype which does nothing.
Many if not most type systems provide for such a thing, if one isn't predefined.
If you define your own, you should have a good reason for doing so. In C++ for example a class used as an object or tag in metaprogramming is often completely empty, because it only serves to carry information through the type system or function overloading at compile time, and ideally does not exist at runtime.
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 2 years ago.
Improve this question
It is obvious when to use a navigation property. But when should I use a inverse navigational property and when should I not use a inverse navigational property?
Should I always use a inverse navigation property when I use a navigation property to create a bi-directional relation?
Are there any guiding principles?
My guiding principle is to strive to keep things simple. I don't use them until I need them. :) Just like any other public member or method, (or any code for that matter) it should only exist if that existence is justified.
The presence of an inverse property indicates that I may treat that entity as a top-level and need to be able to refer to it's related entity. For example, a Customer contains Orders, so the question is should an Order reference back to it's Customer?
If I can query orders (irrespective of Customer) and want to be able to access customer information in those queries then it is beneficial to have an inverse property.
var orderDetails = context.Orders.Where(o => o.OrderDate == DateTime.Today)
.Select(o => new
{
o.OrderId,
o.OrderNumber,
CustomerName = o.Customer.Name
}).ToList();
As opposed to joining customer and order in a query to gain access to both customer and order details via a one-directional reference. (I tried writing an example from memory, but it got too ugly too fast. :D )
Where it doesn't make sense is to "always" have bi-directional references. For instance when you have something like an Address and an AddressType. AddressType will never need to know about a list of addresses of that type, and even if you did want to query that detail, it is easy enough to filter via the single-direction reference. It makes sense that Address (relative to the address type) is the top-level reference, where-as it makes sense that you may want to reference orders from a customer, or customer from an order.
They do not affect the generated sql. So from the point of view of database structure this is not important.
But when you are querying data from database by linq you can use that properties in "where" and "include" statements. So it gives you more options to create a query.
I'm almost always specifica inverse navigation property.
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 5 years ago.
Improve this question
I know there is scala.collection.mutable package which provides mutable data structures. But how is it done?
Can I write my own mutable data structure and pass it to a function to be changed?
Edit: The question aims towards techniques that can be used to implement mutable data types.
Read this wonderful tutorial on implementing custom collections in scala.
It should have all you need to answer the question "how it is done".
If you are just talking about any data structure, not a collection, then something like
class Foo(var bar: String)
will do. But ... don't do it. While, there are rare and isolated cases, where having a mutable structure is unavoidable, chances are, you will not encounter such a case for a long time.
My advice to you is to start with learning to write good, idiomatic scala code, and getting into the functional mindset, where data structures don't mutate under you. Learn to appreciate that.
Sure, you can. There is no limitation, that all immutable data structures should be inside scala.collection.immutable, and all mutable DS should be inside scala.collection.mutable. Standard collection classes are divided into these two packages just for convenience. You can create your classes, where you like to do it.
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 5 years ago.
Improve this question
Can we implement one concept in terms of other ?
Objects in terms of higher order functions?
Higher order functions in terms of objects?
Yes.
Objects in terms of higher order functions?
If your language has records, then you can implement objects as a record of closures closing over a common environment. In fact, that's exactly how objects are implemented in ECMAScript. (In ECMAScript, records are confusingly called objects, though.)
If you don't have records, or you subscribe to the message-oriented paradigm of OO, you can use a selector function instead, which takes the "message" as a parameter and returns a closure based on the message. This is how pretty much all object systems in Scheme work, for example Oleg Kiselyov's Purely-functional Object-Oriented System.
Higher order functions in terms of objects?
In fact, Scala implements functions using objects.
An object with a single method is isomorphic to a function.
An object with a single method and some instance variables is isomorphic to a closure.
An object with a single method that takes an object with a single method as parameter or returns an object with a single method is isomorphic to a higher-order function.
That's exactly how functions are implemented in Scala (with a method named apply), Ruby (with a method named call), Python (with a method named __call__), and Java (as instances of a so-called SAM interface, an interface with a Single Abstract Method).
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 8 years ago.
Improve this question
I wish to copy (in a nested manner) values from one object tree to another. In Java I would have used something like Orika.
My particular use case is building a sequence of message deltas to generate a latest state.
Scala favours immutable values. Don't think in terms of copying - think in terms of creating a new object tree that's a transformation of the previous object tree.
You might like to use Shapeless' generic zipper support, which can apply a transformation anywhere in a nested structure of case classes or similar.
I don't understand your use case in terms of your question - perhaps you should be more specific about what you want to do. If you want to apply a message delta to a message to generate a new message, that's a case for Lenses, which are also available in Shapeless, although the implementation in Monocle is supposed to be better.
It shouldn't be necessary to use something that relies on runtime reflection - Scala is expressive enough to implement these kinds of things in a typesafe way.
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 4 years ago.
Improve this question
One common aspect of most large projects is the need for common tracking data on many Domain Entities. For instance, most large projects, track the following properties for many Domain Entities:
DateTime DateCreated
User CreatedBy
DateTime LastModified
User LastModifiedBy
This data is pretty self explanatory, the data is used to track who did what when to a Domain object.
The question is what's the best way to handle this tracking data when designing the domain model for a large application.
The classic way is to use a base class and then have the relevant domain classes inherit from that base class. But this sets off my favor composition over inheritance alarm bell. The more large projects I've worked on, the more I reject inheritance out-of-hand, but that's not to say there are situations where it is the best option, perhaps in this case, for instance. An alternate inheritance solution would be to use an interface, but while this solution is less coupled, I don't see many examples using this approach on domain entities.
The second way would be to use composition to add a tracking object of sorts to each domain entity. The only problem with this is that the data-layer would have to be specifically instructed to not represent these as a separate table. A minor task, but one that is hard to justify if there is no pay-off.
The final way to handle tracking data is to configure the data-layer to do this transparently. I think it is probably possible to do this with Entity-Framework, but not having implemented this solution in the past, this would be the most upfront time intensive solution. It is difficult to foresee if this solution would be worth the trouble.
While this question may seem objective, this is actually a common task that most large projects have to deal with one way or another.
What is the best way to design a domain model and/or a large project for tracking metadata?
Best practice is often subjective and can cause as many problems as it solves. When should you inherit? When should you compose? Scholars spend years arguing the toss over the minutiae of a problem. Basic inheritance with a simple interface is pragmatic and effective. If it's a standard feature for all your entities then inheritance is probably the better option.
I have a base class with the audit properties and implemented an interface for these properties. I intercept the call to the context.SaveChanges() with the following code. It's simple and it works. It could be extended to fail if any tracked entity does not implement the IAudit interface.
public override int SaveChanges()
{
var entities = this.GetChangedAuditDataEntities();
foreach (var entity in entities)
{
this.SetModificationInfo(entity);
}
return base.SaveChanges();
}
private IEnumerable<IAuditData> GetChangedAuditDataEntities()
{
return (
from entry in _context.ChangeTracker.Entries()
where entry.State != EntityState.Unchanged
select entry.Entity)
.OfType<IAuditData>();
}
private void SetModificationInfo(IAuditData entity)
{
entity.lastModifiedBy = _currentUser.Name;
entity.lastModified = System.DateTime.Now;
}
This is one of those questions that does not automatically have a "correct" answer. If Jon Skeet were to answer it then it would be considered best practice. The only other correct answer will have to confirm your particular bias or at the every least strike the right intellectual note.
Years ago inheritance was rife and one of the many push backs from this has been the "value composition over inheritance" mantra. Fine, but inheritance has it's place.
I would suggest that any architectural layer that has many of the same type of object, such as a domain object (the words "domain object" imply common layer) can be greatly enhanced by having a common base class. System.Object is a good example of it. I'll give you another example. When we were defining the exception decorators for our solution we decided to extend the ToString() method to create a value that would uniquely identify the object.
public override string ToString()
{
if (this is IAuditData)
{
IAuditDataidentifiable = this as IAuditData;
return string.Format(#"{0} {{ id: {1}, ETag: {2} }}",
identifiable.GetType().Name,
identifiable.id,
identifiable.ETag);
}
else return base.ToString();
}
7 lines of code - pragmatic, simple and effective. From your question you sound wholly opposed to inheritance which must be borne from many a burnt finger. Me too ;-) but I still assert it's the better option in this instance.
I like what qujck has said in his answer and his comment but i would like to add something, if the tracking information represent an infrastructural concept i would go and put them in some infrastructure layer responsible for auditing or logging or etc .., otherwise if they are domain concepts i really like to keep them were they belong in the domain model layer and in this case i would use a complex object (value object) to represent them and to relief my self of the burden of setting them manually whenever i create a tracked object i would define a method that is called by my factory or IoC container whenever a tracked object is requested, my point is centralize change and keep concepts where they belong.