I have the following problem illustrated by the pseudo code below (might not make a whole lot of sense):
class Form {
boolean loggedOn = false;
String id = null;
...get/set shared methods
}
class SearchFormA extends Form{
String name = null;
String email = null;
...get/set methods
}
class SearchFormB extends Form{
String age = null;
String gender = null;
...get/set methods
}
class Search {
public Search(HttpServletRequest request){
String searchMode = (String) request.getSearchMode();
if("0".equals(searchMode)){
SearchFormA formA = new SearchFormA();
formA.setName((String)request.getParameter("name"));
formA.setId((String)request.getParameter("id"));
...populate form
request.getSession().setAttribute("formA",formA);
}
if("1".equals(searchMode)){
SearchFormB formB = new SearchFormB();
formB.setAge((String)request.getParameter("age"));
formB.setId((String)request.getParameter("id"));
...populate form
request.getSession().setAttribute("formB",formB);
}
...rest of code
}
}
What i've done is using reflection, but is there any other way to do it at compile time?
I've also tried Factory method, but the classes SearchFormA and SearchFormB does not have much in common.
EDIT: ok basically, in this case i have 4-5 searchModes, each searchMode has a different form. Between these forms they share certain similar fields. In future i might have to add 10 searchModes and it's going to be repeating alot of populating of the same fields.
Unfortunately your code is too much "pseudo." For example it is not clear where do you take searchMode from. Also initialization of your specific forms is hard coded. I believe that in real life all these data is taken from class Data.
So, I assume that class Data contains name, age, id. Now the question is how does Data class contain this data. Special fields? Generic hash table?
In any case I think that the fact that you have some kind of "general" code (Search class) and have to create special forms is a bad pattern. You should use some MVC framework that populates your specific form automatically. Then run your search logic using the form data. if you have shared logic for both modes implement it either in abstract class or in utility class.
I don't see much wrong with your current approach. You could use an enum to avoid the string comparisons as in the following example:
public enum SearchMode {
A {
#Override
public Form createForm(Data data) {
SearchFormA form = new SearchFormA();
form.setName(...);
populateCommon(form, data);
return form;
}
},
B {
#Override
public Form createForm(Data data) {
SearchFormB form = new SearchFormB();
form.setAge(...);
populateCommon(form, data);
return form;
}
};
public abstract Form createForm(Data data);
public void populateCommon(Form form, Data data) {
// Set common properties
form.setId(...);
}
public static Form createForm(String searchMode, Data data) {
return SearchMode.valueOf(searchMode).createForm(data);
}
}
What you're obviously trying to avoid is that in the Search method you'd have to keep appending to the if structure (spaghetti code).
I feel like the situation you're describing isn't all that different from the one I wrote this answer for. That would mean that Strategy and Template (and others) could come in handy here.
Cheers,
Wim
Related
Please avoid giving answers in Kotlin only and higher than Android 21.
I'm trying to build an API parser that makes use of class hierarchy logic to represent the API hierarchy itself. With this structure I am able to parse the API in an uncomplicated fashion and I was able to achieve this already, but I'd like to improve it further.
I'll begin explaining what I already have implemented.
This is an example URL that my app will receive via GET, parse and dispatch internally:
http://www.example.com/news/article/1105
In the app the base domain is irrelevant, but what comes after is the API structure.
In this case we have a mixture of commands and variables:
news (command)
article (command)
1105 (variable)
To establish what is a command and what is a variable I built the following class structures:
public class API {
public static final News extends AbstractNews {}
}
public class AbstractNews {
public static final Article extends AbstractArticle {}
}
public class Article {
public static void GET(String articleId) {
// ...
}
}
And I iterate through each class after splitting the URL while matching each command to each class (or subclass) starting from the API class. Until I reach the end of the split URL any matches that fail are stored in a separate list as variables.
The process is as follows for the example provided above:
Split URL each forward slash (ignoring the base domain)
/news/article/1105
List<String> stringList = [
news,
article,
1105
];
Iterate each item in the split list and match agains the API structured classes (the following is just a sample example, it is not 100% of what I currently have implemtend):
List<String> variableList = new ArrayList<>();
Class lastClass = API.class;
for (String stringItem : stringList) {
if ((lastClass = classHasSubClass(lastClass, stringItem)) != null) {
continue;
}
variableList.add(stringItem);
}
Once the end of the list is reached I check if the last class contains the request method (in this case GET) and invoke along with the variable list.
Like I said before this is working perfectly fine, but it leaves every class directly exposed and as a result they can be accessed directly and incorrectly by anyone else working on the project, so I am trying to make the hierarchy more contained.
I want to keep the ability to access the methods via hierarchy as well, so the following can still be possible:
API.News.Article.GET(42334);
While at the same time I don't want it to be possible to do the following as well:
AbstractArticle.GET(42334);
I have tried making each subclass into a class instance field instead
public class API {
// this one is static on purpose to avoid having to instantiate
// the API class before accessing its fields
public static final AbstractNews News = new AbstractNews();
}
public class AbstractNews {
public final AbstractArticle Article = new AbstractArticle();
}
public class Article {
public void GET(String articleId) {
// ...
}
}
This works well for the two points I wanted to achieve before, however I am not able to find a way to iterate the class fields in a way that allows me to invoke the final methods correctly.
For the previous logic all I needed to iterate was the following:
private static Class classHasSubClass(Class<?> currentClass, String fieldName) {
Class[] classes;
classes = currentClass.getClasses();
for (final Class classItem : classes) {
if (classItem.getSimpleName().toLowerCase().equals(fieldName)) {
return classItem;
}
}
return null;
}
But for the second logic attempt with fields I was not able to invoke the final method correctly, probably because the resulting logic was in fact trying to do the following:
AbstractArticle.GET(42334);
Instead of
API.News.Article.GET(42334);
I suspect it is because the first parameter of the invoke method can no longer be null like I was doing before and has to be the correct equivalent of API.News.Article.GET(42334);
Is there a way to make this work or is there a better/different way of doing this?
I discovered that I was on the right path with the instance fields, but was missing part of the necessary information to invoke the method correctly at the end.
When iterating the fields I was only using the Class of each field, which was working perfectly fine before with the static class references since those weren't instances, but now it requires the instance of the field in order to work correctly.
In the end the iterating method used in place of classHasSubClass that got this to work is as follows:
private static Object getFieldClass(Class<?> currentClass, Object currentObject, final String fieldName) {
Field[] fieldList;
fieldList = currentClass.getDeclaredFields();
for (final Field field : fieldList) {
if (field.getName().toLowerCase().equals(fieldName)) {
try {
return field.get(currentObject);
} catch (IllegalAccessException e) {
e.printStackTrace();
break;
}
}
}
return null;
}
With this I always keep an instance object reference to the final field that I want to invoke to pass as the 1st parameter (someMethod.invoke(objectInstance);) instead of null.
I am creating a logic for web application to managing consents from user.
The model class that is persisted in the DB will have multiple fields, from which only a set will be changed with user request. E. g. class will have 10 fields with various consents, but user will be willing to change only 2 of those. To avoid writing a big chain of if-else's I designed this classes, to harness polymorphism to do the job for me, but somehow this design seems flawed to me. Could you tell me if this is proper way to do it?
PROBLEM: Change values of only subset of fields from large set of fields in class.
For sake of simplicity I removed getter/setters methods and some fields.
Main logic for changing consents:
public class GdprServiceImpl implements GdprService {
private final ConsentRepository consentRepository;
#Autowired
public GdprServiceImpl(ConsentRepository consentRepository) {
this.consentRepository = consentRepository;
}
#Override
public void changeConsent(User user, List<ConsentDto> consents) {
Optional<Consent> optionalConsent = consentRepository.findByUser(user);
if(optionalConsent.isPresent()) {
Consent consent = optionalConsent.get();
for(ConsentDto consentDto : consents) {
consentDto.apply(consent);
}
consentRepository.save(consent);
}
else {
Consent consent = new Consent();
consent.setUser(user);
for(ConsentDto consentDto : consents) {
consentDto.apply(consent);
}
consentRepository.save(consent);
}
}
Model class:
public class Consent {
private Boolean messageConsent;
private Boolean recordConsent;
/*CONSTRUCTOR, OTHER METHODS AND FIELDS OMITTED*/
}
Classes that will change a set of fields from Consent class:
public abstract class ConsentDto {
public abstract void apply(Consent consent);
}
public class RecordConsentDto extends ConsentDto {
private boolean consentValue;
public RecordConsentDto(boolean consentValue) {
this.consentValue = consentValue;
}
#Override
public void apply(Consent consent) {
consent.setRecordConsent(consentValue);
}
}
public class MessageConsentDto extends ConsentDto {
private boolean consentValue;
public MessageConsentDto(boolean consentValue) {
this.consentValue = consentValue;
}
#Override
public void apply(Consent consent) {
consent.setMessageConsent(this.consentValue);
}
}
You are right about the design having a "smell".
This is because the DB design is not normalized.
having a list of consents in one record is an indication. while technically it is allowed, classic RDBMS design dictatets that arrays should be represented as either one-to-many or many-to-many relation between tables. Of course, same in the object model.
a Fully normalized solution will have a consent_catalog table and many-to-many relation to users:
table consent_catalog {
int id // PK
String name
}
The catalog acts as "consent enum", having one row per type of consent (record, message, etc)
table user_consents {
int user_id references users(id)
int consent_id references consent_catalog(id)
}
This table has rows only for consents accepted by the user. no "false" consents. This design opens up new possibilities like knowing which users have a specific consent or mulitple consents in common.
This design feels like an overkill. At the end of the day you are always calling consent.setMessageConsent() or similar it's wrapped with an enum field and a class implementing ConsumerDto (which is really a Consumer). Generally DTO are not supposed to implement business logic yet one could argue that apply method is one.
It really would be cleaner to have UserConsent POJO with Boolean fields. The exception would be if triggering one consent should trigger other but it's not clear from your example.
Just my two cents. I'd prefer to see either an anemic POJO passed around or DDD aggregate root for user that manages consents but not something in between.
Me and one of my colleague were trying to solve the following problem:
Lets take an example of class A
One of my colleagues was facing problem of extracting one particular property from A.
Fetching one property from One particular class (in this case A) is easy. but lets
assume that you have multiple classes (A1, A2...) and you want to fetch one
particular property from the collection of these classes with more and more reusability of code.
for example
public class A {
private String name;
.
.
.
}
List<String> listOfNames = createNameList(listOfAInstances);
createNameList() method would be like following:
List<String> tempList = new ArrayList<>();
for(A a : listOfAInstances) {
tempList.add(a.getName());
}
return tempList;
now if there are multiple classes I have to do this for each class and different properties.
I suggested two approaches:
Reflection based approach.
Create an interface called "PropertyExtractable" and put a method in it called "extractProperty" in it.
As shown below:
interface PropertyExtractable {
Object extractProperty();
}
public class A implements PropertyExtractable {
private String name;
.
.
.
public Object extractProperty() {
return this.name;
}
}
For this I can write some utility method which then can be used everywhere i.e.
public Object getPropertiesOfPropertyExtractable(PropertyExtractable prExtractable) {
return prExtractable.extractProperty();
}
This was the background, one other colleague of mine had different opinion about 2nd approach, he told me it seems like anti-pattern. He tried to explain to me but I didn't get it entirely so and hence I am asking here.
I am trying to compare this example with the Comparator interface in Java. Like java allows us to use Comparator on any of the custom object class and allows us to define the logic for comparison then why can't I define the logic for extraction
Further more interfaces can be used in this way, then why shouldn't we use it
I want to know is this approach an anti-pattern? why?
You can place extracting code in separate method and reuse it:
class A {
private String name;
public String getName() {
return name;
}
}
class B {
private String surname;
public String getSurname() {
return surname;
}
}
public class SomeClass {
private <T> List<String> extractFields(List<T> list, Function<T, String> extractorFunction) {
return list.stream().map(extractorFunction).collect(Collectors.toList());
}
public void someMethod() {
List<A> listOfInstancesA = new ArrayList<>();
List<B> listOfInstancesB = new ArrayList<>();
// fill lists
List<String> fieldsA = extractFields(listOfInstancesA, A::getName);
List<String> fieldsB = extractFields(listOfInstancesB, B::getSurname);
}
}
The situation you describe is working with a legacy system which you don't want to change.
Since if you weren't you'd introduce an interface for the common properties (like your example for the Comparator interface). You introduced an interface without a meaning which may be an anti-pattern since you actually need a functional interface: PropertyExtractable vs. NamedObject=> has a method: String getName()).
If you want to implement Reflection, then your interface may be correct but I don't see it (e.g. in your case you already have Reflection built in into Java).
Usually you use the Adapter pattern to get a property/method from an object which doesn't implement the requested interface.
I have an object which has a few arrays as fields. It's class roughly looks like this:
public class Helper {
InsuranceInvoices[] insuranceInvoices;
InsuranceCollectiveInvoices[] insuranceCollectiveInvoices
BankInvoices[] bankInvoices;
BankCollectiveInvoices[] bankCollectiveInvoices;
}
All of the invoice types have a mutual marker interface Invoices.
I need to get all of the invoices to invoke another method on them.
Helper helperObject = new Helper();
// ...
for (InsuranceInvoices invoice : helperObject.getInsuranceInvoices()) {
Integer customerId = invoice.getCustomerId();
// ...
}
for (BankInvoices invoice : helperObject.getBankInvoices()) {
Integer customerId = invoice.getCustomerId();
// ...
}
// repeat with all array fields
The problem is that all invoices only have the marker interface in common. The method getCustomerID() is not defined by a mutual interface or class. This is a behaviour I cannot change due to a given specification.
The code repetition inside the for-each-loop is something that bugs me. I have to do the exact same thing on all invoice objects in the four different arrays. Hence four for-each-loops that unecessary bloat the code.
Is there a way that I can write a general (private) method? One idea was:
private void generalMethod(Invoice[] invoiceArray){
// ...
}
But this would require four instanceof checks because the class Invoice doesn't know the method getCusomterId(). Therefore I would gain nothing; the method would still contain repetitions.
I'm thankful for every possible solution to generalize this problem!
Possible solutions to generalize the problem (ordered from best to worst):
Using wrapper class
public class InvoiceWrapper {
private String customerID;
public String getCustomerID() {
return customerID;
}
public InvoiceWrapper(BankInvoices invoice) {
this.customerID = invoice.getCustomerID();
}
public InvoiceWrapper(InsuranceInvoices invoice) {
this.customerID = invoice.getCustomerID();
}
// other constructors
}
Upd If I understood correctly, you need to do something with IDs in all arrays. To use InvoiceWrapper, you also need to implement iterator in Helper class, that will walk through arrays and return a wrapper for each entry. So, you will have code that works with 4 arrays anyway.
Using instance of casts
public class CustomerIdHelper {
public static String getID(Invoice invoice) {
if (invoice instanceof InsuranceInvoices) {
return ((InsuranceInvoices) invoices).getCustomerID();
} else if ...
}
}
Calling methods by name via Reflection
public class CustomerIdHelper {
public static String getID(Invoice invoice) {
Method method = invoice.getClass().getDeclaredMethod("getCustomerId");
return (String) method.invoke(invoice);
}
}
It's not pretty, but you could use reflection to look up the getCustomerId Method and then invoke() it, cf. Class.getDeclaredMethod().
private void generalMethod(Invoice[] invoiceArray){
try {
for (Invoice invoice : invoiceArray) {
Method getCustomerId = invoice.getClass().getDeclaredMethod("getCustomerId");
getCustomerId.invoke(invoice);
}
} catch (Exception e) {
// ...
}
}
Do note that this is untested.
If you are not allowed to change the classes you are handling by adding a custom interface to them. The best thing you can do is wrap them with a custom class that does have the desired properties.
This way you will have one class with all 'not so nice' code that converts the classes you can not touch to nice classes that match a proper and useful design.
For instance you could have a class WrappedInsuranceInvoice that extends WrappedInsurace and contains a member field InsuranceInvoice. If you don't need to keep the original class you would be off even better by copying the data. This way you could for instance lose the arrays and use lists instead.
I'm sorry if this question has been asked already, I haven't found anything like my question yet...
I'm working/playing/learning to build up some kind of testing environment... Inside it, I'm building an Application Layer (a package of classes that are the virtual representation of the different pages/windows/forms) of an application. The simplified setup is the following:
public abstract class WebPage {
protected WebDriver driver;
protected WebElement getElement(By by){
WebElement element = (new WebDriverWait(driver, 10))
.until(ExpectedConditions.presenceOfElementLocated(by));
return element;
}
public void menuLogout(){
System.out.println("Logged out");
}
}
public class HomePage extends WebPage {
public ProfilePage ClickLinktoProfilePage(){
return new ProfilePage();
}
public DashBoardPage clickViewDashboard(){
return new DashBoardPage();
}
public String getTitle(){
return getElement(By.id("title")).getText();
}
}
public class ProfilePage extends WebPage {
public String getUsername(){
return getElement(By.id("name")).getText();
}
public String getEmail(){
return getElement(By.id("email")).getText();
}
public HomePage clickReturnToHomePage(){
return new HomePage();
}
}
public class DashBoardPage extends WebPage {
public String getcurrentPeriod(){
return getElement(By.id("name")).getText();
}
}
The idea behind this is that I wish my Test to hold only one current WebPage. I do not wish to create a new variable each time I change page.
I also do not want to be forced to know in advance which page I'm heading into. I want the application Layer to give me the flow of the Application. In the same way that when clicking a link, you are brought to the following page, I wish that when I click a link that brings me to another page, that method tells me what page I'm heading into.
(WebPage abstract class also exposes lots of shared methods between all concrete WebPages)
So my intended use was:
WebPage currentPage = new HomePage();
currentPage = currentPage.ClickLinktoProfilePage(); //currentPage = new ProfilePage();
System.out.println(currentPage.getUsername());
currentPage.menuLogout();
Sadly, this does not work, since the currentPage variable is typed as WebPage, it cannot see any of the concrete classes's methods. I find it logical and odd at the same time because I can ask "currentPage.getClass().getName();" and it'll return "packageName.ConcreteClassName".
For Typecasting to work, I would need to redefine the variable's type... (not sure if it's possible or even good to do).
So I know I can find the name of the class inside the variable, but I'm not sure where to go from there.
Anyone got a solution?
To clarify what Radiodef and I are saying in the comments here:
What you want is to define WebPage (your abstract API) in such a way that your concrete subclasses don't need to have public methods that aren't a part of that API.
For example, compare the java.util.List interface in the standard library. There are multiple implementations of this interface (ArrayList and LinkedList are the most well-known ones, but there are many others), but the majority of code that uses List doesn't need to care whether it's actually using an ArrayList or a LinkedList or something else, since all the operations that you need are exposed via the List interface.
You can do the same thing with your WebPage class. For example, you could define a series of "hooks" for different operations that you can do with a web page:
public abstract class WebPage {
// methods that each subclass needs to implement
protected abstract String renderBodyHtml();
public abstract String getNameToLinkTo();
// other methods that are common to every page
public final void serve(
HttpServletRequest request, HttpServletResponse response) {
// write the response, using the specific page's body HTML
response.getWriter().println(renderToBodyHtml());
}
}
And then your pages would implement that contract like so:
// Note: the class doesn't need to be public, since anybody that uses
// it can just declare their variable as type WebPage
class Page1 extends WebPage {
#Override protected String renderBodyHtml() {
return "<body>Hello world!</body>";
}
#Override public String getNameToLinkTo() {
return "Page1";
}
}
Then code that wants to work with a WebPage doesn't need to know that it's a Page1 (or any other page):
public static void printPageName(WebPage webPage) {
System.out.println(webPage.getNameToLinkTo());
}
Alternatively, like resueman says, you can just use the Page1, Page2, etc., types directly, using WebPage only for implementation inheritance, not API. This is fine as well -- the correct solution depends on how flexible (and complex) you want your code to be.