Clean architecture/OOP and optimization: how to organize for classes with same logic

45 views Asked by At

Let's guess I have class on server like

class MyData {
  String statusA;
  String statusB;
  String statusC;
  ...
  Something field20;

  boolean canDoX() {
    return statusA.equals('z') && statusB.equals('y')
  }
}

It is mapping from DB entity. Now for optimization was created new class

class MyDataWithHalfOfFields {
  String statusA;
  String statusB;
  String statusC;
  ...
  Something field10;
}

How should I replace canDoX so that it will be according to clean architecture?

Lang is Java but not really matter

Update

Why it is optimization. Designer wants 2 pages in frontend

  1. Group of objects with data from array of MyDataWithHalfOfFields
  2. Page of MyData

May be it won't be a big problem to get unnecessary fields for one object but for list it already more consuming

2

There are 2 answers

2
Ronei Kunkel On

I dont have xp with java, but i guess the question is more about oop than clean arch. But if java classes accept inheritance and abstract classes, or just inheritance, you can make a class with the specific behavior (canDoX()) an then extends in both classes. But, have a chance to use the MyData class instead MyDataWithHalfOfFields?

4
Codebling On

There's nothing "cleaner" or "optimized" about the second class, it simply has fewer fields.

If you are writing a new app, and creating a new database alongside it, then remove unnecessary fields from the database.

If you are writing an app for an existing database, you may want to isolate your ORM/entity classes from the rest of your logic. Since you don't control the database, the ORM/entitiy classes are subject to change (several ORM libraries will create the classes for you from an existing database).

Either way, you should aim to have an ORM/Entity layer which strictly represents your data and has no other logic, then another layer which has translations or abstractions over the "raw" data (whether or not this is necessary depends on your app), then you should build your app logic based on the abstraction later (or the ORM/Entity if abstractions are not necessary).