Your examples seem to imply that a window must not have a height & width, but can calculate area... I wonder how they can achieve this without knowing their height/width?
Are getters/setters the "evil" here?
You seem to imply that a data model should exist, that anaemia is a bad thing, and that data transport objects (DTOs) - which are essentially model + transport mechanism are a bad thing?
Elsewhere in this series, you seem to imply that data storage in a database is a bad thing?
Learn something new every day.
- I am a senior software engineer working in industry, teaching and writing on software design, SOLID principles, DDD and TDD.
Location
Buenos Aires
Education
Computer Science Degree at Universidad de Buenos Aires
Hi. A database is not a bad thing. It is just an accidental issue we should only tackle once we have built good models.
A window's resposability might or might not be related to answer it's width. Since it is a resposability I'd never call it a getter . The window might not it's width . But it is also accidental and should not return it
I'm clearly confused... which object should we talk to, to obtain the window's height/width, since it is intrinsically a property of the window?
Let's say that a window cleaner wants to give a quote over the phone... they will probably want to know the number & size of the windows...
Maybe the fix here is that we introduce yet another model, the GlassPane, since a window could be single/double/triple glazed etc... and then (to me), it becomes the job of the GlassPane to know it's dimensions. That feels a little too over-zealous application of Single Responsibility Principle though.
If the responsibility might, or might not lay with the Window to know it's width, at what point do we decide who's responsibility is it? If a bug is raised about it, how do we know where to fix if it responsibilities aren't tied down?
Also, I would argue that to a certain degree, the database should be considered before the models. There may be factors affecting your choice of database, which then force you down certain roads in model design. For example, if your employer says "We already have PostGres instances that DBAs know how to support... we can't justify the cost of licence & training for MSSQL" - that might affect the length of fields you can allow, etc.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Your examples seem to imply that a window must not have a height & width, but can calculate area... I wonder how they can achieve this without knowing their height/width?
Are getters/setters the "evil" here?
You seem to imply that a data model should exist, that anaemia is a bad thing, and that data transport objects (DTOs) - which are essentially model + transport mechanism are a bad thing?
Elsewhere in this series, you seem to imply that data storage in a database is a bad thing?
Have I missed something obvious?
Hi. A database is not a bad thing. It is just an accidental issue we should only tackle once we have built good models.
A window's resposability might or might not be related to answer it's width. Since it is a resposability I'd never call it a getter . The window might not it's width . But it is also accidental and should not return it
I'm clearly confused... which object should we talk to, to obtain the window's height/width, since it is intrinsically a property of the window?
Let's say that a window cleaner wants to give a quote over the phone... they will probably want to know the number & size of the windows...
Maybe the fix here is that we introduce yet another model, the GlassPane, since a window could be single/double/triple glazed etc... and then (to me), it becomes the job of the GlassPane to know it's dimensions. That feels a little too over-zealous application of Single Responsibility Principle though.
If the responsibility might, or might not lay with the Window to know it's width, at what point do we decide who's responsibility is it? If a bug is raised about it, how do we know where to fix if it responsibilities aren't tied down?
Also, I would argue that to a certain degree, the database should be considered before the models. There may be factors affecting your choice of database, which then force you down certain roads in model design. For example, if your employer says "We already have PostGres instances that DBAs know how to support... we can't justify the cost of licence & training for MSSQL" - that might affect the length of fields you can allow, etc.