I've got a class called List_Field that, as the name suggests, builds list input fields. These list input fields allow users to select a single item per list.
I want to be able to build list input fields that would allow users to select multiple items per list, so I have the following dilemma:
Should I do that through implementing a multiple_choice_allowed property into the existing List_Field property, or should I implement a Multiple_Choice_List_Field subclass of the List_Field class?
What's the engineering principle that I should follow when confronted with dilemmas like this one?
Take a look at the SOLID principles. They'll help you in your designs. In particular, the single responsibility principle will tell you not to mix the two concerns in one class, and the Liskov substitution principle will tell you not to create subclasses that break the contract of superclasses, like what you're also proposing.
So what would be the solution in your case? You could create an abstract base class that would be agnostic to the type of selection and then create 2 subclasses, one for single selection and another for multiple selection.
Depends on presence/lack of object evolution - if you want special case, sub-classing or injecting (DI) "select" behaviour (strategy) is good.
But if you also want to allow Field_List to change its behaviour dynamically, then property or mutating method is the only way to go.
Example: Sign-up screen with different "plans" - basic, where you can only select one thing and premium, where you can select as much as you want. Change of plan will switch between drop-down and multiple checkboxes, while still having the very same object including its contents.
I would vote for property/mutate method.
Personally I would go for the Multiple_Choice_List_Field way. I don't think there is a strict standard or an engineering principle that would make you to do it one way instead of another.
The more important thing here is to choose one way to do it and follow it whenever you encounter such a dilemma. You should be consistent, but which way you go is your own choice.
I would choose the subclass because this way you won't have to bloat your List_Field class with additional checks and requirements. Of course there are other considerations such as if you need to switch the multiple choice and single choice at runtime it would be better to go for the boolean property (although subclass will work too, but doesn't feel natural to me).
The other thing is for List_Field you might need more than a single property to handle multiple choices, depending on your current implementation. For example a new property to return an array of the selected items.
Just do it the way it's most comfortable for you to build and maintain (and eventually extend).
Should I do that through implementing
a multiple_choice_allowed property
into the existing List_Field property
If you can do that, I think it's the best solution because this way you avoid class proliferation.
If in doing that you are complicating too much your List_Field class, maybe create a derived class can have some benefits regarding the maintainability of your code.
Personally, I would say neither: instead use a constructor that takes multiple_choice_allowed, and then have a property exposing ListFields as a collection (with just one element when only one is allowed, all of them when more than one is allowed). Make it readonly (which means that you should copy it whenever you return the list).
Related
I have a situation whereby a predecessor has created a class that is designed to handle the creation of Note entities that are added to the database to journal actions that are carried out by the system across the site.
At present, this class has been broken down into several CreateXYZNote methods that take an enum denoting a specific note type, and an instance of the model that drives that area of the site.
My problem is, there are so many types of notes, each used only in one or two places across the system. Each of the methods is huge, consisting of a small amount of common code, and specifics (e.g. the textual content of the note) are held within a series of switch statements based on an enum. Extremely hard to find the code relating to specific notes, and very hard to maintain at present, and it's only going to grow as new types of notes find their way into the system over time.
Has anyone got any advice or patterns that could help with this sort of situation?
The simplest solution I can think of is that I have a set of profiles held outside of this class as a dictionary (keyed by the enum values) that define the title, description, categories etc. for the notes, and this class then becomes just a means of looking up those values and creating the note, but it just feels like I'm moving the problem to another place rather than resolving it.
You could use a NoteFactory that has a INote Create(NoteType type) method. The factory could depend on a Dictionary keyed by NoteType that the factory uses to find and return the appropriate Note. This way you avoid a non-OCP switch statement.
The factory can be injected with the dictionary, using an IoC container helps here, or you can create the dictionary in the constructor.
i'm working on a tile editor. In the editor you can load a tile map. Each tile map can have multiple layers. A tile map has a list of it's layers. I now need tile map properties in the layer class (things like tile width/height e.g.). I'm now asking myself what is the best way to do this.
I could make a bidirectional relationship by introducing a tilemap property in the layer class, so that i have access to everything i need from there. But then i would have to take care of two sides of the relationship.
I could give all the needed properties to the layer class with the constructor, but then they basicly become layer properties (aka they are different objects for every layer).
Same as 2 but give the properties to the layer with "ref" paramter.
I could make a class called something like TileMapLayerProperties where i put all the properties in and then pass the object to the layer classes. Advantage would be that all the properties would be the same and only the tileMapLayerProperties-reference would be per instance. Another advantage would be the "definition" of the layer constructor becoming much shorter.
So any suggestions / tips would be appreciated.
A bi-directional association (1) might be OK or not, depending on what properties and methods a tile map contains and what a layer should be able to know and access. If a tile map has a DeleteAllLayers method and layers should not be able to call it, then layers cannot have direct access to their parent.
Creating a dedicated property object (4) seems more clean to me. That way you have one object with all necessary information that you can pass around, but it does not contain more than that, especially it does not allow calling destructive methods etc.
Passing the properties to the constructor (2) is similar to (4), but more verbose and less object-oriented. It's fine when you have 1 or 2 properties, but with more than a few it gets ugly and unmaintainable.
But there is another problem: If the properties are of immutable types (e.g. int, string), then the layers do not see changes made in the map. They only see their private copy!
I don't understand (3). How does the ref keyword change (2)? It only allows the callee to change the value of a variable passed by the caller. Or do you mean objects with reference types?
Another solution
Interfaces would be another way to solve this. You could create a ITileMapLayerProperties interface that provides all the properties and pass it to the layer's constructor. The map could either implement the interface itself or contain a TileMapLayerProperties object that implements the interface. But the layer does not need to know this.
Option 2 would work for what you are trying to do, and you may not need to include the 'ref' keyword.
I'm curious, what kind of datamembers are you trying to access from the child classes? If they are collections then you may not need the 'ref' keyword.
Another option would be to make the parent class static, but I'm not sure if this is the outcome you're looking for. Can you load more than one tile map at a time? If not, consider the static class option.
I think option is 3 is better. You can pass a reference of your ParentClass to the ChildClass and can have directly access to all public properties. I suggested it better because what ever changes you will make whether from ChildClass or ParentClass, all other layers will inherit those changes.
This is a question that I've been asking myself for quite some time so I decided to just ask you guys here.
Let's assume I have a Shop-object which contains a ProductList-object as an instance variable. Core functionality of my Shop-object is of course the ability to add a Product.
What should the public interface for adding products to the shop look like?
shop.AddProduct(product)
or
shop.Products.Add(product) ?
Thank you for your thoughts and your help.
This is really a question about whether or not to expose Products as a property, or whether to use methods. And there are already many questions on SO regarding this. For example:
Properties vs Methods
I personally prefer properties in most cases when they are not a functional part of the container object. By that, I mean that products are not an integral part of a store. A store is still a store, even if it has no products.
Products are simply objects that live within the store. As such, they make perfect sense as a collection property. Although I would probably have an Inventory property, of which Products are a property of the inventory.
In any event, methods tend to make more sense when they do something. Not simply containing something. For instance store.PurchaseProduct(product) would remove items from the products collection, but it also does something (adds money to the till, does inventory management, etc..).
Another reason to use methods is when you need to do several things when you manipulate the collection. For instance, suppose you don't want objects removed from products without also ensuring that money goes into the till, or that breakage is recorded. Then, I would still use a property, but I would make that property private and only access it via methods that perform the actions.
This is, however, largely a philosophical argument. People will have opinions either way. What matters is your own opinion.
I have a lot of dropdown lists, custom grids on my webform which are displayed to the end user. Each is populated from database through a DAL. I have separate classes defined for each. However, I am thinking about reducing the number of classes, as every new requirement results in a separate custom object.
How can I reduce the no. of classes for such requirements? Should I use datasets, lists etc. ?
"Separate classes defined for each" and "How can I reduce the no. of classes for such requirements".
Do you really create a new class for each dropdown list?
From my experience, usually I generalized it by using this class:
public class DropDownItem<T>{
public string Display{get;set;}
public T Value{get;set;}
}
It can be done using Dictionary<T> though.
Never used in ASP.Net, but it works well in Winform and WPF databinding. In Asp.Net specific, I think normal select-option is enough to supply the need.
However for gridview, you need to generalize your classes to be more generic. Declare a class which has most of the parameter, which is nullable.
Example one request has 10 parameter, 5 is mandatory and other 5 is nullable. Grid A display param 1,2,3,4,5,7,8 and grid B display param 1,2,3,4,5,6,9,10. This way, you can use one class in many more grid.
Don't use DataSets/DataTable. It is better to use more class than DataSet. The maintainability will be better when using more class than DataSet, because it is strongly typed, rather than "COLUMN_NAME" in DataSet.
I hope this doesn't sound too critical, but if each requirement being added as a class is ending up as a lot work, perhaps you can look into inheritance to clean up boilerplate/shared code in those classes.
Generally a lot of small classes (that don't overlap functionality with other classes) is a good thing. The opposite complexity problem, the "god" class, where all your code is stuffed into fewer classes, is much worse.
If my domain object should contain string properties in 2 languages, should I create 2 separate properties or create a new type BiLingualString?
For example in plant classification application, the plant domain object can contain Plant.LatName and Plant.EngName.
The number of bi-lingual properties for the whole domain is not big, about 6-8, I need only to support two languages, information should be presented to UI in both languages at the same time. (so this is not locallization). The requirements will not change during development.
It may look like an easy question, but this decision will have impact on validation, persistance, object cloning and many other things.
Negative sides I can think of using new dualString type:
Validation: If i'm going to use DataAnattations, Enterprise Library validation block, Flued validation this will require more work, object graph validation is harder than simple property validation.
Persistance: iether NH or EF will require more work with complex properties.
OOP: more complex object initialization, I will have to initialize this new Type in constructor before I can use it.
Architecture: converting objects for passing them between layers is harder, auto mapping tools will require more hand work.
While reading your question I was thinking about why not localization all the time but when I read information should be presented to UI in both languages at the same time. I think it makes sense to use properties.
In this case I would go for a class with one string for each languages as you have mentioned BiLingualString
public class Names
{
public string EngName {get;set;}
public string LatName {get;set;}
}
Then I would use this class in my main Plant Class like this
public class Plant: Names
{
}
If you 100% sure that it will always be only Latin and English I would just stick with simplest solution - 2 string properties. It also more flexible in UI then having BiLingualString. And you won't have to deal with Complex types when persisting.
To help decide, I suggest considering how consistent this behavior will be at all layers. If you expose these as two separate properties on the business object, I would also expect to see it stored as two separate columns in a database record, for example, rather than two translations for the same property stored in a separate table. It does seem odd to store translations this way, but your justifications sound reasonable, and 6 properties is not un-managable. But be sure that you don't intend to add more languages in the future.
If you expect this system to by somewhat dynamic in that you may need to add another language at some point, it would seem to make more sense to me to implement this differently so that you don't have to alter the schema when a new language needs to be supported.
I guess the thing to balance is this: consider the likelihood of having to adjust the languages or properties to accommodate a new language against the advantage (simplicity) you gain by exposing these directly as separate properties rather than having to load translations as a separate level.