I was reading this answer on SESE about encapsulation and getters/setters. Suppose I favor the use of immutable classes, so if a setter were implemented, it would return the a new object reflecting the change, for example:
//return a new Book reflecting the price change.
public Book updatePrice(double price){}
In the link, the answer suggested I have a method called getDisplayinformation() that returns a data structure.
(think an array indexed by an enum, a struct, or a methodless class)
Following this advice how would I return a Book with a List of authors?
public final class Author{
private final String id;
private final String firstname;
private final String lastname;
//Constructor
}
public final class Book{
private String bookID;
private final String title;
private List<Author> authorsList;
private double price;
//Constructor
}
Suppose I wanted to return a Map<String,String>.
public Map<String,String> getDisplayinformation(){
Map<String,String> displayMap = new HashMap<String,String>();
display.put("BookTitle", title);
display.put("ID", bookID);
display.put("Price", price.toString())
//insert authorsList;
return displayMap;
}
The answer you quote got half of it right. Providing getters for fields does break encapsulation, because it makes the caller dependent on some internal structure.
Now, returning a map where the caller needs to know the keys and knows what that information is, is basically not different than providing a getter for that field.
Object-orientation tries to tell us that the functionality needs to be bundled with the data. So, the Book has to have some method to present the Book. I would not call it getDisplayInformation(), rather simply display(). It can return something, and it can take relevant parameters too.
The point is, that anything returned by display() must be about the presentation, and must not be about the book. Semantics about being a book should be lost at that point, otherwise the caller will be tightly coupled.
So, it's ok to return an XML document, JSON document, HTML, a Wicket Component, whatever it is you can use for presentation that is independent of the Book.
Or, the method could take an argument to present itself to. Like AWT Component.paint(Graphics g) or something.
Note: this is actually a controversial subject. Mixed-paradigm development (a mix of procedural and ood) would argue that presentation needs to be separated from objects, while object-orientation argues that data and function belong always together.
I am working on a complex datamodel in which we have different classes with lots of attributes that we sometimes need to compare or copy partially. However, we couldn't gather them in a class because some of them overlap.
So you can better understand, let's take an example:
public class Product {
private Amount price;
private String name;
private String description;
private Color color;
private Shape shape;
private Picture mainPicture;
private Company designer;
private Company maker;
}
Let's imagine the production is outsourced and we sometimes need to copy everything but maker:
public Product copyForOutsourcing(Product product) {
Product p = new Product();
p.setPrice(product.getPrice());
p.setName(product.getName());
p.setDescription(product.getDescription());
p.setColor(product.getColor());
p.setShape(product.setShape());
p.setMainPicture(product.getMainPicture());
p.setDesigner(product.getDesigner());
return p;
}
Let's now imagine the product exists in multiple forms and we sometimes need to copy everything but shape, color and picture:
public Product copyForDeclension(Product product) {
Product p = new Product();
p.setPrice(product.getPrice());
p.setName(product.getName());
p.setDescription(product.getDescription());
p.setDesigner(product.getDesigner());
p.setMaker(product.getMaker());
return p;
}
The same way, we need different comparisons: p1.get*().equals(p2.get*()).
As you can see, it's a bit redundant and it's still worst when there are more attributes and/or more copy or comparison methods. Moreover, when adding an attribute, we always forget adding it in the copy and compare methods.
The first idea we got was to add annotations:
#Outsourcing, #Declension
private Amount price;
#Outsourcing, #Declension
private String name;
#Outsourcing, #Declension
private String description;
#Outsourcing, #Declension
private Color color;
#Outsourcing
private Shape shape;
#Outsourcing
private Picture mainPicture;
#Outsourcing
private Company designer;
#Declension
private Company maker;
That way, it's easy to compare or copy attributes using reflection, there is not redundant code, and when adding attributes, it's easy to update copy and compare methods: we just have to add annotations to the new attribute.
But what happens if Product extends an other class, let's say CompanyObject, in which attributes like "stockingLocations" should be copied in copyForDeclension.
CompanyObject shouldn't depend on annotation Declension because this annotation is Product specific. CompanyObject could even be in an other project and so couldn't be modified.
If we want to use reflection so as to avoid redundancy, then we need to specify which attributes are copied:
public List<Field> getDeclensionAttributes() {
List<Field> list = new ArrayList<Field>();
list.add(ReflectUtils.getField(CompanyObject.class, "stockingLocation"));
list.add(ReflectUtils.getField(Product.class, "price"));
...
return list;
}
The problem is that this way, we have attribute names specified as String so refactoring will probably break things and the compiler will not warn us!
So the question is: when having a class with many attributes in which several copy/comparison methods need to be specified, what is the most elegant way to implement these copy and comparison methods?
Furthermore, how to ensure that adding an attribute forces the developer to question the behavior of this attribute in the different copy/compare methods?
Probably you can have only one copy implementation and control what attribute to copy by passing List of attribute to copy (Enum to represent attribute list). Something like this
public Product copyForDeclension(Product product, List<ProductAttributes> attribuitesToCopy) {
attribuitesToCopy.stream().forEach(productAttribute -> {
switch (productAttribute) {
case PRICE:
//do copy
break;
case NAME:
//do copy
break;
default:
// throw exception, will be helpful for maintain code
}
});
}
enum ProductAttributes {
PRICE,
NAME,
//.....
}
This way implementation will be common and non-redundant and what all attributes to be considiered will be handled by caller of copy (This may be good or bad for your requirement).
I came across a refactoring functionality that looks to be useful as I learn eclipse and java. But I'm not sure how this could be useful. Is there a pattern that would benefit from this kind of refactoring? This refactoring option basically extracted out all variables into another class whose name was changed to append Data at the end.
Any examples of WHAT/WHY this kind of refactoring gives us would be really helpful.
Thank you in advance.
Extract Class is mostly used when a class has too many responsibilities; it is trying to do too much. It splits out the class into two individual classes and then transfers some functionality into the other class - obviously there will be a relationship between the classes because you still want all of the code to interact.
You can combine Extract Class with other refactoring patterns such as Move Method and Move Field that will move methods and fields to the other class in such a way that all of the code still works as intended.
This link has a good example of Extract Class: http://sourcemaking.com/refactoring/extract-class
If you had too many fields in your class and you see that this must be a extra class, you can use it.
Example:
public class Person {
private int age;
private String name;
private String street;
private int streetnumber;
}
to:
public class Person {
private int age;
private String name;
private Adress data = new Adress();
}
public class Address {
public String street;
public int streetnumber;
public Address() {}
}
While creating a Web service I decided to exchange Business Object (BO) between client and web service.
If in the future I get a request to expand my model and put some new attributes (field) in my BO and send it to the client, what would be the best approach?
So basically, each BO may have 0..n meta-fields.
Each meta-field is Key,Value like, where keys can be anything from simple data types to other BOs.
Here is a little Java code for modelling BOs, I just need confirmation that I'm on the right track.
class AbstractBO{
//optional list of meta fields for future extension
List<MetaField> metaFieldList;
//setters. getters
}
----
class MetaField {
private Object key;
private Object value;
// setters
// getters
}
----
class MyBO extends AbstractBO {
//BO specific fields
private String name;
...
}
---
TODAY
class Person extends AbstractBO {
private String name;
private int age;
//extend metaFieldList = null;
}
----
TOMORROW
class Person extends AbstractBO {
private String name;
private int age;
//list with new metafield
}
How to model Person for Tomorrow purposes?
If, as your follow-up comment implies, you actually want to send the direct object code (presumably by implementing Serializable) instead of using a XML or JSON (which is what you'd typically do when implementing a web service), then I don't know how you'd actually be able to achieve what you want.
When Java tries to recreate your object by deserializing it, it will have to match the input data against what it believes the class to be. For best practice purposes, you should be implementing serialVersionUID and changing it each time you modify your class so that when you add variables, the person on the other end won't be able to erroneously reconstruct the class that you send them if they have an old version of the code.
First of all I should probably say that the term 'constant object' is probably not quite right and might already mean something completely different from what I am thinking of, but it is the best term I can think of to describe what I am talking about.
So basically I am designing an application and I have come across something that seems like there is probably an existing design pattern for but I don't know what it is or what to search for, so I am going to describe what it is I am trying to do and I am looking for suggestions as to the best way to implement it.
Lets say you have a class:
public class MyClass {
private String name;
private String description;
private int value;
public MyClass(String name, String description, int value) {
this.name = name;
this.description = description;
this.value = value;
}
// And I guess some getters and setters here.
}
Now lets say that you know in advance that there will only ever be say 3 instances of this class, and the data is also known in advance (or at least will be read from a file at runtime, and the exact filename is known in advance). Basically what I am getting at is that the data is not going to be changed during runtime (once it has been set).
At first I thought that I should declare some static constants somewhere, e.g.
public static final String INSTANCE_1_DATA_FILE = "path/to/instance1/file";
public static final String INSTANCE_2_DATA_FILE = "path/to/instance2/file";
public static final String INSTANCE_3_DATA_FILE = "path/to/instance3/file";
public static final MyClass INSTANCE_1 = new MyClass(getNameFromFile(INSTANCE_1_DATA_FILE), getDescriptionFromFile(INSTANCE_1_DATA_FILE), getValueFromFile(INSTANCE_1_DATA_FILE));
public static final MyClass INSTANCE_2 = new MyClass(getNameFromFile(INSTANCE_2_DATA_FILE), getDescriptionFromFile(INSTANCE_2_DATA_FILE), getValueFromFile(INSTANCE_2_DATA_FILE));
public static final MyClass INSTANCE_3 = new MyClass(getNameFromFile(INSTANCE_3_DATA_FILE), getDescriptionFromFile(INSTANCE_3_DATA_FILE), getValueFromFile(INSTANCE_3_DATA_FILE));
Obvisouly now, whenever I want to use one of the 3 instances I can just refer directly to the constants.
But I started thinking that there might be a cleaner way to handle this and the next thing I thought about was doing something like:
public MyClassInstance1 extends MyClass {
private static final String FILE_NAME = "path/to/instance1/file";
public String getName() {
if (name == null) {
name = getNameFromFile(FILE_NAME);
}
return name;
}
// etc.
}
Now whenever I want to use the instances of MyClass I can just use the one I want e.g.
private MyClass myInstance = new MyClassInstance2();
Or probably even better would be to make them singletons and just do:
private MyClass myInstance = MyClassInstance3.getInstance();
But I can't help but think that this is also not the right way to handle this situation. Am I overthinking the problem? Should I just have a switch statement somewhere e.g.
public class MyClass {
public enum Instance { ONE, TWO, THREE }
public static String getName(Instance instance) {
switch(instance) {
case ONE:
return getNameFromFile(INSTANCE_1_DATA_FILE);
break;
case TWO:
etc.
}
}
}
Can anyone tell me the best way to implement this? Note that I have written the sample code in Java because that is my strongest language, but I will probably be implementing the application in C++, so at the moment I am more looking for language independent design patterns (or just for someone to tell me to go with one of the simple solutions I have already mentioned).
If you want the values to be constant, then you will not need setters, otherwise code can simply change the values in your constants, making them not very constant. In C++, you can just declare the instances const, although I'd still get rid of the setters, since someone could always cast away the const.
The pattern looks ok, although the fact that you are creating a new instance each time one is requested, is not usual for constants.
In java, you can create enums that are "smart" e.g.
public enum MyClass {
ONE(INSTANCE_1_DATA_FILE),
TWO(INSTANCE_2_DATA_FILE),
//etc...
private MyClass(String dataFile)
{
this(getNameFromDataFile(dataFile), other values...)
}
private MyClass(String name, String data, etc...)
{
this.name = name;
// etc..
}
public String getName()
{
return name;
}
}
In C++, you would create your MyClass, with a private constructor that takes the filename and whatever else it needs to initialize, and create static const members in MyClass for each instance, with the values assigned a new instance of MyClass created using the private constructor.
EDIT: But now I see the scenario I don't think this is a good idea having static values. If the types of ActivityLevel are fundamental to your application, then you can enumerate the different type of activity level as constants, e.g. a java or string enum, but they are just placeholders. The actual ActivityDescription instances should come from a data access layer or provider of some kind.
e.g.
enum ActivityLevel { LOW, MED, HIGH }
class ActivityDescription
{
String name;
String otherDetails;
String description; // etc..
// perhaps also
// ActivityLevel activityLevel;
// constructor and getters
// this is an immutable value object
}
interface ActivityDescriptionProvider
{
ActivityDescription getDescription(ActivityLevel activityLevel);
}
You can implement the provider using statics if you want, or an enum of ActivityDescription instnaces, or better still a Map of ActivityLevel to ActivityDescription that you load from a file, fetch from spring config etc. The main point is that using an interface to fetch the actual description for a given ActivityLevel decouples your application code from the mechanics of how those descriptions are produced in the system. It also makes it possible to mock the implementation of the interface when testing the UI. You can stress the UI with a mock implementation in ways that is not possible with a fixed static data set.
Now lets say that you know in advance that there will only ever be say 3 instances of this class, and the data is also known in advance (or at least will be read from a file at runtime, and the exact filename is known in advance). Basically what I am getting at is that the data is not going to be changed during runtime (once it has been set).
I'd use an enum. And then rather in this flavor:
public enum MyEnum {
ONE("path/to/instance1/file"),
TWO("path/to/instance2/file"),
THREE("path/to/instance3/file");
private String name;
private MyEnum(String name) {
this.name = name;
}
public String getName() {
return name;
}
}
Which can be used as follows:
MyEnum one = MyEnum.ONE;
String name = one.getName();
(I'm too slow once again, you already accepted an answer, but here it is anyway...)
You want to (a) prevent changes to the data held in objects of MyClass, and (b) allow only a fixed set of MyClass objects to exist, implying that runtime code should not be able to create new instances of MyClass.
Your initial example has a public constructor, which violates (b)
I'd use a Factory approach so the Factory is the only thing that can create instances, and the class doesn't provide any setters so it's immutable.
Depending on how much flexibility you want for the future, you could put the factory and the class in the same package and limit scope that way, or you could make MyClass an inner class within the factory. You may also consider making MyClass an interface separate from its implementation.
A properties file could be used to configure the factory itself.
The properties file (e.g. "foo.properties") could look something like
one=/path/to/datafile1
two=/another/path/to/datafile2
three=/path/to/datafile3
I use "Foo" instead of "MyClass" in the (Java) examples below.
public class FooFactory
{
/** A place to hold the only existing instances of the class */
private final Map<String, Foo> instances = new HashMap<String, Foo>();
/** Creates a factory to manufacture Foo objects */
// I'm using 'configFile' as the name of a properties file,
// but this could use a Properties object, or a File object.
public FooFactory(String configfile)
{
Properties p = new Properties();
InputStream in = this.getClass().getResourceAsStream();
p.load(in); // ignoring the fact that IOExceptions can be thrown
// Create all the objects as specified in the factory properties
for (String key : p.keys())
{
String datafile = p.getProperty(key);
Foo obj = new Foo(datafile);
instances.put(key, obj);
}
}
public Foo getFoo(String which)
{
return instances.get(which);
}
/** The objects handed out by the factory - your "MyClass" */
public class Foo
{
private String name;
private String description;
private int value;
private Foo(String datafile)
{
// read the datafile to set name, description, and value
}
}
}
You're set to allow only your predefined instances, which can't be changed at runtime, but you can set it all up differently for another run at a later time.
Your first method seems to me like the best and the least prone to code rot. I'm not impressed by the idea of subclassing an object just to change the file name that contains the data that will be used to build it.
Of course, you could maybe improve on your original idea by wrapping these all in an outer class that provides some sort of enumeration access. A collection of MyClass's in other words. But I think you should discard this subclassing idea.
First, you really should be limiting where you use these instances in the code. Use them in as few places as possible. Given these are file names, I expect you want three class instances which accesses the files. How many classes are required depends on what your want to do with them? Look at the Singleton pattern for these classes.
Now you don't need the constants, but could have a helper class which will read the file containing the file names and supply them to the reader class. The code to find then name could also be a method called by the static initializer of the Singleton.
The common approach is to use a map:
private static final Map<String, YouClass> mapIt =
new HashMap<String, YouClass>(){{
put("one", new YourClass("/name", "desc", 1 )),
put("two", new YourClass("/name/two", "desc2", 2 )),
put("three", new YourClass("/name/three", "desc", 3 ))
}}
public static YourClass getInstance( String named ) {
return mapIt.get( named );
}
Next time you need it:
YouClass toUse = YourClass.getInstance("one");
Probably using strings as keys is not the best option but you get the idea.