Let's define a simple state machine:
public enum State {
A, B, C, D;
private List<State> validChange;
static {
A.validChange = Arrays.asList(B);
B.validChange = Arrays.asList(C);
C.validChange = Arrays.asList(A, D);
D.validChange = Arrays.asList(D);
}
public boolean couldChange(State newState) {
return validChange.contains(newState);
}
}
and a simple state object
public class StateObject {
private State currentState;
public State getCurrentState() {
return currentState;
}
public void setCurrentState(State currentState) {
if (this.currentState != null && !this.currentState.couldChange(currentState)) {
throw new IllegalStateException(String.format("Can not change from %s to %s", this.currentState, currentState));
}
this.currentState = currentState;
}
}
As we see in the setter we check that the state change is valid. My questions:
is it a good solution to add some logic to setter method (we are not interest how does it work but only fact logic inside setter)?
when should we add logic, when should we not?
if not why?
The state pattern has its reference implementation for years. The implementation is free of your concerns. States are not represented as enums but rather as classes inheriting from the same base class. This way the implementation of transition between states is much simpler and cleaner as each state is only responsible for its own transitions.
I wonder why you decide to try your own approach instead of following a good, reliable practice.
Answering your question - there is nothing fundamentally wrong in having a code in a setter. But the way you approach the implementation of the state pattern raises unnecessary issues.
In general, yes, it's OK to have logic in setters.
If you think SRP is a good idea, then you're OK if you add logic that is related to setter functionality, which primarily means maintaining the integrity of the object w.r.t to the change of the attribute's value.
Like I said, one of the cases when this is a bad idea is an SRP violation.
In fact, I would say the code posted shows an example of such a violation, since the setter has two responsibilities:
initialize the State of a new StateObject instance,
process any transition into a new State.
The second responsibility would become even more apparent if you'd implement the remaining part of a canonical state machine, i.e. the full transition function, including transition actions.
A primary example of where this separation of concerns would become important is in code where you only have setter injection - how do you differentiate between initialization and transition in this case? With this code, you can't.
Additionally, I believe the case would become more apparent if you'd refactor validChange to StateObject, which I think is necessary, since the current code breaks encapsulation - State, a state machine label, contains "guard specification" for the state transition function. Let's say you would like to have the same labels in a different state machine - as the code currently stands, you can't have that (there's even a nice code smell that should point you towards the problem, as instead of using an enum constructor, you're forced to create a static initialization block).
Related
Although I'm not sure if I've chosen the right name for it, anyone who's worked on a large project with lots of features has probably seen it: some boolean return function gets bloated with the interaction of every little feature. Eventually what was once a simple one or two variable check becomes:
public boolean showFavoritesTool(UserData userData){
if(currentPage.isPremiumPage())
{
return true;
}
if(!userData.isLoggedIn())
{
return false;
}
if(userData.isMember())
{
return userData.getPreferences().isFavoritesTurnedOn();
}
if(getUrlParams()["showFavorites"])
{
return getUrlParams()["showFavorites"]
}
return false;
}
Edit: Let me clarify, this is just an early example of functions like this. At some point, it would grow as new features are developed to at least twice this size. The function I was looking at that prompted this question had at least 15 variables, some of which were nested. This code may look simple, but it won't remain so as new variables are added.
Everytime a new feature is added, another entry is thrown into the flag function. They don't usually overlap, but when they do you can be sure that no one has thought about what should happen. It doesn't take long before these functions become hard to interpret.
Is there a cleaner solution to this? Also, if that cleaner solution involves more architecture, when would one implement it? As soon as a second variable is added? Or is there some breaking point?
Your question is rather general and it is difficult to understand its scope, nevertheless I will try and provide some insight which will hopefully answer it.
Everytime a new feature is added, another entry is thrown into the flag function. They don't usually overlap, but when they do you can be sure that no one has thought about what should happen
This is a nasty side effect of poor planning and design. Code should be closed for modification, but open to extension
Design with the future in mind, as mentioned previously by Yuval Itzchakov, an interface which contains an abstract showFavouritesTool() method which is overriden by each user class depending on each classes requirements will provide greater flexibility, and adhere to the Open/Closed principle. Unfortunately, with the limited information given, it would be difficult to create an example which fits your problem.
Incidently, there will be occassions where multiple boolean expressions need checking. Why not simplify the method by using one concise statement.
For example:
public boolean showFavoritesTool(UserData userData){
return currentPage.isPremiumPage()
|| userData.isLoggedIn() && userData.isMember() && userData.getPreferences().isFavoritesTurnedOn()
|| userData.isLoggedIn() && getUrlParams()["showFavorites"];
}
I would just rewrite it in a more conscious and understandable form. This requires some care because early returns, (double) negations and the like often obscure the behavior and it is easy to introduce bugs.
public boolean showFavoritesTool(UserData userData)
{
return currentPage.isPremiumPage()
|| userData.isLoggedIn() && userData.isMember() && userData.getPreferences().isFavoritesTurnedOn()
|| userData.isLoggedIn() && getUrlParams()["showFavorites"];
}
If the logic becomes is really complex it helps introducing some intermediate variables.
public boolean showFavoritesTool(UserData userData)
{
var isPremiumPage = currentPage.isPremiumPage();
var isLoggedIn = userData.isLoggedIn();
var isMemberAndHasFavoritesTurnedOn = userData.isMember() && userData.getPreferences().isFavoritesTurnedOn();
var urlIndicatesShowFavorites = getUrlParams()["showFavorites"];
return isPremiumPage
|| isLoggedIn && isMemberAndHasFavoritesTurnedOn
|| isLoggedIn && urlIndicatesShowFavorites;
}
In this example it is a bit to much but you get the idea. It is usually a good idea to align the meaning of intermediate variables with business or technical requirements.
If all the validations stay in the same place, are clear (for example, take the ! out of the second if and make it a return true, put the return value in the third if and make it a return true also, same with the last if) and commented when "favorites tool" should be shown, I don't see a problem with it.
I think your question is a bit too general, since i don't fully understand the scope of the problem. there are multiple uses of fields which we have no knowledge about.
But in general, if you are trying to categories which set of features you want to expose to a group of users, you could make them all inherit a base type, which has an abstract method with a function called SetFavoriteTool, like so:
public abstract class BaseData
{
public abstract bool ShowFavoriteTool();
}
public class UserData : BaseData
{
public override bool ShowFavoriteTool()
{
if ....
}
}
or if you're more into interfaces, you could depend on an IFavoriteTool:
public interface IFavoriteTool
{
bool ShowFavoriteTool();
}
public class UserData : IFavoriteTool
{
public bool ShowFavoriteTool()
{
if..
}
}
and then you could change your method to:
public bool ShowFavoriteTool(UserData userData)
{
var favoriteTool = (IFavoriteTool) userData;
return favoriteTool.ShowFavoriteTool();
}
This is just a lead since i don't really understand the Domain problem you're dealing with.
Hope this helps.
This is what's known as "code rot." It's a process of source degrading in performance and/or maintainability. Eventually it may degrade to a point where the performance gets so bad or it becomes so unmaintainable that you have to start over (version 2.0)
Code rod occurs as a result of incremental enhancements or bug fixes that causes your design veer further and further away from the original design.
To combat code rot, you need to have (and enforce) good standards. Have code reviews, code audits, document source, write unit tests, etc.
I will occasionally create my own enum to declare the state of the object. In this case, something similar to this:
public enum FavoriteToolState {
IsVisible,
IsHidden
}
This way, you could set the state of the favorite inside the inner methods which actually determine whether or not the favorite is premium, or whether the user has logged in, or any of those other options, and instead of checking each of those methods, you could check to see if the current FavoriteToolState is FavoriteToolState.IsVisible.
Whether or not this is cleaner could be argued either way, I suppose. I prefer this way in some cases.
I have a sample(incomplete) class like
class ABC{
public:
void login();
void query_users();
//other methods
private:
//member data
}
This class should be used in a way that login needs to be called first and then only other methods like query_users, etc., can be called. Login sets some private member data for the other methods to use. Is there any simpler way to achieve this other than calling a function that checks if the member data is set at the start of every other method in the class?
There are two general approach I know of, and they differ a good bit. You'll have to pick the appropriate mechanism for the task - in standard class-based OO languages (e.g. Java/C++/C#/Python), they are the only two approaches I know of. (There may be other approaches in different paradigms that I am unfamiliar with.)
1. Check the state.
This is done in many classes already that have to track the state of the system/backing resource. Two common examples are (file) stream and database connections.
A "template" might look like:
void Logon(credentials) { ..; loggedOn = true }
void DieUnlessLoggedIn { if (!loggedOn) { throw .. } }
void DoStuff () { DieUnlessLoggedIn(); .. }
While the above approach is pretty generic, some languages may support invariants (Eiffel), decorations (Python), annotations, AOP, or other assertion mechanisms.
This approach is useful for dynamic state in a mutable world: e.g. what happens after "Logout"? The state for DoStuff is invalid again until a re-logon (if it's allowed). However, this approach cannot be used for compile-time checks in general in mainstream OOP languages because the run-time state simply is not available at compile-time.
2. Use multiple types to represent state.
Create two separate types, such that type ServiceLogon (method Logon) creates ServiceAccess (method DoStuff). Thus DoStuff can only be called (on type ServiceAccess) after created from Logon (on ServiceLogon). This works well to enforce calling order semantics in static languages with member hiding - because programs won't compile if it's wrong.
login = new ServiceLogon(credentials)
access = login.Logon();
access.DoStuff(); // can't be called before obtained via Logon
Using the type to encode additional state can be overly complex as it can fracture a class-based type system, but is useful in "builder" and "repository" patterns and such; basically, ask if the type warrants being split to maintain SRP, then considering this approach.
This approach cannot handle things like "logout" entirely without incorporating state checking as type ServiceAccess would (in the clean sense) always represent the same state due to it being encoded in the type.
1. & 2. Use state checking and state/role-specific types.
A hybrid is totally acceptable, of course, and the above two approaches are not mutually exclusive. It may make sense to separate the roles making one type (and thus methods invoked upon it) dependent upon another method while still checking runtime state as appropriate. As per above, #1 is really good for runtime guards (which can be highly dynamic) while #2 can enforce certain rules at compile-time.
What you can do is to create instances of ABC form a static factory method that returns the instance you can use. In pseudo-code:
abc = ABC.login(); //sets all the state
users = abc.query_users();
I am not sure this is the best way but you can make login() private and call it as part of the constructor, which would ensure that login() is called at time of object creation itself and after that only any other functions can be called (unless you have static functions)
class ABC{
public ABC(credentials){
login(credentails);
}
public:
void query_users();
//other methods
private:
void login();
//member data
}
It will already work first when it goes from the top down. If you want to make sure that login is successful then call the other methods from inside the login() method.
like:
public void login(){
//do login code
if(//code for login check){
//run other methods
}
else{
login(); //re-run login workings
}
}
If you really want to follow good patterns you might try making as many of your classes immutable as possible.
This would imply that your constructor sets the total state (does the entire login) and then the order of the method calls is totally irrelevant.
I have a habit of creating classes that tend to pass objects around to perform operations on them rather than assigning them to a member variable and having operations refer to the member variable. It feels much more procedural to me than OO.
Is this a terrible practice? If so, what are the adverse effects (performance, memory consumption, more error-prone)? Is it simply easier and more closely aligned to OO principles like encapsulation to favour member variables?
A contrived example of what I mean is below. I tend to do the following;
public class MyObj()
{
public MyObj() {}
public void DoVariousThings(OtherObj oo)
{
if (Validate(oo))
{
Save(oo);
}
}
private bool Validate(OtherObj oo)
{
// Do stuff related to validation
}
private bool Save(OtherObj oo)
{
// Do stuff related to saving
}
}
whereas I suspect I should be doing the following;
public class MyObj()
{
private OtherObj _oo;
public MyObj(OtherObj oo)
{
_oo = oo;
}
public void DoVariousThings()
{
if (Validate())
{
Save();
}
}
private bool Validate()
{
// Do stuff related to validation with _oo
}
private bool Save()
{
// Do stuff related to saving with _oo
}
}
If you write your programs in an object oriented language, people will expect object oriented code. As such, in your first example, they would probably expect that the reason for making oo a parameter is that you will use different objects for it all the time. In your second example, they would know that you always use the same instance (as initialized in the constructor).
Now, if you use the same object all the time, but still write your code like in your first example, you will have them thoroughly confused. When an interface is well designed, it should be obvious how to use it. This is not the case in your first example.
I think you already answered your question yourself, you seem to be aware of the fact that the 2nd approach is more favorable in general and should be used (unless there are serious reasons for the first approach).
Advantages that come to my mind immediately:
Simplified readability and maintainability, both for you and for others
Only one entry point, therefore only needing to checking for != null etc.
In case you want to put that class under test, it's way easier, i.e., getting something like this (extracting interface IOtherObj from OtherObj and working with that):
public MyObj (IOtherObj oo)
{
if (oo == null) throw...
_oo = oo;
}
Talking of the adverse effects of your way, there are none, but only if you are keeping the programs and the code to yourself,, what are you doing is NOT a standard thing, say, if after some time, you start to work making libraries and code that may be used by others also, then it is a big problem. The may pass any foo object and hope that it would work.
you have to validate the object before passing it and if the validation fails do things accordingly, but if u use the standard OOP way, there is no need for validation or taking up the cases where an inappropriate type object is pass,
In a nutshell, your way is bad for :
1. code re-usability.
2. you have to handle more exceptions.
3. okay, if u r keeping things to urself, otherwise, not a good practice.
hope, it cleared some doubt.
Today I read a book and the author wrote that in a well-designed class the only way to access attributes is through one of that class methods. Is it a widely accepted thought? Why is it so important to encapsulate the attributes? What could be the consequences of not doing it? I read somewhere earlier that this improves security or something like that. Any example in PHP or Java would be very helpful.
Is it a widely accepted thought?
In the object-oriented world, yes.
Why is it so important to encapsulate the attributes? What could be the consequences of not doing it?
Objects are intended to be cohesive entities containing data and behavior that other objects can access in a controlled way through a public interface. If an class does not encapsulate its data and behavior, it no longer has control over the data being accessed and cannot fulfill its contracts with other objects implied by the public interface.
One of the big problems with this is that if a class has to change internally, the public interface shouldn't have to change. That way it doesn't break any code and other classes can continue using it as before.
Any example in PHP or Java would be very helpful.
Here's a Java example:
public class MyClass {
// Should not be < 0
public int importantValue;
...
public void setImportantValue(int newValue) {
if (newValue < 0) {
throw new IllegalArgumentException("value cannot be < 0");
}
}
...
}
The problem here is that because I haven't encapsulated importantValue by making it private rather than public, anyone can come along and circumvent the check I put in the setter to prevent the object from having an invalid state. importantValue should never be less than 0, but the lack of encapsulation makes it impossible to prevent it from being so.
What could be the consequences of not
doing it?
The whole idea behind encapsulation is that all knowledge of anything related to the class (other than its interface) is within the class itself. For example, allowing direct access to attributes puts the onus of making sure any assignments are valid on the code doing the assigning. If the definition of what's valid changes, you have to go through and audit everything using the class to make sure they conform. Encapsulating the rule in a "setter" method means you only have to change it in one place, and any caller trying anything funny can get an exception thrown at it in return. There are lots of other things you might want to do when an attribute changes, and a setter is the place to do it.
Whether or not allowing direct access for attributes that don't have any rules to bind them (e.g., anything that fits in an integer is okay) is good practice is debatable. I suppose that using getters and setters is a good idea for the sake of consistency, i.e., you always know that you can call setFoo() to alter the foo attribute without having to look up whether or not you can do it directly. They also allow you to future-proof your class so that if you have additional code to execute, the place to put it is already there.
Personally, I think having to use getters and setters is clumsy-looking. I'd much rather write x.foo = 34 than x.setFoo(34) and look forward to the day when some language comes up with the equivalent of database triggers for members that allow you to define code that fires before, after or instead of a assignments.
Opinions on how "good OOD" is achieved are dime a dozen, and also very experienced programmers and designers tend to disagree about design choices and philosophies. This could be a flame-war starter, if you ask people across a wide varieties of language background and paradigms.
And yes, in theory are theory and practice the same, so language choice shouldn't influence high level design very much. But in practice they do, and good and bad things happen because of that.
Let me add this:
It depends. Encapsulation (in a supporting language) gives you some control over how you classes are used, so you can tell people: this is the API, and you have to use this. In other languages (e.g. python) the difference between official API and informal (subject to change) interfaces is by naming convention only (after all, we're all consenting adults here)
Encapsulation is not a security feature.
Another thought to ponder
Encapsulation with accessors also provides much better maintainability in the future. In Feanor's answer above, it works great to enforce security checks (assuming your instvar is private), but it can have much further reaching benifits.
Consider the following scenario:
1) you complete your application, and distribute it to some set of users (internal, external, whatever).
2) BigCustomerA approaches your team and wants an audit trail added to the product.
If everyone is using the accessor methods in their code, this becomes almost trivial to implement. Something like so:
MyAPI Version 1.0
public class MyClass {
private int importantValue;
...
public void setImportantValue(int newValue) {
if (newValue < 0) {
throw new IllegalArgumentException("value cannot be < 0");
}
importantValue = newValue;
}
...
}
MyAPI V1.1 (now with audit trails)
public class MyClass {
private int importantValue;
...
public void setImportantValue(int newValue) {
if (newValue < 0) {
throw new IllegalArgumentException("value cannot be < 0");
}
this.addAuditTrail("importantValue", importantValue, newValue);
importantValue = newValue;
}
...
}
Existing users of the API make no changes to their code and the new feature (audit trail) is now available.
Without encapsulation using accessors your faced with a huge migration effort.
When coding for the first time, it will seem like a lot of work. Its much faster to type: class.varName = something vs class.setVarName(something); but if everyone took the easy way out, getting paid for BigCustomerA's feature request would be a huge effort.
In Object Oriente Programming there is a principle that is known as (http://en.wikipedia.org/wiki/Open/closed_principle):
POC --> Principle of Open and Closed. This principle stays for: a well class design should be opened for extensibility (inheritance) but closed for modification of internal members (encapsulation). It means that you could not be able to modify the state of an object without taking care about it.
So, new languages only modify internal variables (fields) through properties (getters and setters methods in C++ or Java). In C# properties compile to methods in MSIL.
C#:
int _myproperty = 0;
public int MyProperty
{
get { return _myproperty; }
set { if (_someVarieble = someConstantValue) { _myproperty = value; } else { _myproperty = _someOtherValue; } }
}
C++/Java:
int _myproperty = 0;
public void setMyProperty(int value)
{
if (value = someConstantValue) { _myproperty = value; } else { _myproperty = _someOtherValue; }
}
public int getMyProperty()
{
return _myproperty;
}
Take theses ideas (from Head First C#):
Think about ways the fields can misused. What can go wrong if they're not set properly.
Is everything in your class public? Spend some time thinking about encapsulation.
What fields require processing or calculation? They are prime candidates.
Only make fields and methods public if you need to. If you don't have a reason to declare something public, don't.
Does it affect the time in loading the application?
or any other issues in doing so?
The question is vague on what "long" means. Here are some possible interpretations:
Interpretation #1: The constructor has many parameters
Constructors with many parameters can lead to poor readability, and better alternatives exist.
Here's a quote from Effective Java 2nd Edition, Item 2: Consider a builder pattern when faced with many constructor parameters:
Traditionally, programmers have used the telescoping constructor pattern, in which you provide a constructor with only the required parameters, another with a single optional parameters, a third with two optional parameters, and so on...
The telescoping constructor pattern is essentially something like this:
public class Telescope {
final String name;
final int levels;
final boolean isAdjustable;
public Telescope(String name) {
this(name, 5);
}
public Telescope(String name, int levels) {
this(name, levels, false);
}
public Telescope(String name, int levels, boolean isAdjustable) {
this.name = name;
this.levels = levels;
this.isAdjustable = isAdjustable;
}
}
And now you can do any of the following:
new Telescope("X/1999");
new Telescope("X/1999", 13);
new Telescope("X/1999", 13, true);
You can't, however, currently set only the name and isAdjustable, and leaving levels at default. You can provide more constructor overloads, but obviously the number would explode as the number of parameters grow, and you may even have multiple boolean and int arguments, which would really make a mess out of things.
As you can see, this isn't a pleasant pattern to write, and even less pleasant to use (What does "true" mean here? What's 13?).
Bloch recommends using a builder pattern, which would allow you to write something like this instead:
Telescope telly = new Telescope.Builder("X/1999").setAdjustable(true).build();
Note that now the parameters are named, and you can set them in any order you want, and you can skip the ones that you want to keep at default values. This is certainly much better than telescoping constructors, especially when there's a huge number of parameters that belong to many of the same types.
See also
Wikipedia/Builder pattern
Effective Java 2nd Edition, Item 2: Consider a builder pattern when faced with many constructor parameters (excerpt online)
Related questions
When would you use the Builder Pattern?
Is this a well known design pattern? What is its name?
Interpretation #2: The constructor does a lot of work that costs time
If the work must be done at construction time, then doing it in the constructor or in a helper method doesn't really make too much of a difference. When a constructor delegates work to a helper method, however, make sure that it's not overridable, because that could lead to a lot of problems.
Here's some quote from Effective Java 2nd Edition, Item 17: Design and document for inheritance, or else prohibit it:
There are a few more restrictions that a class must obey to allow inheritance. Constructors must not invoke overridable methods, directly or indirectly. If you violate this rule, program failure will result. The superclass constructor runs before the subclass constructor, so the overriding method in the subclass will be invoked before the subclass constructor has run. If the overriding method depends on any initialization performed by the subclass constructor, the method will not behave as expected.
Here's an example to illustrate:
public class ConstructorCallsOverride {
public static void main(String[] args) {
abstract class Base {
Base() { overrideMe(); }
abstract void overrideMe();
}
class Child extends Base {
final int x;
Child(int x) { this.x = x; }
#Override void overrideMe() {
System.out.println(x);
}
}
new Child(42); // prints "0"
}
}
Here, when Base constructor calls overrideMe, Child has not finished initializing the final int x, and the method gets the wrong value. This will almost certainly lead to bugs and errors.
Interpretation #3: The constructor does a lot of work that can be deferred
The construction of an object can be made faster when some work is deferred to when it's actually needed; this is called lazy initialization. As an example, when a String is constructed, it does not actually compute its hash code. It only does it when the hash code is first required, and then it will cache it (since strings are immutable, this value will not change).
However, consider Effective Java 2nd Edition, Item 71: Use lazy initialization judiciously. Lazy initialization can lead to subtle bugs, and don't always yield improved performance that justifies the added complexity. Do not prematurely optimize.
Constructors are a little special in that an unhandled exception in a constructor may have weird side effects. Without seeing your code I would assume that a long constructor increases the risk of exceptions. I would make the constructor as simple as needed and utilize other methods to do the rest in order to provide better error handling.
The biggest disadvantage is probably the same as writing any other long function -- that it can get complex and difficult to understand.
The rest is going to vary. First of all, length and execution time don't necessarily correlate -- you could have a single line (e.g., function call) that took several seconds to complete (e.g., connect to a server) or lots of code that executed entirely within the CPU and finished quickly.
Startup time would (obviously) only be affected by constructors that were/are invoked during startup. I haven't had an issue with this in any code I've written (at all recently anyway), but I've seen code that did. On some types of embedded systems (for one example) you really want to avoid creating and destroying objects during normal use, so you create almost everything statically during bootup. Once it's running, you can devote all the processor time to getting the real work done.
Constructor is yet another function. You need very long functions called many times to make the program work slow. So if it's only called once it usually won't matter how much code is inside.
It affects the time it takes to construct that object, naturally, but no more than having an empty constructor and calling methods to do that work instead. It has no effect on the application load time
In case of copy constructor if we use donot use reference in that case
it will create an object and call the copy constructor and passing the
value to the copy constructor and each time a new object is created and
each time it will call the copy constructor it goes to infinite and
fill the memory then it display the error message .
if we pass the reference it will not create the new object for storing
the value. and no recursion will take place
I would avoid doing anything in your constructor that isn't absolutely necessary. Initialize your variables in there, and try not to do much else. Additional functionality should reside in separate functions that you call only if you need to.